Re: [PATCH] fix page_count in ->iomap_migrate_page()

From: Richard Weinberger
Date: Fri Dec 14 2018 - 08:35:45 EST

Am Freitag, 14. Dezember 2018, 13:26:28 CET schrieb Gao Xiang:
> Hi Richard,
> On 2018/12/14 19:25, Richard Weinberger wrote:
> > This is the third place which needs this workaround.
> > UBIFS, F2FS, and now iomap.
> >
> > I agree with Dave that nobody can assume that PG_private implies an additional
> > page reference.
> > But page migration does that. Including parts of the write back code.
> It seems that it's clearly documented in
> * A pagecache page contains an opaque `private' member, which belongs to the
> * page's address_space. Usually, this is the address of a circular list of
> * the page's disk buffers. PG_private must be set to tell the VM to call
> * into the filesystem to release these pages.
> *
> * A page may belong to an inode's memory mapping. In this case, page->mapping
> * is the pointer to the inode, and page->index is the file offset of the page,
> * in units of PAGE_SIZE.
> *
> * If pagecache pages are not associated with an inode, they are said to be
> * anonymous pages. These may become associated with the swapcache, and in that
> * case PG_swapcache is set, and page->private is an offset into the swapcache.
> *
> * In either case (swapcache or inode backed), the pagecache itself holds one
> * reference to the page. Setting PG_private should also increment the
> * refcount. The each user mapping also has a reference to the page.
> and when I looked into that, I found

Hmm, in case of UBIFS it seems easy. We can add a get/put_page() around setting/clearing
the flag.
I did that now and so far none of my tests exploded.

Artem, do you remember why UBIFS never raised the page counter when setting PG_private?