tree 6846f7fb6de6daf2daf40dead48354edc8be7061
parent 999a5c64d26146256b98d6fd4960da5d7f05ad64
author David Howells <dhowells@redhat.com> 1617912091 +0100
committer David Howells <dhowells@redhat.com> 1619177713 +0100

mm: Split page_has_private() in two to better handle PG_private_2

Split page_has_private() into two functions:

 (1) page_needs_cleanup() to find out if a page needs the ->releasepage(),
     ->invalidatepage(), etc. address space ops calling upon it.

     This returns true when either PG_private or PG_private_2 are set.

 (2) page_private_count() which returns a count of the number of refs
     contributed to a page for attached private data.

     This returns 1 if PG_private is set and 0 otherwise.

I think suggestion[1] is that PG_private_2 should just have a ref on the
page, but this isn't accounted in the same way as PG_private's ref.

Notes:

 (*) The following:

	btrfs_migratepage()
	iomap_set_range_uptodate()
	iomap_migrate_page()
	to_iomap_page()

     should probably all use PagePrivate() rather than page_has_private()
     since they're interested in what's attached to page->private when
     they're doing this, and not PG_private_2.

     It may not matter in these cases since page->private is probably NULL
     if PG_private is not set.

 (*) Should PAGE_FLAGS_CLEANUP (PAGE_FLAGS_PRIVATE as was) just be merged
     into page_needs_cleanup() as that's the only user?

 (*) Do we actually need PG_private, or is it possible just to see if
     page->private is NULL?

 (*) There are a lot of "if (page_has_private()) try_to_release_page()"
     combinations.  Does it make sense to make an inline function that does
     this?

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Linus Torvalds <torvalds@linux-foundation.org>
cc: Matthew Wilcox <willy@infradead.org>
cc: Christoph Hellwig <hch@lst.de>
cc: Josef Bacik <josef@toxicpanda.com>
cc: Alexander Viro <viro@zeniv.linux.org.uk>
cc: Andrew Morton <akpm@linux-foundation.org>
cc: linux-mm@kvack.org
cc: linux-cachefs@redhat.com
Link: https://lore.kernel.org/linux-fsdevel/CAHk-=whWoJhGeMn85LOh9FX-5d2-Upzmv1m2ZmYxvD31TKpUTA@mail.gmail.com/ [1]