linux-kernel - Re: trace: fix task state printout

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: <20081218120140.GC21123@elte.hu>
Date:	Thu, 18 Dec 2008 13:01:40 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>,
	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: trace: fix task state printout


* Steven Rostedt <rostedt@...dmis.org> wrote:

> 
> On Wed, 17 Dec 2008, Thomas Gleixner wrote:
> 
> > Impact: tracer task state decoding is wrong, size check is buggy
> 
> The Imact line seems more of a subject line. The real Impact line should 
> be something like:
> 
> Impact: fix wrong decoding of task state int tracer
> 
> Keyword is 'fix'
> 
> > 
> > The tracing code has interesting varieties of printing out task state. 
> > Unfortunalely only one of the instances is correct as it copies the 
> > code from sched.c:sched_show_task(). The others are plain wrong as 
> > they treatthe bitfield as an integer offset into the character array. 
> > Also the size check of the character array is wrong as it includes the 
> > trailing \0.
> > 
> > Use a common state decoder inline which does the Right Thing.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> 
> Acked-by: Steven Rostedt <srostedt@...hat.com>
> 
> Ingo, this is a low risk fix that probably should be pushed towards 
> Linus for inclusion into 2.6.28.

ok, we can do that after a few days of testing.

Btw., note that when capturing traces via trace_pipe, i still see frequent 
mistakes of PIDs being matched up to the wrong 'comm' string

 loop-1sec-2895 ...
      Xorg-2895 ...

the Xorg-2895 is bogus. I have been seeing these for a long time and 
thought we fixed it, but i noticed them yesterday once more, while i was 
tracing some code. Any ideas about what's wrong there?

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