RE: [PATCH v5 5/9] mm: Introduce mf_dax_kill_procs() for fsdax case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> Subject: Re: [PATCH v5 5/9] mm: Introduce mf_dax_kill_procs() for fsdax case
> 
> On Tue, Jun 29, 2021 at 07:49:24AM +0000, ruansy.fnst@xxxxxxxxxxx wrote:
> > > But I think this is unnecessary; why not just pass the PFN into
> mf_dax_kill_procs?
> >
> > Because the mf_dax_kill_procs() is called in filesystem recovery function,
> which is at the end of the RMAP routine.  And the PFN has been translated to
> disk offset in pmem driver in order to do RMAP search in filesystem.  So, if we
> have to pass it, every function in this routine needs to add an argument for this
> PFN.  I was hoping I can avoid passing PFN through the whole stack with the
> help of this dax_load_pfn().
> 
> OK, I think you need to create:
> 
> struct memory_failure {
> 	phys_addr_t start;
> 	phys_addr_t end;
> 	unsigned long flags;
> };
> 
> (a memory failure might not be an entire page, so working in pfns isn't the best
> approach)

Do you mean the range of memory failure may less than one page size?  I found those memory_failure* functions are using pfn as their parameter.  So in which case it could be less than one page size?


--
Thanks,
Ruan.

> 
> Then that can be passed to ->memory_failure() and then deeper to
> ->notify_failure(), and finally into xfs_corrupt_helper().




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux