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: <[email protected]> Cc: <[email protected]> Cc: Dan Williams <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Signed-off-by: Vishal Verma <[email protected]> --- 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(-) diff --git a/include/acpi/platform/aclinuxex.h b/include/acpi/platform/aclinuxex.h index efdff52..9bd54ec 100644 --- a/include/acpi/platform/aclinuxex.h +++ b/include/acpi/platform/aclinuxex.h @@ -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) -- 2.9.3 _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
