linux-kernel - Re: [PATCH 1/2] sched: Fix "divide error: 0000" in find_busiest

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: <1311114621.2617.7.camel@laptop>
Date:	Wed, 20 Jul 2011 00:30:21 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Terry Loftin <terry.loftin@...com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Bob Montgomery <bob.montgomery@...com>
Subject: Re: [PATCH 1/2] sched: Fix "divide error: 0000" in
 find_busiest_group

On Tue, 2011-07-19 at 16:20 -0600, Terry Loftin wrote:
> On 07/19/2011 03:17 PM, Peter Zijlstra wrote:
> > On Tue, 2011-07-19 at 14:58 -0600, Terry Loftin wrote:
> >> Correct the protection expression in update_cpu_power() to avoid setting
> >> rq->cpu_power to zero.
> > 
> > Firstly you fail to mention what kernel this is again, secondly this
> > should never happen in the first place, so this fix is wrong. At best it
> > papers over another bug.
> 
> My Apologies, this was found on kernel 2.6.32.32, but the all
> the related code is the same in v3.0-rc7.  The patch is against
> v3.0-rc7.  I've done some limited testing of this on 2.6.32.32
> by modifying __cycles_2_ns() to add an offset to the TSC when
> it is read to simulate 208 days of uptime, but that kernel has
> only been running for a couple days.
> 
> I also agree this should never happen.  As the statement currently
> stands, it won't work - so it should either be corrected or removed.
> Here is the alternative patch:
> 

> -	if (!power)
> -		power = 1;

IIRC it can actually end up being 0 if the scale factors are small
enough, but what I couldn't see happening is how it can be > 2^32, which
is required for your initial patch to make a difference.

In that case the scale factors were _way_ out of bound, they're supposed
to be [0,SCHED_POWER_SCALE] and since we divide by SCHED_POWER_SCALE
after every factor the result should remain in that range.

Now clearly you've found that going haywire, so we need to find where
and why that happens and cure that.

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