Re: [PATCH RESEND v6 5/9] mm: Introduce mf_dax_kill_procs() for fsdax case

From: Jane Chu <jane.chu@oracle.com>
To: Shiyang Ruan <ruansy.fnst@fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	nvdimm@lists.linux.dev, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org, dm-devel@redhat.com
Cc: djwong@kernel.org, dan.j.williams@intel.com, david@fromorbit.com,
	hch@lst.de, agk@redhat.com, snitzer@redhat.com
Subject: Re: [PATCH RESEND v6 5/9] mm: Introduce mf_dax_kill_procs() for fsdax case
Date: Thu, 5 Aug 2021 17:59:01 -0700	[thread overview]
Message-ID: <d53c2d1e-16c6-5540-fdcb-e89adf7f4dec@oracle.com> (raw)
In-Reply-To: <20210730100158.3117319-6-ruansy.fnst@fujitsu.com>

> @@ -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