On Friday, July 14, 2017 10:26:42 PM Dan Williams wrote: > [ adding Bob ] > > On Fri, Jul 14, 2017 at 3:11 PM, Vishal Verma <vishal.l.verma@xxxxxxxxx> wrote: > > 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. Well, no. The above is not a good enough reason to switch the entire subsystem over to using GPF_NOIO wholesale, especially on systems that don't care about NFIT and the related things (and that's the majority of systems shipping today AFAICS let alone the systems already in production). If that's one of *multiple* reasons to do the switch-over, we can talk about that, but otherwise it just looks like an attempt to cut corners. > Another option would be to custom code an acpi_ars_clear_error() > routine that manages to issue the proper DSM without needing to > perform any memory allocations, but this will have implications for > the common ACPICA code. But isn't that the *right* way to address the problem at hand? I guess any OS using ACPICA will run into this problem sooner or later, so it would not be unreasonable to request ACPICA modifications to address it IMO. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
