| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20181214174220.GA30170@kroah.com>
Date: Fri, 14 Dec 2018 18:42:20 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jeremy Cline <jeremy@...ine.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Jean-Marc Lenoir <archlinux@...emel.com>,
Erik Schmauss <erik.schmauss@...el.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Jean Delvare <jdelvare@...e.de>,
Michael J Gruber <mjg@...oraproject.org>
Subject: Re: [PATCH 4.19 061/110] ACPICA: AML interpreter: add region
addresses in global list during initialization
On Fri, Dec 14, 2018 at 05:03:22PM +0000, Jeremy Cline wrote:
> Hi folks,
>
> On 11/29/18 9:12 AM, Greg Kroah-Hartman wrote:
> > 4.19-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Erik Schmauss <erik.schmauss@...el.com>
> >
> > commit 4abb951b73ff0a8a979113ef185651aa3c8da19b upstream.
> >
> > The table load process omitted adding the operation region address
> > range to the global list. This omission is problematic because the OS
> > queries the global list to check for address range conflicts before
> > deciding which drivers to load. This commit may result in warning
> > messages that look like the following:
> >
> > [ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (20180531/utaddress-213)
> > [ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> >
> > However, these messages do not signify regressions. It is a result of
> > properly adding address ranges within the global address list>
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
> > Tested-by: Jean-Marc Lenoir <archlinux@...emel.com>
> > Signed-off-by: Erik Schmauss <erik.schmauss@...el.com>
> > Cc: All applicable <stable@...r.kernel.org>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Cc: Jean Delvare <jdelvare@...e.de>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >
> > ---
> > drivers/acpi/acpica/dsopcode.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > --- a/drivers/acpi/acpica/dsopcode.c
> > +++ b/drivers/acpi/acpica/dsopcode.c
> > @@ -417,6 +417,10 @@ acpi_ds_eval_region_operands(struct acpi
> > ACPI_FORMAT_UINT64(obj_desc->region.address),
> > obj_desc->region.length));
> >
> > + status = acpi_ut_add_address_range(obj_desc->region.space_id,
> > + obj_desc->region.address,
> > + obj_desc->region.length, node);
> > +
> > /* Now the address and length are valid for this opregion */
> >
> > obj_desc->region.flags |= AOPOBJ_DATA_VALID;
> >
> >
> Fedora has received a couple of reports[0] of boot failures on v4.19
> kernels:
>
> kernel: BUG: unable to handle kernel paging request at 00000036000000b6
> kernel: PGD 0 P4D 0
> kernel: Oops: 0000 [#1] SMP NOPTI
> kernel: CPU: 0 PID: 108 Comm: kworker/0:3 Not tainted
> 4.19.8-300.fc29.x86_64 #1
> kernel: Hardware name: Hewlett-Packard HP Compaq 6715b/30C2, BIOS 68YTT
> Ver. F.07 07/16/2007
> kernel: Workqueue: events work_for_cpu_fn
> kernel: RIP: 0010:acpi_ns_build_normalized_path+0x76/0x108
> kernel: Code: 31 c0 48 85 ff 74 de 31 d2 49 89 f8 31 c0 4c 39 05 ff 5b
> 57 01 74 61 4c 39 c7 74 0e 39 c2 76 08 41 89 c1 42 c6 04 0e 2e ff c0
> <45> 8b 48 0c 41 89 ca 44 89 4c 24 04 45 31 c9 46 8a 5c 0c 07 45 84
> kernel: RSP: 0018:ffffb68740a1fce0 EFLAGS: 00010207
> kernel: RAX: 000000000000000a RBX: 0000000000000001 RCX: 0000000000000001
> kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9dd2360e7168
> kernel: RBP: 0000000000000000 R08: 00000036000000aa R09: fffffffffffffffc
> kernel: R10: 0000000000000000 R11: 00000000000000d2 R12: 0000000000008200
> kernel: R13: ffff9dd2360e7168 R14: ffff9dd2706980c0 R15: 0000000000000001
> kernel: FS: 0000000000000000(0000) GS:ffff9dd275c00000(0000)
> knlGS:0000000000000000
> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> kernel: CR2: 00000036000000b6 CR3: 000000007137e000 CR4: 00000000000006f0
> kernel: Call Trace:
> kernel: acpi_ns_get_normalized_pathname+0x1f/0x6d
> kernel: acpi_ut_check_address_range+0x8f/0x118
> kernel: acpi_check_address_range+0x40/0x59
> kernel: acpi_check_resource_conflict+0x3a/0x50
> kernel: acpi_check_region+0x61/0x80
> kernel: piix4_probe+0x144/0x658 [i2c_piix4]
> kernel: local_pci_probe+0x41/0x90
> kernel: work_for_cpu_fn+0x16/0x20
> kernel: process_one_work+0x1a1/0x3a0
> kernel: worker_thread+0x30/0x380
> kernel: ? pwq_unbound_release_workfn+0xd0/0xd0
> kernel: kthread+0x112/0x130
> kernel: ? kthread_create_worker_on_cpu+0x70/0x70
> kernel: ret_from_fork+0x35/0x40
> kernel: Modules linked in: i2c_piix4(+) parport_pc wmi tpm_infineon
> parport ssb hp_accel lis3lv02d mmc_core input_polldev video radeon
> i2c_algo_bit drm_kms_helper ttm drm firewire_ohci firewire_core
> ata_generic serio_raw pata_acpi yenta_socket crc_itu_t pata_atiixp
> kernel: CR2: 00000036000000b6
> kernel: ---[ end trace 9c88eedaaeca7db0 ]---
>
> I reverted this patch on v4.19.8 and at least one user (Michael, Cc'd)
> reported that fixed the regression.
>
> This patch appears to have been included in v4.19.2 (commit
> 22083c028d0b), reverted in v4.19.3 (commit 8ef305fbc50d), and finally
> included again here in v4.19.6 (commit 87403e35bc56). I couldn't find
> a discussion about bringing it back, so maybe it happened accidentally?
No it was asked to be brought back, it was not an accident.
I think the acpi developers need to make up their mind :)
thanks,
greg k-h
Powered by blists - more mailing lists