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: <20140512150950.GP30445@twins.programming.kicks-ass.net>
Date:	Mon, 12 May 2014 17:09:50 +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 Mon, May 12, 2014 at 10:09:08AM -0400, Steven Rostedt wrote:
> On Mon, 12 May 2014 08:47:30 +0200
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> 
> > But that has nothing what so fucking ever to do with 'success'. Reusing
> > that trace argument for something entirely different is just retarded.
> 
> And having a "success" field that his hard coded to "true" is also
> retarded. At least this change is fucking useful.

You know why that's there :/ And yes, I started hating tracepoints a lot
more ever since that happened.

> How about this. Add a new field called 'rq_added' or something. We can
> ever shrink the size of the "success" field and hard code it to true in
> the trace. That will never change. Then the caller of the tracepoint
> will send in a "true" or "false" to "rq_added" and we can add that
> tracepoint as well.
> 
> What I mean by shrink the size of the success field is that it is
> currently 4 bytes in size. We can make it two (or one) and then add
> another field for the 'rq_added' and have that be two bytes as well.
> This shouldn't break any tools that use this.
> 
> Point being, this is useful information, why not pass it to userspace?

Because it adds code to one of the hottest code paths in the kernel and
so far nobody had a sane explanation of WTF they were doing.


Content of type "application/pgp-signature" skipped