Re: can we finally kill off CONFIG_FS_DAX_LIMITED

[Joao Martins <joao.m.martins@oracle.com>]

On 8/23/21 9:21 PM, Dan Williams wrote:
> On Mon, Aug 23, 2021 at 12:47 PM Gerald Schaefer
> <gerald.schaefer@linux.ibm.com> wrote:
>>
>> On Mon, 23 Aug 2021 16:05:46 +0200
>> Gerald Schaefer <gerald.schaefer@linux.ibm.com> wrote:
>>
>>> On Fri, 20 Aug 2021 07:43:40 +0200
>>> Christoph Hellwig <hch@lst.de> wrote:
>>>
>>>> Hi all,
>>>>
>>>> looking at the recent ZONE_DEVICE related changes we still have a
>>>> horrible maze of different code paths.  I already suggested to
>>>> depend on ARCH_HAS_PTE_SPECIAL for ZONE_DEVICE there, which all modern
>>
>> Oh, we do have PTE_SPECIAL, actually that took away the last free bit
>> in the pte. So, if there is a chance that ZONE_DEVICE would depend
>> on PTE_SPECIAL instead of PTE_DEVMAP, we might be back in the game
>> and get rid of that CONFIG_FS_DAX_LIMITED.
> 
> So PTE_DEVMAP is primarily there to coordinate the
> get_user_pages_fast() path, and even there it's usage can be
> eliminated in favor of PTE_SPECIAL. I started that effort [1], but
> need to rebase on new notify_failure infrastructure coming from Ruan
> [2]. So I think you are not in the critical path until I can get the
> PTE_DEVMAP requirement out of your way.
> 

Isn't the implicit case that PTE_SPECIAL means that you
aren't supposed to get a struct page back? The gup path bails out on
pte_special() case. And in the fact in this thread that you quote:

> [1]: https://lore.kernel.org/r/161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com

(...) we were speaking about[1.1] using that same special bit to block
longterm gup for fs-dax (while allowing it device-dax which does support it).

[1.1] https://lore.kernel.org/nvdimm/a8c41028-c7f5-9b93-4721-b8ddcf2427da@oracle.com/

Or maybe that's what you mean for this particular case of FS_DAX_LIMITED. Most _special*()
cases in mm match _devmap*() as far I've experimented in the past with PMD/PUD and dax
(prior to [1.1]).

I am just wondering would you differentiate the case where you have metadata for the
!FS_DAX_LIMITED case in {gup,gup_fast} path in light of removing PTE_DEVMAP. I would have
thought of checking that a pgmap exists for the pfn (without grabbing a ref to it).

> 
> [2]: https://lore.kernel.org/r/20210730085245.3069812-1-ruansy.fnst@fujitsu.com
>