On Tue, 22 May 2018 10:58:36 -0700 Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > 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. I added this to the changelog: : No in-kernel code uses the new KPF_VMALLOC. Like the other KPF_* : flags, it is for use by tools/vm/page-types.c. > > 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.
