| Message ID | c226eed72699ee1934426074b9d1c902ccfa0b48.1398817612.git.lv.zheng@intel.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng <lv.zheng@intel.com> wrote: > The commit of back porting Linux XSDT validation mechanism has introduced > a regreession: > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 > Subject: ACPICA: Back port and refine validation of the XSDT root table. > There is a pointer still accessed after unmapping. > > This patch fixes this issue. Lv Zheng. > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911 > Buglink: https://bugs.archlinux.org/task/39811 > Signed-off-by: Lv Zheng <lv.zheng@intel.com> > Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> > Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> > Signed-off-by: Bob Moore <robert.moore@intel.com> > Cc: <stable@vger.kernel.org> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table. This patch should get into 3.15-rcX soon. It fixes a known regression that prevents booting on machines with AMI firmware, and that is present in 3.14 so we need it for stable as well. Rafael? josh > --- > drivers/acpi/acpica/tbutils.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c > index 6c31d77..e1638ad 100644 > --- a/drivers/acpi/acpica/tbutils.c > +++ b/drivers/acpi/acpica/tbutils.c > @@ -355,6 +355,7 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) > u32 table_count; > struct acpi_table_header *table; > acpi_physical_address address; > + acpi_physical_address rsdt_address; > u32 length; > u8 *table_entry; > acpi_status status; > @@ -383,11 +384,14 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) > * as per the ACPI specification. > */ > address = (acpi_physical_address) rsdp->xsdt_physical_address; > + rsdt_address = > + (acpi_physical_address) rsdp->rsdt_physical_address; > table_entry_size = ACPI_XSDT_ENTRY_SIZE; > } else { > /* Root table is an RSDT (32-bit physical addresses) */ > > address = (acpi_physical_address) rsdp->rsdt_physical_address; > + rsdt_address = address; > table_entry_size = ACPI_RSDT_ENTRY_SIZE; > } > > @@ -410,8 +414,7 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) > > /* Fall back to the RSDT */ > > - address = > - (acpi_physical_address) rsdp->rsdt_physical_address; > + address = rsdt_address; > table_entry_size = ACPI_RSDT_ENTRY_SIZE; > } > } > -- > 1.7.10 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote: > On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng <lv.zheng@intel.com> wrote: > > The commit of back porting Linux XSDT validation mechanism has introduced > > a regreession: > > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 > > Subject: ACPICA: Back port and refine validation of the XSDT root table. > > There is a pointer still accessed after unmapping. > > > > This patch fixes this issue. Lv Zheng. > > > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911 > > Buglink: https://bugs.archlinux.org/task/39811 > > Signed-off-by: Lv Zheng <lv.zheng@intel.com> > > Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> > > Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> > > Signed-off-by: Bob Moore <robert.moore@intel.com> > > Cc: <stable@vger.kernel.org> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table. > > This patch should get into 3.15-rcX soon. It fixes a known regression > that prevents booting on machines with AMI firmware, and that is > present in 3.14 so we need it for stable as well. Rafael? Lv, is it safe to take this patch alone into 3.15-rc? Rafael > > --- > > drivers/acpi/acpica/tbutils.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c > > index 6c31d77..e1638ad 100644 > > --- a/drivers/acpi/acpica/tbutils.c > > +++ b/drivers/acpi/acpica/tbutils.c > > @@ -355,6 +355,7 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) > > u32 table_count; > > struct acpi_table_header *table; > > acpi_physical_address address; > > + acpi_physical_address rsdt_address; > > u32 length; > > u8 *table_entry; > > acpi_status status; > > @@ -383,11 +384,14 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) > > * as per the ACPI specification. > > */ > > address = (acpi_physical_address) rsdp->xsdt_physical_address; > > + rsdt_address = > > + (acpi_physical_address) rsdp->rsdt_physical_address; > > table_entry_size = ACPI_XSDT_ENTRY_SIZE; > > } else { > > /* Root table is an RSDT (32-bit physical addresses) */ > > > > address = (acpi_physical_address) rsdp->rsdt_physical_address; > > + rsdt_address = address; > > table_entry_size = ACPI_RSDT_ENTRY_SIZE; > > } > > > > @@ -410,8 +414,7 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) > > > > /* Fall back to the RSDT */ > > > > - address = > > - (acpi_physical_address) rsdp->rsdt_physical_address; > > + address = rsdt_address; > > table_entry_size = ACPI_RSDT_ENTRY_SIZE; > > } > > } > > -- > > 1.7.10 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
SGksIFJhZmFlbA0KDQo+IEZyb206IGxpbnV4LWFjcGktb3duZXJAdmdlci5rZXJuZWwub3JnIFtt YWlsdG86bGludXgtYWNwaS1vd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBSYWZh ZWwgSi4gV3lzb2NraQ0KPiBTZW50OiBNb25kYXksIE1heSAwNSwgMjAxNCA4OjQzIEFNDQo+IA0K PiBPbiBTYXR1cmRheSwgTWF5IDAzLCAyMDE0IDA4OjU5OjE0IEFNIEpvc2ggQm95ZXIgd3JvdGU6 DQo+ID4gT24gVHVlLCBBcHIgMjksIDIwMTQgYXQgMTA6MDUgUE0sIEx2IFpoZW5nIDxsdi56aGVu Z0BpbnRlbC5jb20+IHdyb3RlOg0KPiA+ID4gVGhlIGNvbW1pdCBvZiBiYWNrIHBvcnRpbmcgTGlu dXggWFNEVCB2YWxpZGF0aW9uIG1lY2hhbmlzbSBoYXMgaW50cm9kdWNlZA0KPiA+ID4gYSByZWdy ZWVzc2lvbjoNCj4gPiA+ICAgQ29tbWl0OiA2NzFjYzY4ZGM2MWYwMjlkNDRiNDNhNjgxMzU2MDc4 ZTAyZDhkYWI4DQo+ID4gPiAgIFN1YmplY3Q6IEFDUElDQTogQmFjayBwb3J0IGFuZCByZWZpbmUg dmFsaWRhdGlvbiBvZiB0aGUgWFNEVCByb290IHRhYmxlLg0KPiA+ID4gVGhlcmUgaXMgYSBwb2lu dGVyIHN0aWxsIGFjY2Vzc2VkIGFmdGVyIHVubWFwcGluZy4NCj4gPiA+DQo+ID4gPiBUaGlzIHBh dGNoIGZpeGVzIHRoaXMgaXNzdWUuICBMdiBaaGVuZy4NCj4gPiA+DQo+ID4gPiBCdWdsaW5rOiBo dHRwczovL2J1Z3ppbGxhLmtlcm5lbC5vcmcvc2hvd19idWcuY2dpP2lkPTczOTExDQo+ID4gPiBC dWdsaW5rOiBodHRwczovL2J1Z3MuYXJjaGxpbnV4Lm9yZy90YXNrLzM5ODExDQo+ID4gPiBTaWdu ZWQtb2ZmLWJ5OiBMdiBaaGVuZyA8bHYuemhlbmdAaW50ZWwuY29tPg0KPiA+ID4gUmVwb3J0ZWQt YW5kLXRlc3RlZC1ieTogQnJ1Y2UgQ2hpYXJlbGxpIDxtYW5vMTU1QGdtYWlsLmNvbT4NCj4gPiA+ IFJlcG9ydGVkLWFuZC10ZXN0ZWQtYnk6IFNweXJvcyBTdGF0aG9wb3Vsb3MgPHNweXN0YXRoQGdt YWlsLmNvbT4NCj4gPiA+IFNpZ25lZC1vZmYtYnk6IEJvYiBNb29yZSA8cm9iZXJ0Lm1vb3JlQGlu dGVsLmNvbT4NCj4gPiA+IENjOiA8c3RhYmxlQHZnZXIua2VybmVsLm9yZz4gIyAzLjE0Lng6IDY3 MWNjNjg6IEFDUElDQTogQmFjayBwb3J0IGFuZCByZWZpbmUgdmFsaWRhdGlvbiBvZiB0aGUgWFNE VCByb290IHRhYmxlLg0KPiA+DQo+ID4gVGhpcyBwYXRjaCBzaG91bGQgZ2V0IGludG8gMy4xNS1y Y1ggc29vbi4gIEl0IGZpeGVzIGEga25vd24gcmVncmVzc2lvbg0KPiA+IHRoYXQgcHJldmVudHMg Ym9vdGluZyBvbiBtYWNoaW5lcyB3aXRoIEFNSSBmaXJtd2FyZSwgYW5kIHRoYXQgaXMNCj4gPiBw cmVzZW50IGluIDMuMTQgc28gd2UgbmVlZCBpdCBmb3Igc3RhYmxlIGFzIHdlbGwuICBSYWZhZWw/ DQo+IA0KPiBMdiwgaXMgaXQgc2FmZSB0byB0YWtlIHRoaXMgcGF0Y2ggYWxvbmUgaW50byAzLjE1 LXJjPw0KDQpZZXMsIGl0J3Mgc2FmZSB0byBvbmx5IHRha2UgdGhpcyBwYXRjaCB0byBiZSBhIHJl Z3Jlc3Npb24gZml4Lg0KSSdtIHNvcnJ5IGZvciB0aGUgcmVncmVzc2lvbiBJIG1hZGUgaW4gdGhl IGJpc2VjdGVkIGNvbW1pdC4NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMNCi1Mdg0KDQo+IA0K PiBSYWZhZWwNCj4gDQo+IA0KPiA+ID4gLS0tDQo+ID4gPiAgZHJpdmVycy9hY3BpL2FjcGljYS90 YnV0aWxzLmMgfCAgICA3ICsrKysrLS0NCj4gPiA+ICAxIGZpbGUgY2hhbmdlZCwgNSBpbnNlcnRp b25zKCspLCAyIGRlbGV0aW9ucygtKQ0KPiA+ID4NCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJz L2FjcGkvYWNwaWNhL3RidXRpbHMuYyBiL2RyaXZlcnMvYWNwaS9hY3BpY2EvdGJ1dGlscy5jDQo+ ID4gPiBpbmRleCA2YzMxZDc3Li5lMTYzOGFkIDEwMDY0NA0KPiA+ID4gLS0tIGEvZHJpdmVycy9h Y3BpL2FjcGljYS90YnV0aWxzLmMNCj4gPiA+ICsrKyBiL2RyaXZlcnMvYWNwaS9hY3BpY2EvdGJ1 dGlscy5jDQo+ID4gPiBAQCAtMzU1LDYgKzM1NSw3IEBAIGFjcGlfc3RhdHVzIF9faW5pdCBhY3Bp X3RiX3BhcnNlX3Jvb3RfdGFibGUoYWNwaV9waHlzaWNhbF9hZGRyZXNzIHJzZHBfYWRkcmVzcykN Cj4gPiA+ICAgICAgICAgdTMyIHRhYmxlX2NvdW50Ow0KPiA+ID4gICAgICAgICBzdHJ1Y3QgYWNw aV90YWJsZV9oZWFkZXIgKnRhYmxlOw0KPiA+ID4gICAgICAgICBhY3BpX3BoeXNpY2FsX2FkZHJl c3MgYWRkcmVzczsNCj4gPiA+ICsgICAgICAgYWNwaV9waHlzaWNhbF9hZGRyZXNzIHJzZHRfYWRk cmVzczsNCj4gPiA+ICAgICAgICAgdTMyIGxlbmd0aDsNCj4gPiA+ICAgICAgICAgdTggKnRhYmxl X2VudHJ5Ow0KPiA+ID4gICAgICAgICBhY3BpX3N0YXR1cyBzdGF0dXM7DQo+ID4gPiBAQCAtMzgz LDExICszODQsMTQgQEAgYWNwaV9zdGF0dXMgX19pbml0IGFjcGlfdGJfcGFyc2Vfcm9vdF90YWJs ZShhY3BpX3BoeXNpY2FsX2FkZHJlc3MgcnNkcF9hZGRyZXNzKQ0KPiA+ID4gICAgICAgICAgICAg ICAgICAqIGFzIHBlciB0aGUgQUNQSSBzcGVjaWZpY2F0aW9uLg0KPiA+ID4gICAgICAgICAgICAg ICAgICAqLw0KPiA+ID4gICAgICAgICAgICAgICAgIGFkZHJlc3MgPSAoYWNwaV9waHlzaWNhbF9h ZGRyZXNzKSByc2RwLT54c2R0X3BoeXNpY2FsX2FkZHJlc3M7DQo+ID4gPiArICAgICAgICAgICAg ICAgcnNkdF9hZGRyZXNzID0NCj4gPiA+ICsgICAgICAgICAgICAgICAgICAgKGFjcGlfcGh5c2lj YWxfYWRkcmVzcykgcnNkcC0+cnNkdF9waHlzaWNhbF9hZGRyZXNzOw0KPiA+ID4gICAgICAgICAg ICAgICAgIHRhYmxlX2VudHJ5X3NpemUgPSBBQ1BJX1hTRFRfRU5UUllfU0laRTsNCj4gPiA+ICAg ICAgICAgfSBlbHNlIHsNCj4gPiA+ICAgICAgICAgICAgICAgICAvKiBSb290IHRhYmxlIGlzIGFu IFJTRFQgKDMyLWJpdCBwaHlzaWNhbCBhZGRyZXNzZXMpICovDQo+ID4gPg0KPiA+ID4gICAgICAg ICAgICAgICAgIGFkZHJlc3MgPSAoYWNwaV9waHlzaWNhbF9hZGRyZXNzKSByc2RwLT5yc2R0X3Bo eXNpY2FsX2FkZHJlc3M7DQo+ID4gPiArICAgICAgICAgICAgICAgcnNkdF9hZGRyZXNzID0gYWRk cmVzczsNCj4gPiA+ICAgICAgICAgICAgICAgICB0YWJsZV9lbnRyeV9zaXplID0gQUNQSV9SU0RU X0VOVFJZX1NJWkU7DQo+ID4gPiAgICAgICAgIH0NCj4gPiA+DQo+ID4gPiBAQCAtNDEwLDggKzQx NCw3IEBAIGFjcGlfc3RhdHVzIF9faW5pdCBhY3BpX3RiX3BhcnNlX3Jvb3RfdGFibGUoYWNwaV9w aHlzaWNhbF9hZGRyZXNzIHJzZHBfYWRkcmVzcykNCj4gPiA+DQo+ID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAvKiBGYWxsIGJhY2sgdG8gdGhlIFJTRFQgKi8NCj4gPiA+DQo+ID4gPiAtICAg ICAgICAgICAgICAgICAgICAgICBhZGRyZXNzID0NCj4gPiA+IC0gICAgICAgICAgICAgICAgICAg ICAgICAgICAoYWNwaV9waHlzaWNhbF9hZGRyZXNzKSByc2RwLT5yc2R0X3BoeXNpY2FsX2FkZHJl c3M7DQo+ID4gPiArICAgICAgICAgICAgICAgICAgICAgICBhZGRyZXNzID0gcnNkdF9hZGRyZXNz Ow0KPiA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgdGFibGVfZW50cnlfc2l6ZSA9IEFDUElf UlNEVF9FTlRSWV9TSVpFOw0KPiA+ID4gICAgICAgICAgICAgICAgIH0NCj4gPiA+ICAgICAgICAg fQ0KPiA+ID4gLS0NCj4gPiA+IDEuNy4xMA0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBUbyB1bnN1 YnNjcmliZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgt a2VybmVsIiBpbg0KPiA+ID4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2Vy Lmtlcm5lbC5vcmcNCj4gPiA+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtl cm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0KPiA+ID4gUGxlYXNlIHJlYWQgdGhlIEZBUSBh dCAgaHR0cDovL3d3dy50dXgub3JnL2xrbWwvDQo+ID4gLS0NCj4gPiBUbyB1bnN1YnNjcmliZSBm cm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtYWNwaSIgaW4N Cj4gPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0K PiA+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jk b21vLWluZm8uaHRtbA0KPiANCj4gLS0NCj4gSSBzcGVhayBvbmx5IGZvciBteXNlbGYuDQo+IFJh ZmFlbCBKLiBXeXNvY2tpLCBJbnRlbCBPcGVuIFNvdXJjZSBUZWNobm9sb2d5IENlbnRlci4NCj4g LS0NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vi c2NyaWJlIGxpbnV4LWFjcGkiIGluDQo+IHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRv bW9Admdlci5rZXJuZWwub3JnDQo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2Vy Lmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 5, 2014 at 12:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote: > Hi, Rafael > >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki >> Sent: Monday, May 05, 2014 8:43 AM >> >> On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote: >> > On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng <lv.zheng@intel.com> wrote: >> > > The commit of back porting Linux XSDT validation mechanism has introduced >> > > a regreession: >> > > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 >> > > Subject: ACPICA: Back port and refine validation of the XSDT root table. >> > > There is a pointer still accessed after unmapping. >> > > >> > > This patch fixes this issue. Lv Zheng. >> > > >> > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911 >> > > Buglink: https://bugs.archlinux.org/task/39811 >> > > Signed-off-by: Lv Zheng <lv.zheng@intel.com> >> > > Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> >> > > Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> >> > > Signed-off-by: Bob Moore <robert.moore@intel.com> >> > > Cc: <stable@vger.kernel.org> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table. >> > >> > This patch should get into 3.15-rcX soon. It fixes a known regression >> > that prevents booting on machines with AMI firmware, and that is >> > present in 3.14 so we need it for stable as well. Rafael? >> >> Lv, is it safe to take this patch alone into 3.15-rc? > > Yes, it's safe to only take this patch to be a regression fix. FWIW, Fedora is carrying this on top of 3.14.2 already, and people with the impacted machines say it's working for them. So I agree it should be safe. Thanks to the both of you. josh -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, May 05, 2014 08:42:46 AM Josh Boyer wrote: > On Mon, May 5, 2014 at 12:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote: > > Hi, Rafael > > > >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki > >> Sent: Monday, May 05, 2014 8:43 AM > >> > >> On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote: > >> > On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng <lv.zheng@intel.com> wrote: > >> > > The commit of back porting Linux XSDT validation mechanism has introduced > >> > > a regreession: > >> > > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 > >> > > Subject: ACPICA: Back port and refine validation of the XSDT root table. > >> > > There is a pointer still accessed after unmapping. > >> > > > >> > > This patch fixes this issue. Lv Zheng. > >> > > > >> > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911 > >> > > Buglink: https://bugs.archlinux.org/task/39811 > >> > > Signed-off-by: Lv Zheng <lv.zheng@intel.com> > >> > > Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> > >> > > Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> > >> > > Signed-off-by: Bob Moore <robert.moore@intel.com> > >> > > Cc: <stable@vger.kernel.org> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table. > >> > > >> > This patch should get into 3.15-rcX soon. It fixes a known regression > >> > that prevents booting on machines with AMI firmware, and that is > >> > present in 3.14 so we need it for stable as well. Rafael? > >> > >> Lv, is it safe to take this patch alone into 3.15-rc? > > > > Yes, it's safe to only take this patch to be a regression fix. > > FWIW, Fedora is carrying this on top of 3.14.2 already, and people > with the impacted machines say it's working for them. So I agree it > should be safe. > > Thanks to the both of you. OK, queued up for 3.15, thanks!
Hi, > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net] > Sent: Tuesday, May 06, 2014 8:44 AM > > On Monday, May 05, 2014 08:42:46 AM Josh Boyer wrote: > > On Mon, May 5, 2014 at 12:23 AM, Zheng, Lv <lv.zheng@intel.com> wrote: > > > Hi, Rafael > > > > > >> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki > > >> Sent: Monday, May 05, 2014 8:43 AM > > >> > > >> On Saturday, May 03, 2014 08:59:14 AM Josh Boyer wrote: > > >> > On Tue, Apr 29, 2014 at 10:05 PM, Lv Zheng <lv.zheng@intel.com> wrote: > > >> > > The commit of back porting Linux XSDT validation mechanism has introduced > > >> > > a regreession: > > >> > > Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 > > >> > > Subject: ACPICA: Back port and refine validation of the XSDT root table. > > >> > > There is a pointer still accessed after unmapping. > > >> > > > > >> > > This patch fixes this issue. Lv Zheng. > > >> > > > > >> > > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911 > > >> > > Buglink: https://bugs.archlinux.org/task/39811 > > >> > > Signed-off-by: Lv Zheng <lv.zheng@intel.com> > > >> > > Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> > > >> > > Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> > > >> > > Signed-off-by: Bob Moore <robert.moore@intel.com> > > >> > > Cc: <stable@vger.kernel.org> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table. > > >> > > > >> > This patch should get into 3.15-rcX soon. It fixes a known regression > > >> > that prevents booting on machines with AMI firmware, and that is > > >> > present in 3.14 so we need it for stable as well. Rafael? > > >> > > >> Lv, is it safe to take this patch alone into 3.15-rc? > > > > > > Yes, it's safe to only take this patch to be a regression fix. > > > > FWIW, Fedora is carrying this on top of 3.14.2 already, and people > > with the impacted machines say it's working for them. So I agree it > > should be safe. > > > > Thanks to the both of you. > > OK, queued up for 3.15, thanks! Actually there are 2 fixes in the same patch set for this issue: One is a regression fix for commit 671cc68 - let me call it "Solution 1 - ill formed XSDT skipping". https://patchwork.kernel.org/patch/4090591/ The other is a different approach to solve the old issue that is fixed by solution 1 - let me call it "Solution 2 - R/XSDT NULL entry skipping". https://patchwork.kernel.org/patch/4090511/ https://patchwork.kernel.org/patch/4090501/ And if you want to know the whole story before making further decisions. The commit 671cc68 is introduced to reduce the ACPICA divergences. Lacking in platforms having such ill formed XSDT shipped, I only unit tested the commit in ACPICA development environment where AcpiOsUnmapMemory() is a no-op. Thus the buggy commit is leaked to the Linux kernel during the ACPICA release cycle. When fixing the regression here: https://bugzilla.kernel.org/show_bug.cgi?id=73911 At first, the root cause is not addressed due to the same test incapability, thus it comes the solution 2 to solve the old issue in a different way. As the solution 1 prevents higher versioned tables to be used while solution 2 enables higher versioned tables, I believe solution 2 is more correct than the old approach. The solution 2 is based on ACPICA 201403 release, for kernel v3.14, a completely different stable material is generated. In the meanwhile, the regression is root caused. Though the regression fix may not be useful if the solution 2 is proven to be more correct, ACPICA also merged this regression fix in order to generate a stable material for Linux. I'm not sure if patches for solution 2 also need to be merged using the short-cut path. Possibly not as the solution 2 changed old behavior of Linux, so they are not urgent stable materials. Thanks and best regards -Lv > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center.
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c index 6c31d77..e1638ad 100644 --- a/drivers/acpi/acpica/tbutils.c +++ b/drivers/acpi/acpica/tbutils.c @@ -355,6 +355,7 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) u32 table_count; struct acpi_table_header *table; acpi_physical_address address; + acpi_physical_address rsdt_address; u32 length; u8 *table_entry; acpi_status status; @@ -383,11 +384,14 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) * as per the ACPI specification. */ address = (acpi_physical_address) rsdp->xsdt_physical_address; + rsdt_address = + (acpi_physical_address) rsdp->rsdt_physical_address; table_entry_size = ACPI_XSDT_ENTRY_SIZE; } else { /* Root table is an RSDT (32-bit physical addresses) */ address = (acpi_physical_address) rsdp->rsdt_physical_address; + rsdt_address = address; table_entry_size = ACPI_RSDT_ENTRY_SIZE; } @@ -410,8 +414,7 @@ acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address) /* Fall back to the RSDT */ - address = - (acpi_physical_address) rsdp->rsdt_physical_address; + address = rsdt_address; table_entry_size = ACPI_RSDT_ENTRY_SIZE; } }