-
Notifications
You must be signed in to change notification settings - Fork 348
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix race in GenericSerialBus (I2C) and GPIO OpRegion parameter handling
The handling of the GenericSerialBus (I2C) and GPIO OpRegions in AcpiEvAddressSpaceDispatch() passes a number of extra parameters to the address-space handler through the address-space Context pointer (instead of using more function parameters). The Context is shared between threads, so if multiple threads try to call the handler for the same address-space at the same time, then a second thread could change the parameters of a first thread while the handler is running for the first thread. An example of this race hitting is the Lenovo Yoga Tablet2 1015L, where there are both AttribBytes accesses and AttribByte accesses to the same address-space. The AttribBytes access stores the number of bytes to transfer in Context->AccessLength. Where as for the AttribByte access the number of bytes to transfer is always 1 and FieldObj->Field.AccessLength is unused (so 0). Both types of accesses racing from different threads leads to the following problem: 1. Thread a. starts an AttribBytes access, stores a non 0 value from FieldObj->Field.AccessLength in Context->AccessLength 2. Thread b. starts an AttribByte access, stores 0 in Context->AccessLength 3. Thread a. calls i2c_acpi_space_handler() (under Linux). Which sees that the access-type is ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE and calls acpi_gsb_i2c_read_bytes(..., Context->AccessLength) 4. At this point Context->AccessLength is 0 (set by thread b.) rather then the FieldObj->Field.AccessLength value from thread a. This 0 length reads leads to the following errors being logged: i2c i2c-0: adapter quirk: no zero length (addr 0x0078, size 0, read) i2c i2c-0: i2c read 0 bytes from client@0x78 starting at reg 0x0 failed, error: -95 Note this is just an example of the problems which this race can cause. There are likely many more (sporadic) problems caused by this race. This commit adds a new ContextMutex to acpi_object_addr_handler and makes AcpiEvAddressSpaceDispatch() take that mutex when using the shared Context to pass extra parameters to an address-space handler, fixing this race. Note the new mutex must be taken *after* exiting the interpreter, therefor the existing AcpiExExitInterpreter() call is moved to above the code which stores the extra parameters in the Context. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
- Loading branch information
1 parent
28cb420
commit c9e0116
Showing
4 changed files
with
59 additions
and
17 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters