linux-kernel - Re: s2r badness

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: <alpine.DEB.2.00.0907201948050.6743@gandalf.stny.rr.com>
Date:	Mon, 20 Jul 2009 19:51:25 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Peter Zijlstra <peterz@...radead.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Len Brown <lenb@...nel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: s2r badness

On Tue, 21 Jul 2009, Thomas Gleixner wrote:

> On Mon, 20 Jul 2009, Steven Rostedt wrote:
> > >  
> > > Just to make the list more complete. If tracing is enabled across
> > > suspend/resume you'll hit that one as well:
> > > 
> > > WARNING: at /home/tglx/work/kernel/git/linux-2.6/kernel/trace/ring_buffer.c:1392 rb_reserve_next_event+0x133/0x27c()
> > > 
> > > Negative timestamp delta which is probably due to sched_clock not yet
> > > adjusted to the TSC which got reset.
> > 
> > Perhaps we need to prevent tracing during a "blackout period" of suspend 
> > to ram?
> 
> Perhaps we need to figure out why this is happening and how we best
> deal with it. Disabling functionality just because we can not deal
> with it right now is not a solution.

Heh, suspend to ram is a black magic art. There's voodoo there that causes 
ulcers when you look the wrong way. For example, there's times that simply 
calling smp_processor_id() will reboot the box. Hence, the tracer is very 
intrusive, and we need to prevent it from doing things at certain areas. 
I'm not saying disabling functionality per say, I'm just saying that we 
need to make sure the tracer is not doing something in the guts of 
bringing the CPU back on line when it is not ready.

Are you saying that we need to move the initialization of sched_clock up, 
just to satisfy tracing? If that happens to be the issues here?

-- Steve

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