On 11/06/18 15:11, Matthew Wilcox wrote:
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.
This seems pretty similar to what I am doing in a preparatory patch for
pmalloc (I'm still working on this, I just got swamped in day-job
related stuff, but I am progressing toward an example with IMA).
So it looks like my patch won't work, after all?
Although, in your case, you noticed a problem with userspace, while I do
not care at all about that, so maybe there is some wriggling space there ...
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?
Why not having a reference (either direct or indirect) to the actual
vmap area, and then the flag there, instead?
I do not know the specific use case you have in mind - if any - but I
think that if one is already trying to figure out what sort of use the
vmalloc page is put to, then probably pretty soon there will be a need
for a reference to the area.
So what if the page could hold a reference the area, where there would
be more space available for specifying what it is used for?
--
igor
