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: <20180905082301.131e1967@gandalf.local.home>
Date:   Wed, 5 Sep 2018 08:23:01 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, Ingo Molnar <mingo@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH] sched/debug: use symbolic names for task state
 constants

On Wed, 5 Sep 2018 13:25:24 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Sep 05, 2018 at 11:36:36AM +0200, Uwe Kleine-König wrote:
> > include/trace/events/sched.h includes <linux/sched.h> (via
> > <linux/sched/numa_balancing.h>) and so knows about the TASK_* constants
> > used to interpret .prev_state. So instead of duplicating the magic
> > numbers make use of the defined macros to ease understanding the
> > mapping from state bits to letters which isn't completely intuitive for
> > an outsider.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> > ---
> >  include/trace/events/sched.h | 11 ++++++++---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> > index 0be866c91f62..f07b270d4fc4 100644
> > --- a/include/trace/events/sched.h
> > +++ b/include/trace/events/sched.h
> > @@ -159,9 +159,14 @@ TRACE_EVENT(sched_switch,
> >  
> >  		(__entry->prev_state & (TASK_REPORT_MAX - 1)) ?
> >  		  __print_flags(__entry->prev_state & (TASK_REPORT_MAX - 1), "|",
> > -				{ 0x01, "S" }, { 0x02, "D" }, { 0x04, "T" },
> > -				{ 0x08, "t" }, { 0x10, "X" }, { 0x20, "Z" },
> > -				{ 0x40, "P" }, { 0x80, "I" }) :
> > +				{ TASK_INTERRUPTIBLE, "S" },
> > +				{ TASK_UNINTERRUPTIBLE, "D" },
> > +				{ __TASK_STOPPED, "T" },
> > +				{ __TASK_TRACED, "t" },
> > +				{ EXIT_DEAD, "X" },
> > +				{ EXIT_ZOMBIE, "Z" },
> > +				{ TASK_PARKED, "P" },
> > +				{ TASK_DEAD, "I" }) :
> >  		  "R",  
> 
> Steve, does this work?

As long as the text is preprocessor macros (which they appear to be),
then yeah, this shouldn't cause any harm. If they were enums, then it
would require a little more work.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ