[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cc219e5d-a400-776c-116b-21e5d1470045@huawei.com>
Date: Sun, 24 Apr 2022 10:00:23 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Shiyang Ruan <ruansy.fnst@...itsu.com>
CC: <djwong@...nel.org>, <dan.j.williams@...el.com>,
<david@...morbit.com>, <hch@...radead.org>, <jane.chu@...cle.com>,
Christoph Hellwig <hch@....de>, <linux-kernel@...r.kernel.org>,
<linux-xfs@...r.kernel.org>, <nvdimm@...ts.linux.dev>,
<linux-mm@...ck.org>, <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v13 3/7] pagemap,pmem: Introduce ->memory_failure()
On 2022/4/22 15:06, Shiyang Ruan wrote:
>
>
...
>>
>> Thanks for your patch. There are two questions:
>>
>> 1.Is dax_lock_page + dax_unlock_page pair needed here?
>
> They are moved into mf_generic_kill_procs() in Patch2. Callback will implement its own dax lock/unlock method. For example, for mf_dax_kill_procs() in Patch4, we implemented dax_lock_mapping_entry()/dax_unlock_mapping_entry() for it.
>
>> 2.hwpoison_filter and SetPageHWPoison will be handled by the callback or they're just ignored deliberately?
>
> SetPageHWPoison() will be handled by callback or by mf_generic_kill_procs().
>
> hwpoison_filter() is moved into mf_generic_kill_procs() too. The callback will make sure the page is correct, so it is ignored.
I see this when I read the other patches. Many thanks for clarifying!
>
>
> --
> Thanks,
> Ruan.
>
>>
>> Thanks!
>>
>>> rc = mf_generic_kill_procs(pfn, flags, pgmap);
>>> out:
>>> /* drop pgmap ref acquired in caller */
>>>
>>
>
>
> .
Powered by blists - more mailing lists