Re: ZONE_DEVICE refcounting

[Alistair Popple <apopple@nvidia.com>]

Dan Williams <dan.j.williams@intel.com> writes:

> Alistair Popple wrote:
>> 
>> Alistair Popple <apopple@nvidia.com> writes:
>> 
>> > Dan Williams <dan.j.williams@intel.com> writes:
>> >
>> >> Alistair Popple wrote:
>> >
>> > I also noticed folio_anon() is not safe to call on a FS DAX page due to
>> > sharing PAGE_MAPPING_DAX_SHARED.
>> 
>> Also it feels like I could be missing something here. AFAICT the
>> page->mapping and page->index fields can't actually be used outside of
>> fs/dax because they are overloaded for the shared case. Therefore
>> setting/clearing them could be skipped and the only reason for doing so
>> is so dax_associate_entry()/dax_disassociate_entry() can generate
>> warnings which should never occur anyway. So all that code is
>> functionally unnecessary.
>
> What do you mean outside of fs/dax, do you literally mean outside of
> fs/dax.c, or the devdax case (i.e. dax without fs-entanglements)?

Only the cases fs dax pages might need it. ie. Not devdax which I
haven't looked at closely yet.

> Memory
> failure needs ->mapping and ->index to rmap dax pages. See
> mm/memory-failure.c::__add_to_kill() and
> mm/memory-failure.c::__add_to_kill_fsdax() where that latter one is for
> cases where the fs needs has signed up to react to dax page failure.

How does that work for reflink/shared pages which overwrite
page->mapping and page->index? Eg. in __add_to_kill() if *p is a shared fs
dax page then p->mapping == PAGE_MAPPING_DAX_SHARED and
page_address_in_vma(vma, p) will probably crash.

Thanks.