linux-kernel - Re: commit b00bc0b237055b breaking perf subsystem

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] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0911192053080.24119@localhost.localdomain>
Date:	Thu, 19 Nov 2009 21:24:56 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, peterz@...radead.org
Subject: Re: commit b00bc0b237055b breaking perf subsystem

On Thu, 19 Nov 2009, Arjan van de Ven wrote:
> commit b00bc0b237055b4c45816325ee14f0bd83e6f590
> Author: Thomas Gleixner <tglx@...utronix.de>
> Date:   Mon Nov 2 13:01:56 2009 +0100
> 
>     uids: Prevent tear down race
> 
> has been bisected to break the perf system between -rc5 and -rc7;
> and reverting this patch in rc7 also fixes the issue.

Sigh, today seems to be the day of bisect madness.

I'm not buying direct related perf breakage from fixing that race.

Yes, I'm paranoid, but:
     Does your config have CONFIG_USER_SCHED=y ?

> now this patch is.... fun and seemingly unrelated to perf, so I
> am pretty sure something else is going on.

I fully agree, but ...
 
> the symptom of the breakage is that a userland client of perf
> (in my case, powertop) does not get to see new events if there
> is only, say, one or two of them. The data_head pointer just does
> not get updated.
> 
> Based on the patch, I have a suspicion that this pointer gets updated
> from synchronize RCU context, and this patch just makes that happen
> more.

... I have no idea how you associate that patch with the data_head
pointer and why this patch increases the sync RCU update frequency.

> If that is the case, what we really need is a new ioctl to perf that
> will cause all pending buffer state to be flushed to the ring buffer,
> that applications using perf can then just always call before looking
> at the ring. As a concept, that sounds like a good idea to me anyway...
> 
> comments/suggestions/saying-I'm-full-of-sh*t ?

I fear the latter unless you come up with some coherent explanation of
connecting that patch to rcu and the data_head pointer.

Thanks,

	tglx
--
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/