Re: [PATCH] clk: mvebu: Prevent division by zero in clk_double_div_recalc_rate()
From: Andrew Lunn <andrew@lunn.ch>
Date: 2024-09-09 14:02:17
Also in:
linux-clk, lkml
On Mon, Sep 09, 2024 at 04:38:07PM +0300, Alexandra Diupina wrote:
quoted hunk ↗ jump to hunk
get_div() may return zero, so it is necessary to check before calling DIV_ROUND_UP_ULL(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8ca4746a78ab ("clk: mvebu: Add the peripheral clock driver for Armada 3700") Signed-off-by: Alexandra Diupina <redacted> --- drivers/clk/mvebu/armada-37xx-periph.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)diff --git a/drivers/clk/mvebu/armada-37xx-periph.c b/drivers/clk/mvebu/armada-37xx-periph.c index 8701a58a5804..d0e1d591e4f2 100644 --- a/drivers/clk/mvebu/armada-37xx-periph.c +++ b/drivers/clk/mvebu/armada-37xx-periph.c@@ -343,7 +343,10 @@ static unsigned long clk_double_div_recalc_rate(struct clk_hw *hw, div = get_div(double_div->reg1, double_div->shift1); div *= get_div(double_div->reg2, double_div->shift2); - return DIV_ROUND_UP_ULL((u64)parent_rate, div); + if (!div) + return 0;
Looking at this code, it seems to me some fundamental assumption has gone wrong here, if the dividers are 0. We want to know about this, and a kernel taking a / 0 exception would be a good way to indicate something is very wrong. Won't returning 0 just hide the problem, not make it obvious? Checking for a /0 on user input makes a lot of sense, but here, i think you are just hiding bugs. Please consider this when making similar changes in other parts of the kernel. Why has a /0 happened? Tools like SVACE just point at possible problems. You then need to look at them in detail, understand the context, and decide on the proper fix, which might actually be, a /0 is good. Andrew