On Fri, Oct 22, 2021 at 01:37:28AM +0000, Jane Chu wrote: > On 10/21/2021 4:31 AM, Christoph Hellwig wrote: > > Looking over the series I have serious doubts that overloading the > > slow path clear poison operation over the fast path read/write > > path is such a great idea. > > > > Understood, sounds like a concern on principle. But it seems to me > that the task of recovery overlaps with the normal write operation > on the write part. Without overloading some write operation for > 'recovery', I guess we'll need to come up with a new userland > command coupled with a new dax API ->clear_poison and propagate the > new API support to each dm targets that support dax which, again, > is an idea that sounds too bulky if I recall Dan's earlier rejection > correctly. When I wrote the above I mostly thought about the in-kernel API, that is use a separate method. But reading your mail and thinking about this a bit more I'm actually less and less sure that overloading pwritev2 and preadv2 with this at the syscall level makes sense either. read/write are our I/O fast path. We really should not overload the core of the VFS with error recovery for a broken hardware interface.
