linux-kernel - Re: mm: mmap_sem lock assertion failure in __mlock_vma_pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.11.1403131352240.20266@eggly.anvils>
Date:	Thu, 13 Mar 2014 13:57:59 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Davidlohr Bueso <davidlohr@...com>
cc:	Oleg Nesterov <oleg@...hat.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Michel Lespinasse <walken@...gle.com>,
	Rik van Riel <riel@...hat.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: mm: mmap_sem lock assertion failure in __mlock_vma_pages_range

On Thu, 13 Mar 2014, Davidlohr Bueso wrote:
> On Tue, 2014-03-11 at 18:20 -0400, Sasha Levin wrote:
> > On 03/11/2014 05:45 PM, Davidlohr Bueso wrote:
> > > On Tue, 2014-03-11 at 17:02 -0400, Sasha Levin wrote:
> > >> >On 03/11/2014 04:47 PM, Davidlohr Bueso wrote:
> > >>>> > >>Bingo! With the above patch:
> > >>>>> > >> >
> > >>>>> > >> >[  243.565794] kernel BUG at mm/vmacache.c:76!
> > >>>>> > >> >[  243.566720] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > >>>>> > >> >[  243.568048] Dumping ftrace buffer:
> > >>>>> > >> >[  243.568740]    (ftrace buffer empty)
> > >>>>> > >> >[  243.569481] Modules linked in:
> > >>>>> > >> >[  243.570203] CPU: 10 PID: 10073 Comm: trinity-c332 Tainted: G        W    3.14.0-rc5-next-20140307-sasha-00010-g1f812cb-dirty #143
> > >>> > >and this is also part of the DEBUG_PAGEALLOC + trinity combo! I suspect
> > >>> > >the root cause it the same as Fengguang's report.
> > >> >
> > >> >The BUG still happens without DEBUG_PAGEALLOC.
> > > Any idea what trinity itself is doing?
> > >
> > > Could you add the following, I just want to make sure the bug isn't
> > > being caused by an overflow:
> > 
> > Not hitting that WARN.
> 
> Sasha, could you please try the following patch:
> https://lkml.org/lkml/2014/3/13/312

I was getting the "kernel BUG at mm/vmacache.c:76!" running KSM
on mmotm: Oleg's patch (buildable version below) fixes it for me.

Hugh

--- mmotm/mm/vmacache.c	2014-03-12 18:39:38.008011317 -0700
+++ linux/mm/vmacache.c	2014-03-13 12:21:11.592030813 -0700
@@ -31,15 +31,20 @@ void vmacache_flush_all(struct mm_struct
 	rcu_read_unlock();
 }
 
+static bool vmacache_valid_mm(struct mm_struct *mm)
+{
+	return current->mm == mm && !(current->flags & PF_KTHREAD);
+}
+
 void vmacache_update(unsigned long addr, struct vm_area_struct *newvma)
 {
-	int idx = VMACACHE_HASH(addr);
-	current->vmacache[idx] = newvma;
+	if (vmacache_valid_mm(newvma->vm_mm))
+		current->vmacache[VMACACHE_HASH(addr)] = newvma;
 }
 
 static bool vmacache_valid(struct mm_struct *mm)
 {
-	struct task_struct *curr = current;
+	struct task_struct *curr;
 
 	/*
 	 * This task may be accessing a foreign mm via (for example)
@@ -47,9 +52,10 @@ static bool vmacache_valid(struct mm_str
 	 * task's vmacache pertains to a different mm (ie, its own).  There is
 	 * nothing we can do here.
 	 */
-	if (mm != curr->mm)
-		return false;
+	if (!vmacache_valid_mm(mm))
+ 		return false;
 
+	curr = current;
 	if (mm->vmacache_seqnum != curr->vmacache_seqnum) {
 		/*
 		 * First attempt will always be invalid, initialize
--
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/