linux-kernel - Re: divide by zero bug 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: <AANLkTikg7Q_oOecNgVLPPTu3dOu3aO776f4y1bw410PV@mail.gmail.com>
Date:	Thu, 26 Aug 2010 16:52:27 -0700
From:	Chetan Ahuja <chetan.ahuja@...il.com>
To:	Venkatesh Pallipadi <venki@...gle.com>
Cc:	linux-kernel@...r.kernel.org,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: divide by zero bug in find_busiest_group

On Thu, Aug 26, 2010 at 12:19 PM, Venkatesh Pallipadi <venki@...gle.com> wrote:
> On Wed, Aug 25, 2010 at 6:17 PM, Chetan Ahuja <chetan.ahuja@...il.com> wrote:

> I tried reproducing the problem with vanilla kernel and couldn't
> reproduce it. May be your workload is triggering this some how?
> Also, Suresh did recent fixes to rt_avg and this may not be a problem
> after that. I Haven't looked at this case closely after that recent
> change.
>
> Thanks,
> Venki
>

Venkatesh,

     Thanks for your detailed response. I admit complete ignorance of
the actual logic of the complicated cpu_power computations (or indeed,
any other part of the scheduler code). I'm just looking at it from the
perspective of bug-hunting in an unfamiliar piece of code. I think the
three ways we've so far identified the cpu_power can be zero so far
(all three would be extremely low probability events admittedly) are
warning signs that the code is trying to do  a bit too much. It seems
to be rather difficult to prove  correctness of the math or the
synchronization for my taste. Is there a clear and present use-case
which driving all these complicated computations ?

 For one thing, I don't understand the reason for recomputing
cpu_power dynamically. How does cpu_power of a gorup (which I believe
refers to the group of "hyper-threaded" cores on one physical core)
change while inthe system is in operation ? Is this in support of
hot-swappable CPU's or something ?

  To be honest, for my use case, I'd  like to just disable the whole
work-stealing stuff (referred to as load-balancing in the kernel).
There seems to be no config option that isolates just the dynamic
load-balancing parts (or is there ?) so maybe I'd just hack away the
load-balancing functions by hand so as never to worry about those
denominators again.

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