Distinguishing VMalloc pages

[Matthew Wilcox <willy@infradead.org>]

I think we all like the idea of being able to look at a page [1] and
determine what it's used for.  We have two places that we already look:

PageSlab
page_type

It's not possible to use page_type for VMalloc pages because that field
is in use for mapcount.  We don't want to use another page flag bit.

I tried to use the page->mapping field in my earlier patch and that was
a problem because page_mapping() would return non-NULL, which broke
user-space unmapping of vmalloced pages through the zap_pte_range ->
set_page_dirty path.

I can see two alternatives to pursue here.  One is that we already have
special casing in page_mapping():

 	if ((unsigned long)mapping & PAGE_MAPPING_ANON)
 		return NULL;

So changing:
-#define MAPPING_VMalloc                (void *)0x440
+#define MAPPING_VMalloc                (void *)0x441

in my original patch would lead to page_mapping() returning NULL.
Are there other paths where having a special value in page->mapping is
going to cause a problem?  Indeed, is having the PAGE_MAPPING_ANON bit
set in these pages going to cause a problem?  I just don't know those
code paths well enough.

Another possibility is putting a special value in one of the other
fields of struct page.

1. page->private is not available; everybody uses that field for
everything already, and there's no way that any value could be special
enough to be unique.
2. page->index (on 32-bit systems) can already have all possible values.
3. page->lru.  The second word is already used for many random things,
but the first word is always either a pointer or compound_head (with
bit 0 set).  So we could use a set of values with bits 0 & 1 clear, and
below 4kB (ie 1023 values total) to distinguish pages.

Any preferences/recommendations/words of warning?

[1] It may be helpful to refer to the 'new64' tab for a visual depiction:
https://docs.google.com/spreadsheets/d/1tvCszs_7FXrjei9_mtFiKV6nW1FLnYyvPvW-qNZhdog/edit#gid=1941250461