On Mon, Feb 8, 2021 at 2:55 AM Shiyang Ruan <ruansy.fnst@xxxxxxxxxxxxxx> wrote: > > When memory-failure occurs, we call this function which is implemented > by each kind of devices. For the fsdax case, pmem device driver > implements it. Pmem device driver will find out the block device where > the error page locates in, and try to get the filesystem on this block > device. And finally call filesystem handler to deal with the error. > The filesystem will try to recover the corrupted data if possiable. > > Signed-off-by: Shiyang Ruan <ruansy.fnst@xxxxxxxxxxxxxx> > --- > include/linux/memremap.h | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/include/linux/memremap.h b/include/linux/memremap.h > index 79c49e7f5c30..0bcf2b1e20bd 100644 > --- a/include/linux/memremap.h > +++ b/include/linux/memremap.h > @@ -87,6 +87,14 @@ struct dev_pagemap_ops { > * the page back to a CPU accessible page. > */ > vm_fault_t (*migrate_to_ram)(struct vm_fault *vmf); > + > + /* > + * Handle the memory failure happens on one page. Notify the processes > + * who are using this page, and try to recover the data on this page > + * if necessary. > + */ > + int (*memory_failure)(struct dev_pagemap *pgmap, unsigned long pfn, > + int flags); > }; After the conversation with Dave I don't see the point of this. If there is a memory_failure() on a page, why not just call memory_failure()? That already knows how to find the inode and the filesystem can be notified from there. Although memory_failure() is inefficient for large range failures, I'm not seeing a better option, so I'm going to test calling memory_failure() over a large range whenever an in-use dax-device is hot-removed. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel