Re: [PATCH 4.19 061/110] ACPICA: AML interpreter: add region addresses in global list during initialization

[Greg Kroah-Hartman]

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@xxxxxxxxx>
> > 
> > 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@xxxxxxxxxxx>
> > Signed-off-by: Erik Schmauss <erik.schmauss@xxxxxxxxx>
> > Cc: All applicable <stable@xxxxxxxxxxxxxxx>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> > Cc: Jean Delvare <jdelvare@xxxxxxx>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > 
> > ---
> >  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