[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d53c2d1e-16c6-5540-fdcb-e89adf7f4dec@oracle.com>
Date: Thu, 5 Aug 2021 17:59:01 -0700
From: Jane Chu <jane.chu@...cle.com>
To: Shiyang Ruan <ruansy.fnst@...itsu.com>,
linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
nvdimm@...ts.linux.dev, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, dm-devel@...hat.com
Cc: djwong@...nel.org, dan.j.williams@...el.com, david@...morbit.com,
hch@....de, agk@...hat.com, snitzer@...hat.com
Subject: Re: [PATCH RESEND v6 5/9] mm: Introduce mf_dax_kill_procs() for fsdax
case
> @@ -134,6 +134,12 @@ static int hwpoison_filter_dev(struct page *p)
> if (PageSlab(p))
> return -EINVAL;
>
> + if (pfn_valid(page_to_pfn(p))) {
> + if (is_device_fsdax_page(p))
> + return 0;
> + } else
> + return -EINVAL;
> +
Just curious, what is the rational for preventing dax pages from
participating in hwpoison_filter test?
> +int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index, int flags)
> +{
> + LIST_HEAD(to_kill);
> + /* load the pfn of the dax mapping file */
> + unsigned long pfn = dax_load_pfn(mapping, index);
> +
> + /* the failure pfn may not actually be mmapped, so no need to
> + * unmap and kill procs */
> + if (!pfn)
> + return 0;
what if a process has mapped the file but never faulted in, but did ask
for early signal, will it be excluded due to lack of the 'pfn' association?
thanks,
-jane
Powered by blists - more mailing lists