Re: [PATCH v3 04/25] fsdax: Introduce dax_zap_mappings()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dan Williams <dan.j.williams@xxxxxxxxx> writes:

> Typical pages take a reference at pte insertion and drop it at
> zap_pte_range() time. That reference management is missing for DAX
> leading to a situation where DAX pages are mapped in user page tables,
> but are not referenced.
>
> Once fsdax decides it wants to unmap the page it can drop its reference,
> but unlike typical pages it needs to maintain the association of the
> page to the inode that arbitrated the access in the first instance. It
> maintains that association until explicit truncate(), or the implicit
> truncate() that occurs at inode death, truncate_inode_pages_final().
>
> The zapped state tracks whether the fsdax has dropped its interest in a
> page, but still allows the associated i_pages entry to live until
> truncate. This facilitates inode lookup while awaiting any page pin
> users to drop their pins. For example, if memory_failure() is triggered
> on the page after it has been unmapped, but before it has been truncated
> from the inode, memory_failure() can still associate the event with the
> inode.
>
> Once truncate begins fsdax unmaps the page to prevent any new references
> from being taken without calling back into fsdax core to reestablish
> the mapping.

The gup path should now check dax_is_zap()?  Where do we
prevent new referenced from being taken?

-aneesh



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux