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
