On Tue, May 22, 2018 at 07:10:52PM +0300, Andrey Ryabinin wrote: > On 05/18/2018 10:45 PM, Matthew Wilcox wrote: > > From: Matthew Wilcox <mawilcox@xxxxxxxxxxxxx> > > > > For diagnosing various performance and memory-leak problems, it is helpful > > to be able to distinguish pages which are in use as VMalloc pages. > > Unfortunately, we cannot use the page_type field in struct page, as > > this is in use for mapcount by some drivers which map vmalloced pages > > to userspace. > > > > Use a special page->mapping value to distinguish VMalloc pages from > > other kinds of pages. Also record a pointer to the vm_struct and the > > offset within the area in struct page to help reconstruct exactly what > > this page is being used for. > > This seems useless. page->vm_area and page->vm_offset are never used. > There are no follow up patches which use this new information 'For diagnosing various performance and memory-leak problems', > and no explanation how is it can be used in current form. Right now, it's by-hand. tools/vm/page-types.c will tell you which pages are allocated to VMalloc. Many people use kernel debuggers, crashdumps and similar to examine the kernel's memory. Leaving these breadcrumbs is helpful, and those fields simply weren't in use before. > Also, this patch breaks code like this: > if (mapping = page_mapping(page)) > // access mapping Example of broken code, please? Pages allocated from the page allocator with alloc_page() come with page->mapping == NULL. This code snippet would not have granted access to vmalloc pages before.