Will Deacon writes:
> A little bit of digging suggests that the preempt count isn't balanced
> across the call to perf_pmu_output_stop from perf_mmap_close. Further
> digging revealed the unbalanced get_cpu_ptr in __perf_pmu_output_stop.
> Fix below!
Oh gee, that's embarrassing. Thanks!
> This
Hi Alex,
On Tue, Aug 23, 2016 at 08:08:23PM +0300, Alexander Shishkin wrote:
> Will Deacon writes:
> > On Fri, Aug 12, 2016 at 08:54:49PM +0300, Alexander Shishkin wrote:
> >> Yes, I tracked to a race between unmapping and set_output, trying to
> >> come up with a good fix now.
> >
> > Did you ge
On Tue, Aug 23, 2016 at 04:12:42PM +0100, Will Deacon wrote:
> Hi Alexander,
>
> On Fri, Aug 12, 2016 at 08:54:49PM +0300, Alexander Shishkin wrote:
> > Yes, I tracked to a race between unmapping and set_output, trying to
> > come up with a good fix now.
>
> Did you get anywhere with this? I thin
Will Deacon writes:
> Hi Alexander,
>
> On Fri, Aug 12, 2016 at 08:54:49PM +0300, Alexander Shishkin wrote:
>> Yes, I tracked to a race between unmapping and set_output, trying to
>> come up with a good fix now.
>
> Did you get anywhere with this? I think I just hit the same issue with
> the inte
Hi Alexander,
On Fri, Aug 12, 2016 at 08:54:49PM +0300, Alexander Shishkin wrote:
> Yes, I tracked to a race between unmapping and set_output, trying to
> come up with a good fix now.
Did you get anywhere with this? I think I just hit the same issue with
the intel-pt driver on my broadwell laptop
Yes, I tracked to a race between unmapping and set_output, trying to
come up with a good fix now.
On 12 August 2016 at 20:17, Vince Weaver wrote:
>
> On Tue, 9 Aug 2016, Alexander Shishkin wrote:
>
>>
>> Awesome, I'll have a look. Can you tell it it was messing around with
>> intel_bts driver fro
On Tue, 9 Aug 2016, Alexander Shishkin wrote:
>
> Awesome, I'll have a look. Can you tell it it was messing around with
> intel_bts driver from the fuzzer log?
It's not just my Haswell machine either, my Core2 machine locked up with
this (possibly related):
[69117.178434] WARNING: CPU: 1 PID
and as the fuzzing continues I started to get these, a bit worrying.
[ 6501.254564] Slab corruption (Tainted: GW ): task_struct
start=8800c072e000, len=5760
[ 6501.264971] 010: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
jkkk
[ 6501.273650] Single bit error det
On Tue, 9 Aug 2016, Alexander Shishkin wrote:
> Awesome, I'll have a look. Can you tell it it was messing around with
> intel_bts driver from the fuzzer log?
the fuzzer is messing around with the aux buffer, but this particular bug
triggered quickly so I can't easily tell if this particular bug
Vince Weaver writes:
> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
> WARN_ON_ONCE(atomic_read(
Hello
running the perf_fuzzer on Haswell, this is a new warning I don't think
I've seen before.
It works out to be this code here:
/* this has to be the last one */
rb_free_aux(rb);
WARN_ON_ONCE(atomic_read(&rb->aux_refcount));
mu
11 matches
Mail list logo
