From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by kanga.kvack.org (Postfix) with ESMTP id B07D46B0036 for ; Tue, 29 Apr 2014 06:03:12 -0400 (EDT) Received: by mail-pa0-f45.google.com with SMTP id kq14so6254778pab.18 for ; Tue, 29 Apr 2014 03:03:12 -0700 (PDT) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com. [202.81.31.142]) by mx.google.com with ESMTPS id rb6si12326837pab.436.2014.04.29.03.03.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Apr 2014 03:03:11 -0700 (PDT) Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Apr 2014 20:03:07 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id BB00F357805F for ; Tue, 29 Apr 2014 20:03:05 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s3TA2owG60686412 for ; Tue, 29 Apr 2014 20:02:50 +1000 Received: from d23av03.au.ibm.com (localhost [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s3TA331A005210 for ; Tue, 29 Apr 2014 20:03:04 +1000 Message-ID: <535F78A8.80403@linux.vnet.ibm.com> Date: Tue, 29 Apr 2014 15:32:16 +0530 From: "Srivatsa S. Bhat" MIME-Version: 1.0 Subject: Re: [BUG] kernel BUG at mm/vmacache.c:85! References: <535EA976.1080402@linux.vnet.ibm.com> <1398724754.25549.35.camel@buesod1.americas.hpqcorp.net> <20140428161120.4cad719dc321e3c837db3fd6@linux-foundation.org> <1398730319.25549.40.camel@buesod1.americas.hpqcorp.net> In-Reply-To: <1398730319.25549.40.camel@buesod1.americas.hpqcorp.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Davidlohr Bueso Cc: Linus Torvalds , Andrew Morton , Linux MM , "linux-kernel@vger.kernel.org" , Rik van Riel , Michel Lespinasse , Hugh Dickins , Oleg Nesterov On 04/29/2014 05:41 AM, Davidlohr Bueso wrote: > On Mon, 2014-04-28 at 16:57 -0700, Linus Torvalds wrote: >> On Mon, Apr 28, 2014 at 4:11 PM, Andrew Morton >> wrote: >>> >>> unuse_mm() leaves current->mm at NULL so we'd hear about it pretty >>> quickly if a user task was running use_mm/unuse_mm. >> >> Yes. >> >>> I think so. Maybe it's time to cook up a debug patch for Srivatsa to >>> use? Dump the vma cache when the bug hits, or wire up some trace >>> points. Or perhaps plain old printks - it seems to be happening pretty >>> early in boot. >> >> Well, I think Srivatsa has only seen it once, and wasn't able to >> reproduce it, so we'd have to make it happen more first. >> >>> Are there additional sanity checks we can perform at cache addition >>> time? >> >> I wouldn't really expect it to happen at cache addition time, since >> that's really quite simple. There's only one caller of >> vmacache_update(), namely find_vma(). And vmacache_update() does the >> same sanity check that vmacache lookup does (ie check that the >> passed-on mm is the current thread mm, and that we're not a kernel >> thread). > > Agreed. > >> I'd be more inclined to think it's a missing invalidate, but I can >> only think of two reasons to invalidate: >> >> - the vma itself went away from the mm, got free'd/reused, and so >> vm_mm changes.. >> >> But then we'd have to remove it from the rb-tree, and both callers >> of vma_rb_erase() do a vmacache_invalidate() > > Right, if this were the case, -next never would have allowed it. > >> - the mm of a thread changed >> >> This is exec, use_mm(), and fork() (and fork really only just >> because we copy the vmacache). >> >> exec and fork do that "vmacache_flush(tsk)", which is why I was >> looking at use_mm(). > > Here's a patch to remove treating kthreads specially. Not sure how > easily it would be to test since Srivatsa only ran into it once and I > see no other users complaining. > I guess I'll hold off on testing this fix until I get to reproduce the bug more reliably.. Regards, Srivatsa S. Bhat > diff --git a/mm/mmu_context.c b/mm/mmu_context.c > index f802c2d..41445bb 100644 > --- a/mm/mmu_context.c > +++ b/mm/mmu_context.c > @@ -4,6 +4,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -29,6 +30,7 @@ void use_mm(struct mm_struct *mm) > tsk->active_mm = mm; > } > tsk->mm = mm; > + vmacache_flush(tsk); > switch_mm(active_mm, mm, tsk); > task_unlock(tsk); > #ifdef finish_arch_post_lock_switch > diff --git a/mm/vmacache.c b/mm/vmacache.c > index 1037a3ba..04009d3 100644 > --- a/mm/vmacache.c > +++ b/mm/vmacache.c > @@ -36,13 +36,10 @@ void vmacache_flush_all(struct mm_struct *mm) > * get_user_pages()->find_vma(). The vmacache is task-local and this > * task's vmacache pertains to a different mm (ie, its own). There is > * nothing we can do here. > - * > - * Also handle the case where a kernel thread has adopted this mm via use_mm(). > - * That kernel thread's vmacache is not applicable to this mm. > */ > static bool vmacache_valid_mm(struct mm_struct *mm) > { > - return current->mm == mm && !(current->flags & PF_KTHREAD); > + return current->mm == mm; > } > > void vmacache_update(unsigned long addr, struct vm_area_struct *newvma) > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org