Dan Williams <dan.j.williams@xxxxxxxxx> writes: > Alistair Popple wrote: >> >> Alistair Popple <apopple@xxxxxxxxxx> writes: >> >> > Dan Williams <dan.j.williams@xxxxxxxxx> 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.
