linux-kernel - RE: [PATCH v5 5/9] mm: Introduce mf_dax_kill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OSBPR01MB29201EF10FBF32FF8B3A9168F4119@OSBPR01MB2920.jpnprd01.prod.outlook.com>
Date:   Fri, 16 Jul 2021 06:32:17 +0000
From:   "ruansy.fnst@...itsu.com" <ruansy.fnst@...itsu.com>
To:     Matthew Wilcox <willy@...radead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
        "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        "darrick.wong@...cle.com" <darrick.wong@...cle.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "david@...morbit.com" <david@...morbit.com>,
        "hch@....de" <hch@....de>, "agk@...hat.com" <agk@...hat.com>,
        "snitzer@...hat.com" <snitzer@...hat.com>,
        "rgoldwyn@...e.de" <rgoldwyn@...e.de>
Subject: RE: [PATCH v5 5/9] mm: Introduce mf_dax_kill_procs() for fsdax case

> From: Matthew Wilcox <willy@...radead.org>
> 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@...itsu.com 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().