On Thu, May 15, 2014 at 01:07:34AM -0400, Vince Weaver wrote:
> On Thu, 24 Apr 2014, Vince Weaver wrote:
>
> > On Wed, 23 Apr 2014, Peter Zijlstra wrote:
> > >
> > > Something like so should do I suppose.
> > >
> > > ---
> > > Subject: perf: Fix perf_event_open(.flags) test
> > >
> > > Vince no
On Thu, 24 Apr 2014, Vince Weaver wrote:
> On Wed, 23 Apr 2014, Peter Zijlstra wrote:
> >
> > Something like so should do I suppose.
> >
> > ---
> > Subject: perf: Fix perf_event_open(.flags) test
> >
> > Vince noticed that we test the (unsigned long) flags field against an
> > (unsigned int) c
On Wed, 23 Apr 2014, Peter Zijlstra wrote:
>
> Something like so should do I suppose.
>
> ---
> Subject: perf: Fix perf_event_open(.flags) test
>
> Vince noticed that we test the (unsigned long) flags field against an
> (unsigned int) constant. This would allow setting the high bits on 64bit
> p
On Wed, 23 Apr 2014, Vince Weaver wrote:
>
> I suppose I should make a patch for attr->sample_type and
> attr->read_format which after a quick audit seem to exhibit the same
> problem?
nevermind, PERF_FORMAT_MAX and PERF_SAMPLE_MAX are enum values, not
#defines, so they handle being 64-bit pro
On Wed, 23 Apr 2014, Peter Zijlstra wrote:
> On Tue, Apr 22, 2014 at 11:40:07PM -0400, Vince Weaver wrote:
> >
> > More fun found by the perf_fuzzer...
> >
> > In kernel/events/core.c
> > SYSCALL_DEFINE5(perf_event_open,
> >
> > We check if flags is valid like this:
> >
> > /* for fut
On Wed, 23 Apr 2014, Peter Zijlstra wrote:
>
> So perf_event_open() -> err_alloc: -> free_event() -> __free_event() ->
> call_rcu() -> free_event_rcu() -> kfree().
>
> Would explain that, right? The memory is RCU freed, which means we need
> to wait a grace period before releasing it.
ah yes, RC
On Tue, Apr 22, 2014 at 11:40:07PM -0400, Vince Weaver wrote:
>
> More fun found by the perf_fuzzer...
>
> In kernel/events/core.c
> SYSCALL_DEFINE5(perf_event_open,
>
> We check if flags is valid like this:
>
> /* for future expandability... */
> if (flags & ~PERF_FLAG_ALL)
>
On Wed, Apr 23, 2014 at 12:14:52AM -0400, Vince Weaver wrote:
> On Tue, 22 Apr 2014, Vince Weaver wrote:
>
> > This is allowing events to be allocated memory but not being freed somehow
> > before returning EINVAL (a memory leak).
> > At least it looks like this is happening in the huge traces I h
On Tue, 22 Apr 2014, Vince Weaver wrote:
> This is allowing events to be allocated memory but not being freed somehow
> before returning EINVAL (a memory leak).
> At least it looks like this is happening in the huge traces I have trying
> to track down the perf_fuzzer memory corruption bug.
I ca
More fun found by the perf_fuzzer...
In kernel/events/core.c
SYSCALL_DEFINE5(perf_event_open,
We check if flags is valid like this:
/* for future expandability... */
if (flags & ~PERF_FLAG_ALL)
return -EINVAL;
but flags is a 64-bit value but ~PERF_FLAG_ALL is 3
10 matches
Mail list logo
