[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH-r-ZH+0rsji1f9eEaVDtG3XcMCD_EnAHAMwr8DuqO4D4Ps=w@mail.gmail.com>
Date: Thu, 28 Aug 2025 20:38:20 +0800
From: 林妙倩 <linmq006@...il.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Thomas Gleixner <tglx@...utronix.de>, Grygorii Strashko <grygorii.strashko@...com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] net: ethernet: ti: Prevent divide-by-zero in cpts_calc_mult_shift()
Hi, Vadim
Vadim Fedorenko <vadim.fedorenko@...ux.dev> 于2025年8月28日周四 20:06写道:
>
> On 28/08/2025 10:22, Miaoqian Lin wrote:
> > cpts_calc_mult_shift() has a potential divide-by-zero in this line:
> >
> > do_div(maxsec, freq);
> >
> > due to the fact that clk_get_rate() can return zero in certain error
> > conditions.
>
> Have you seen this happening in the real environment, or is it just
> analysis of the code? I don't see a reason for these "certain error
> conditions" to happen...
This is from code analysis, not from real environment.
The !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK could have the problem.
This may be theoretical.
Powered by blists - more mailing lists