linux-kernel - Re: [PATCH] sched: Distinguish sched_wakeup event when wake up a task which did schedule out or not.

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: <20140512064730.GI30445@twins.programming.kicks-ass.net>
Date:	Mon, 12 May 2014 08:47:30 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Dongsheng Yang <dongsheng081251@...il.com>,
	"yangds.fnst" <yangds.fnst@...fujitsu.com>,
	linux-kernel@...r.kernel.org, mingo@...hat.com, bsegall@...gle.com
Subject: Re: [PATCH] sched: Distinguish sched_wakeup event when wake up a
 task which did schedule out or not.

On Sun, May 11, 2014 at 02:52:24PM -0400, Steven Rostedt wrote:
> On Sun, 11 May 2014 18:35:31 +0200
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> 
> > So if the wait side has already observed cond==false, then without the
> > wakeup, which still potentially has ->on_rq == true, it would block.
> > Therefore the wakeup is a _real_ wakeup.
> > 
> > We fundamentally cannot know, on the wake side, if the wait side has or
> > has not observed cond, and therefore the distinction you're trying to
> > make is a false one.
> 
> I believe you may be misunderstanding Dongsheng. It has nothing to do
> with the wake condition. But the "success" is basically saying, "did I
> move the task on to the run queue?". That's a relevant piece of
> information that the wake up event isn't currently showing.
> 
> Let me ask you this; with Donsheng's patch, will there ever be a
> sched_switch event when the wakeup event sees 'false' and the
> sched_switch event see the task with a state other than "R"? And if so,
> how did the task doing the wakeup event, wake up that task?

But that has nothing what so fucking ever to do with 'success'. Reusing
that trace argument for something entirely different is just retarded.

Content of type "application/pgp-signature" skipped