Messages in this thread | | | Date | Wed, 12 Feb 2014 13:02:54 +0100 | From | Daniel Borkmann <> | Subject | Re: [BUG] at include/linux/page-flags.h:415 (PageTransHuge) |
| |
Hi Vlastimil,
On 02/07/2014 07:58 PM, Hannes Frederic Sowa wrote: > On Fri, Jan 31, 2014 at 03:40:38PM +0100, Vlastimil Babka wrote: >> From: Vlastimil Babka <vbabka@suse.cz> >> Date: Fri, 31 Jan 2014 11:50:21 +0100 >> Subject: [PATCH] mm: include VM_MIXEDMAP flag in the VM_SPECIAL list to avoid >> m(un)locking >> >> Daniel Borkmann reported a bug with VM_BUG_ON assertions failing where >> munlock_vma_pages_range() thinks it's unexpectedly in the middle of a THP page. >> This can be reproduced in tools/testing/selftests/net/ by running make and >> then ./psock_tpacket. >> >> The problem is that an order=2 compound page (allocated by >> alloc_one_pg_vec_page() is part of the munlocked VM_MIXEDMAP vma (mapped by >> packet_mmap()) and mistaken for a THP page and assumed to be order=9. >> >> The checks for THP in munlock came with commit ff6a6da60b89 ("mm: accelerate >> munlock() treatment of THP pages"), i.e. since 3.9, but did not trigger a bug. >> It just makes munlock_vma_pages_range() skip such compound pages until the next >> 512-pages-aligned page, when it encounters a head page. This is however not a >> problem for vma's where mlocking has no effect anyway, but it can distort the >> accounting. >> Since commit 7225522bb ("mm: munlock: batch non-THP page isolation and >> munlock+putback using pagevec") this can trigger a VM_BUG_ON in PageTransHuge() >> check. >> >> This patch fixes the issue by adding VM_MIXEDMAP flag to VM_SPECIAL - a list of >> flags that make vma's non-mlockable and non-mergeable. The reasoning is that >> VM_MIXEDMAP vma's are similar to VM_PFNMAP, which is already on the VM_SPECIAL >> list, and both are intended for non-LRU pages where mlocking makes no sense >> anyway.
Thanks a lot for your efforts.
Is your patch queued up somewhere for mainline and stable?
> I also ran into this problem and wanted to ask what the status of this > patch is? Does it need further testing? I can surely help with that. ;) > > Thanks, > > Hannes >
| |