linux-kernel - Re: sched/cputime: sig->prev

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]

Date:	Tue, 16 Apr 2013 13:06:51 +0200
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Dave Hansen <dave@...1.net>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Subject: Re: sched/cputime: sig->prev_stime underflow

On Thu, Apr 11, 2013 at 11:47:37AM -0700, Dave Hansen wrote:
> On 04/11/2013 12:45 AM, Stanislaw Gruszka wrote:
> > On Mon, Apr 08, 2013 at 08:57:16AM -0700, Dave Hansen wrote:
> >> On 04/04/2013 04:41 PM, Frederic Weisbecker wrote:
> >>> Does this patch fix the issue for you?
> >>> https://lkml.org/lkml/2013/4/4/112
> >>
> >> Nope, that doesn't seem to make a difference.  I'm still seeing the
> >> underflow.  I'm pretty sure it's already gone to hell by the time it
> >> gets in to the loop that's patched there.
> > 
> > Perhaps this is glich introduced by commit 
> > 62188451f0d63add7ad0cd2a1ae269d600c1663d "cputime: Avoid multiplication
> > overflow on utime scaling" . Could you try to revert it and see if that
> > helps. If it does not, can you check if problem happen on 3.8 ?
> 
> I'll run a bit longer, but reverting
> 62188451f0d63add7ad0cd2a1ae269d600c1663d _does_ seem to make it happier.

Hmm, I supposed glitch in this commit because it something that was
changed recently and previously we did not have such bug reports. But
I do not see mistake there. Basically prev->stime should never be
bigger than rtime, since at any moment stime <= rtime and previous
rtime <= current rtime. So this looks like rtime decrease and for
some reason before 62188451f0d it does not manifest as a bug.

It can be fixed by comparing prev->stime < rtime or by something
like first attached patch. Not sure what will be better.

But since this (most likely) is rtime monotonicity problem it
is bug by itself and probably that should be fixed. Can you 
check second patch attached and see if it trigger the warning.

Note patches are not tested, I expect you'll fix them if they
do not do what expected :-)

Thanks
Stanislaw

View attachment "cputime_adjust_modify.patch" of type "text/plain" (1077 bytes)

View attachment "check_rtime.patch" of type "text/plain" (1118 bytes)