On Wed, Jan 23, 2019 at 4:54 PM Jan Kara <jack@xxxxxxx> wrote: ... > > > > At first glance, this requires dropping the assumption that a for an > > uptodate clean page, vmf->vma->vm_file->f_inode == page->mapping->host. > > Is there really such an assumption in common vfs/mm code? and what will > > it take to drop it? > > There definitely is such assumption. Take for example page reclaim as one > such place that will be non-trivial to deal with. You need to remove the > page from page cache of all inodes that contain it without having any file > context whatsoever. So you will need to create some way for this page->page > caches mapping to happen. Jerome in his talk at LSF/MM last year [1] actually > nicely summarized what it would take to get rid of page->mapping > dereferences. He even had some preliminary patches. To sum it up, it's a > lot of intrusive work but in principle it is possible. > > [1] https://lwn.net/Articles/752564/ > That would be real nice if that work makes progress. However, for the sake of discussion, for the narrow case of overlayfs page sharing, if page->mapping is the overlay mapping, then it already has references to the underlying inode/mapping and overlayfs mapping ops can do the right thing for reclaim and migrate. So the fact that there is a lot of code referencing page->mapping (I know that) doesn't really answer my question of how hard it is to drop the assumption that vmf->vma->vm_file->f_inode == page->mapping->host for read protected uptodate pages from common code. Because if overlayfs (or any other arbitrator) will make sure that dirty pages and non uptodate pages abide by existing page->mapping semantics, then block layer code (for example) can still safely dereference page->mapping. In any case, I'd really love to see the first part of Jerome's work merged, with mapping propagated to all common helpers, even if the fs-specific patches and KSM patches will take longer to land. Thanks, Amir.
