RE: [PATCH 0/2] ACPICA: Fix a race in GenericSerialBus (I2C) and GPIO handling

["Kaneda, Erik" <erik.kaneda@intel.com>]

> -----Original Message-----
> From: Hans de Goede <hdegoede@redhat.com>
> Sent: Saturday, December 26, 2020 6:28 AM
> To: Rafael J . Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
> Moore, Robert <robert.moore@intel.com>; Kaneda, Erik
> <erik.kaneda@intel.com>
> Cc: Hans de Goede <hdegoede@redhat.com>; linux-acpi@vger.kernel.org;
> devel@acpica.org
> Subject: [PATCH 0/2] ACPICA: Fix a race in GenericSerialBus (I2C) and GPIO
> handling
> 
> Hi All,
> 
> On one of my machines I noticed the following errors being logged:
> 
> [   52.892807] i2c i2c-0: adapter quirk: no zero length (addr 0x0078, size 0,
> read)
> [   52.893037] i2c i2c-0: i2c read 0 bytes from client@0x78 starting at reg 0x0
> failed, error: -95
> 
> The second line is coming from the Linux I2C ACPI OpRegion handling and
> after a bunch of debugging I've found out that there is a rather obvious
> (once you see it) and nasty race condition in the handling of I2C and GPIO
> opregions in acpi_ev_address_space_dispatch(). See the first patch in this
> series (the second patch is a follow-up cleanup patch removing some code
> duplication).
> 
> TBH I'm surprised that this issue has gone unnoticed as long as it has,
> but I guess that it mostly leads to unreproducable sporadic problems
> making it hard to debug and I got lucky that I had a machine where the
> race seems to trigger about once every 20 seconds.
> 
> I know that ACPICA patches are normally merged through the ACPICA
> upstream
> but given that this is a serious bug, I believe that in this case it might
> be best to add the fix directly to Linux and then port it to ACPICA from
> there.

Thanks for this changeset! I'm taking a look right now

Erik
> 
> Regards,
> 
> Hans