linux-kernel - Re: [lvc-project] [PATCH v3] clk: mvebu: Prevent division by zero in clk_double_div_recalc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20241009-fc03180437255c79b67ad576-pchelkin@ispras.ru>
Date: Wed, 9 Oct 2024 16:43:27 +0300
From: Fedor Pchelkin <pchelkin@...ras.ru>
To: Andrew Lunn <andrew@...n.ch>, Stephen Boyd <sboyd@...nel.org>
Cc: lvc-project@...uxtesting.org,
	Michael Turquette <mturquette@...libre.com>,
	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
	Gregory Clement <gregory.clement@...tlin.com>,
	linux-arm-kernel@...ts.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Alexandra Diupina <adiupina@...ralinux.ru>
Subject: Re: [lvc-project] [PATCH v3] clk: mvebu: Prevent division by zero in
 clk_double_div_recalc_rate()

On Wed, 09. Oct 14:23, Andrew Lunn wrote:
> > > I would say, let is divide by 0, so there is an obvious kernel stack
> > > trace and hopefully a report of the issue. It can then be investigated
> > > in a way we can then find out what the hardware actually is doing.
> > 
> > Is it worth adding some kind of WARN assertions? Or actually just leave it
> > for now as is?
> 
> What actually happens on a / 0 on ARM? I assume it triggers an
> exception, which will give a stack trace? If so a WARN adds no value.

Oh, I see. I should have better said "adding WARN assertions and bailing
out with a default value if they are violated". Thus avoiding to have a
division by zero exception. Non panic_on_warn systems would at least
survive in this case but still have a valuable trace.

Somehow more importantly, it would state in the codebase that the condition
is very-very unexpected and most probably won't ever happen but not 100%
sure because it depends on hardware behavior (as I perceive reading the
current thread).

That said, if adding such WARN-bail-out pattern seems unnecessary and just
wasteful in this situation, I don't think we have any options other than
keeping the code as is.