linux-kernel - Re: OOPS in perf_mmap

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: <20130524092100.GI23650@twins.programming.kicks-ass.net>
Date:	Fri, 24 May 2013 11:21:00 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vince Weaver <vincent.weaver@...ne.edu>
Cc:	Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	trinity@...r.kernel.org
Subject: Re: OOPS in perf_mmap_close()

On Thu, May 23, 2013 at 07:40:12PM -0400, Vince Weaver wrote:
> On Thu, 23 May 2013, Peter Zijlstra wrote:
> 
> > On Thu, May 23, 2013 at 10:10:36AM -0400, Vince Weaver wrote:
> > > 
> > > I can confirm your patch avoids the oops on my machine.
> > > 
> > > It does lead to interesting behavior if I run the sample program
> > > multiple times (with added printfs):
> > > 
> > > vince@...e2:~$ ./perf_mmap_close_bug 
> > > mmap1=0x7f06a6e90000
> > > mmap2=0x7f06a6e7f000
> > > vince@...e2:~$ ./perf_mmap_close_bug 
> > > mmap1=0x7f878a138000
> > > mmap2=0x7f878a127000
> > > vince@...e2:~$ ./perf_mmap_close_bug 
> > > mmap1=0xffffffffffffffff
> > > Error opening fd2 Invalid argument
> > > 
> > > and then it never successfully completes again.  Is this unexpected 
> > > behavior?  
> > 
> > Sounds weird to me, I'll see if I can reproduce/understand.
> 
> I tracked this down in case you haven't already.
> 
> The problem is that in the kernel patched 
> with your patch locked_vm is getting decremented twice in the sample code 
> and going negative.  I'm not sure why this isn't a problem until the 
> third time through.  Here are my crude debug printk 
> results from kernel/events/core.c

D'uh I think I see what's happening.. we haev split the mmap state
between the ringbuffer and event objects and since we have two events
and one ringbuffer we're hosed.

Let me try and straighten this out.
--
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/