@@ -83,12 +83,12 @@ acpi_status acpi_os_terminate(void);
*/
static inline void *acpi_os_allocate(acpi_size size)
{
- return kmalloc(size, irqs_disabled()? GFP_ATOMIC : GFP_KERNEL);
+ return kmalloc(size, irqs_disabled()? GFP_ATOMIC : GFP_NOIO);
}
static inline void *acpi_os_allocate_zeroed(acpi_size size)
{
- return kzalloc(size, irqs_disabled()? GFP_ATOMIC : GFP_KERNEL);
+ return kzalloc(size, irqs_disabled()? GFP_ATOMIC : GFP_NOIO);
}
static inline void acpi_os_free(void *memory)
@@ -99,7 +99,7 @@ static inline void acpi_os_free(void *memory)
static inline void *acpi_os_acquire_object(acpi_cache_t * cache)
{
return kmem_cache_zalloc(cache,
- irqs_disabled()? GFP_ATOMIC : GFP_KERNEL);
+ irqs_disabled()? GFP_ATOMIC : GFP_NOIO);
}
static inline acpi_thread_id acpi_os_get_thread_id(void)
With the ACPI NFIT 'DSM' methods, acpi can be called from IO paths. Specifically, the DSM to clear media errors is called during writes, so that we can provide a writes-fix-errors model. However it is easy to imagine a scenario like: - write through the nvdimm driver - acpi allocation - writeback, causes more IO through the nvdimm driver - deadlock Making the acpi allocations GPF_NOIO would ensure that it doesn't trigger writeback, and avoids the above deadlock. Cc: <linux-acpi@vger.kernel.org> Cc: <linux-nvdimm@lists.01.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> --- Is this too invasive a change? ACPI code in general appears to be good about error-checking allocations, and in our scenario above, a failed allocation would just mean the attempt to issue the DSM would fail, and the IO would simply fail. include/acpi/platform/aclinuxex.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)