On Tue, Jun 12, 2018 at 12:54:09PM +0300, Igor Stoppa wrote: > On 11/06/18 15:11, Matthew Wilcox wrote: > > 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 ... Yes; if your pages can never be mapped to userspace, then there's no problem. Many other users of struct page use the page->mapping field for other purposes. > Why not having a reference (either direct or indirect) to the actual > vmap area, and then the flag there, instead? Because what we're trying to do is find out "Given a random struct page, what is it used for". It might be page cache, it might be slab, it might be anything. We can't go round randomly dereferencing pointers and seeing what pot of gold is at the end of that rainbow. > 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? It might be useful to refer to the earlier patch which included that information: https://www.spinics.net/lists/linux-mm/msg152818.html
