[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20140218151450.4cb1ee9c491f3026ab34c04d@linux-foundation.org>
Date: Tue, 18 Feb 2014 15:14:50 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Daniel Borkmann <dborkman@...hat.com>
Cc: linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>,
Thomas Hellstrom <thellstrom@...are.com>,
John David Anglin <dave.anglin@...l.net>,
HATAYAMA Daisuke <d.hatayama@...fujitsu.com>,
Konstantin Khlebnikov <khlebnikov@...nvz.org>,
Carsten Otte <cotte@...ibm.com>,
Jared Hulbert <jaredeh@...il.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Rik van Riel <riel@...hat.com>,
[3.11.x+] <stable@...r.kernel.org>
Subject: Re: [PATCH akpm] mm: include VM_MIXEDMAP flag in the VM_SPECIAL
list to avoid m(un)locking
On Sun, 16 Feb 2014 15:59:45 +0100 Daniel Borkmann <dborkman@...hat.com> wrote:
> Daniel Borkmann reported a bug (stack trace above) 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
> with default config since 3.11 kernels. A reproducer can be found
> in the kernel's selftest directory for networking by running
> ./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. Related
> Lkml discussion can be found in [2].
>
> Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
> Reported-by: Daniel Borkmann <dborkman@...hat.com>
> Tested-by: Daniel Borkmann <dborkman@...hat.com>
I'll add your signed-of-by: here. As per
Documentation/SubmittingPatches 12) (c) ;)
> Took the liberty to resubmit it, as people hit that on distribution
> kernels; tested and it looks to fix the issue.
hm, I wonder why I missed this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists