On Tue, 22 May 2018 14:45:17 -0700 Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > On Tue, May 22, 2018 at 01:48:38PM -0700, Andrew Morton wrote: > > -ENOCOMMENT ;) > > > > --- a/mm/util.c~mm-distinguish-vmalloc-pages-fix-fix > > +++ a/mm/util.c > > @@ -512,6 +512,8 @@ struct address_space *page_mapping(struc > > mapping = page->mapping; > > if ((unsigned long)mapping & PAGE_MAPPING_ANON) > > return NULL; > > + > > + /* Don't trip over a vmalloc page's MAPPING_VMalloc cookie */ > > if ((unsigned long)mapping < PAGE_SIZE) > > return NULL; > > > > It's a bit sad to put even more stuff into page_mapping() just for > > page_types diddling. Is this really justified? How many people will > > use it, and get significant benefit from it? > > We could leave page->mapping NULL for vmalloc pages. We just need to > find a spot where we can put a unique identifier. The first word of > the union looks like a string candidate; bit 0 is already reserved for > PageTail. The other users are list_head.prev, a struct page *, and > struct dev_pagemap *, so that should work out OK. > > If you want to just drop this patch, I'd be OK with that. I can always > submit it to you again next merge window. OK, let's park it for now.
