Message ID | 3281896.aeNJFYEL58@kreacher |
---|---|
Headers | show |
Series | ACPI: OSL: acpi_os_execute() improvements | expand |
On Wed, Nov 29, 2023 at 02:50:54PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Notify () handlers, like GPE handlers, are only allowed to run on CPU0 > now out of the concern that they might trigger an SMM trap and that (in > some cases) the SMM code running as a result of that might corrupt > memory if not run on CPU0. Pardon my French, but I'm a bit lost in the semantics of all those "that". Maybe the above can be simplified? > However, Notify () handlers are registered by kernel code and they > are not likely to evaluate AML that would trigger an SMM trap. In > fact, many of them don't even evaluate any AML at all and even if > they do, that AML may as well be evaluated in other code paths. In > other words, they are not special from the AML evaluation perspective, > so there is no real reason to treat them in any special way. > > Accordingly, allow Notify () handlers, unlike GPE handlers, to be > executed by all CPUs in the system. > > Also adjust the allocation of the "notify" workqueue to allow multiple > handlers to be executed at the same time, because they need not be > serialized. Code wise LGTM, Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
On Wed, Nov 29, 2023 at 02:46:51PM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Reduce the number of checks and goto labels related to error handling > in acpi_os_execute() and drop the status local variable, which turns > out to be redundant, from it. > > No intentional functional impact. LGTM, Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
On Wed, Nov 29, 2023 at 3:34 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Wed, Nov 29, 2023 at 02:50:54PM +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > > > Notify () handlers, like GPE handlers, are only allowed to run on CPU0 > > now out of the concern that they might trigger an SMM trap and that (in > > some cases) the SMM code running as a result of that might corrupt > > memory if not run on CPU0. > > Pardon my French, but I'm a bit lost in the semantics of all those "that". Well, fair enough. > Maybe the above can be simplified? It can be rephrased.
Hi, On 11/29/23 14:45, Rafael J. Wysocki wrote: > Hi Everyone, > > This series improves acpi_os_execute() on top of > > https://patchwork.kernel.org/project/linux-acpi/patch/5745568.DvuYhMxLoT@kreacher/ > > but only the last patch really depends on it. > > The first two patches clean up the code somewhat and the third one modifies > the function to allow Notify () handlers to run on all CPUs (not on CPU0 only). > > The last patch changes it to use GFP_KERNEL for memory allocations, as it does > not run in interrupt context any more after the change linked above. I have added this series, as well as the preceding "ACPI: OSL: Use a threaded interrupt handler for SCI" patch to my personal tree now, so that it will get tested on various devices when I run my personal tree on them. I'll let you know if I hit any issues caused by this series. Regards, Hans
On Sat, Dec 2, 2023 at 3:31 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 11/29/23 14:45, Rafael J. Wysocki wrote: > > Hi Everyone, > > > > This series improves acpi_os_execute() on top of > > > > https://patchwork.kernel.org/project/linux-acpi/patch/5745568.DvuYhMxLoT@kreacher/ > > > > but only the last patch really depends on it. > > > > The first two patches clean up the code somewhat and the third one modifies > > the function to allow Notify () handlers to run on all CPUs (not on CPU0 only). > > > > The last patch changes it to use GFP_KERNEL for memory allocations, as it does > > not run in interrupt context any more after the change linked above. > > I have added this series, as well as the preceding > "ACPI: OSL: Use a threaded interrupt handler for SCI" > patch to my personal tree now, so that it will get tested on various > devices when I run my personal tree on them. > > I'll let you know if I hit any issues caused by this series. Thank you!
Hi Hans, On Sat, Dec 2, 2023 at 3:31 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 11/29/23 14:45, Rafael J. Wysocki wrote: > > Hi Everyone, > > > > This series improves acpi_os_execute() on top of > > > > https://patchwork.kernel.org/project/linux-acpi/patch/5745568.DvuYhMxLoT@kreacher/ > > > > but only the last patch really depends on it. > > > > The first two patches clean up the code somewhat and the third one modifies > > the function to allow Notify () handlers to run on all CPUs (not on CPU0 only). > > > > The last patch changes it to use GFP_KERNEL for memory allocations, as it does > > not run in interrupt context any more after the change linked above. > > I have added this series, as well as the preceding > "ACPI: OSL: Use a threaded interrupt handler for SCI" > patch to my personal tree now, so that it will get tested on various > devices when I run my personal tree on them. > > I'll let you know if I hit any issues caused by this series. As stated here https://lore.kernel.org/linux-acpi/CAJZ5v0jkHLGa2XxB4TMqzrBBdZYXY79+sh1Z0ZF6keYdLDyfkg@mail.gmail.com/ the last patch in this series is not really a good idea just yet, so please drop it. Thanks!
Hi, On 12/4/23 17:32, Rafael J. Wysocki wrote: > Hi Hans, > > On Sat, Dec 2, 2023 at 3:31 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 11/29/23 14:45, Rafael J. Wysocki wrote: >>> Hi Everyone, >>> >>> This series improves acpi_os_execute() on top of >>> >>> https://patchwork.kernel.org/project/linux-acpi/patch/5745568.DvuYhMxLoT@kreacher/ >>> >>> but only the last patch really depends on it. >>> >>> The first two patches clean up the code somewhat and the third one modifies >>> the function to allow Notify () handlers to run on all CPUs (not on CPU0 only). >>> >>> The last patch changes it to use GFP_KERNEL for memory allocations, as it does >>> not run in interrupt context any more after the change linked above. >> >> I have added this series, as well as the preceding >> "ACPI: OSL: Use a threaded interrupt handler for SCI" >> patch to my personal tree now, so that it will get tested on various >> devices when I run my personal tree on them. >> >> I'll let you know if I hit any issues caused by this series. > > As stated here > > https://lore.kernel.org/linux-acpi/CAJZ5v0jkHLGa2XxB4TMqzrBBdZYXY79+sh1Z0ZF6keYdLDyfkg@mail.gmail.com/ > > the last patch in this series is not really a good idea just yet, so > please drop it. Ack, done. Regards, Hans