From: Remi Pommarel <repk@triplefau.lt>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clk: meson: pll: Fix by 0 division in __pll_params_to_rate()
Date: Sun, 15 Dec 2019 12:00:20 +0100 [thread overview]
Message-ID: <20191215110020.GA7304@voidbox> (raw)
In-Reply-To: <1jo8whesj2.fsf@starbuckisacylon.baylibre.com>
On Mon, Dec 09, 2019 at 10:51:13AM +0100, Jerome Brunet wrote:
>
> On Sun 08 Dec 2019 at 22:22, Remi Pommarel <repk@triplefau.lt> wrote:
>
> > Some meson pll registers can be initialized with 0 as N value, introducing
> > the following division by 0 when computing rate :
> >
> > UBSAN: Undefined behaviour in drivers/clk/meson/clk-pll.c:75:9
> > division by zero
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc3-608075-g86c9af8630e1-dirty #400
> > Call trace:
> > dump_backtrace+0x0/0x1c0
> > show_stack+0x14/0x20
> > dump_stack+0xc4/0x100
> > ubsan_epilogue+0x14/0x68
> > __ubsan_handle_divrem_overflow+0x98/0xb8
> > __pll_params_to_rate+0xdc/0x140
> > meson_clk_pll_recalc_rate+0x278/0x3a0
> > __clk_register+0x7c8/0xbb0
> > devm_clk_hw_register+0x54/0xc0
> > meson_eeclkc_probe+0xf4/0x1a0
> > platform_drv_probe+0x54/0xd8
> > really_probe+0x16c/0x438
> > driver_probe_device+0xb0/0xf0
> > device_driver_attach+0x94/0xa0
> > __driver_attach+0x70/0x108
> > bus_for_each_dev+0xd8/0x128
> > driver_attach+0x30/0x40
> > bus_add_driver+0x1b0/0x2d8
> > driver_register+0xbc/0x1d0
> > __platform_driver_register+0x78/0x88
> > axg_driver_init+0x18/0x20
> > do_one_initcall+0xc8/0x24c
> > kernel_init_freeable+0x2b0/0x344
> > kernel_init+0x10/0x128
> > ret_from_fork+0x10/0x18
> >
> > This checks if N is null before doing the division.
>
> Thanks for reporting this
>
> >
> > Fixes: 8289aafa4f36 ("clk: meson: improve pll driver results with
> > frac")
>
> In mainline, the commit above went in with sha1 3c4fe763d64d.
>
> Also, this commit is not really responsible for the problem. Having HW
> initialized with N = 0 would have failed since the beginning, I believe.
>
> In this case the correct fixes would be:
> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
>
>
> > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> > ---
> > drivers/clk/meson/clk-pll.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> > index ddb1e5634739..6649659f216a 100644
> > --- a/drivers/clk/meson/clk-pll.c
> > +++ b/drivers/clk/meson/clk-pll.c
> > @@ -66,6 +66,10 @@ static unsigned long __pll_params_to_rate(unsigned long parent_rate,
> > (1 << pll->frac.width));
> > }
> >
> > + /* Avoid by zero division */
> > + if (n == 0)
> > + return 0;
>
> This can only really happen after init, in recalc() rate.
>
> I would much prefer if you could check the n value right after it is
> read (meson_parm_read()) in .recalc_rate() and add a comment explaining
> that some HW may have this parameter set 0 on init.
>
Sure will do.
Thanks for reviewing this.
--
Remi
> > +
> > return DIV_ROUND_UP_ULL(rate, n);
> > }
>
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: Remi Pommarel <repk@triplefau.lt>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: meson: pll: Fix by 0 division in __pll_params_to_rate()
Date: Sun, 15 Dec 2019 12:00:20 +0100 [thread overview]
Message-ID: <20191215110020.GA7304@voidbox> (raw)
In-Reply-To: <1jo8whesj2.fsf@starbuckisacylon.baylibre.com>
On Mon, Dec 09, 2019 at 10:51:13AM +0100, Jerome Brunet wrote:
>
> On Sun 08 Dec 2019 at 22:22, Remi Pommarel <repk@triplefau.lt> wrote:
>
> > Some meson pll registers can be initialized with 0 as N value, introducing
> > the following division by 0 when computing rate :
> >
> > UBSAN: Undefined behaviour in drivers/clk/meson/clk-pll.c:75:9
> > division by zero
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc3-608075-g86c9af8630e1-dirty #400
> > Call trace:
> > dump_backtrace+0x0/0x1c0
> > show_stack+0x14/0x20
> > dump_stack+0xc4/0x100
> > ubsan_epilogue+0x14/0x68
> > __ubsan_handle_divrem_overflow+0x98/0xb8
> > __pll_params_to_rate+0xdc/0x140
> > meson_clk_pll_recalc_rate+0x278/0x3a0
> > __clk_register+0x7c8/0xbb0
> > devm_clk_hw_register+0x54/0xc0
> > meson_eeclkc_probe+0xf4/0x1a0
> > platform_drv_probe+0x54/0xd8
> > really_probe+0x16c/0x438
> > driver_probe_device+0xb0/0xf0
> > device_driver_attach+0x94/0xa0
> > __driver_attach+0x70/0x108
> > bus_for_each_dev+0xd8/0x128
> > driver_attach+0x30/0x40
> > bus_add_driver+0x1b0/0x2d8
> > driver_register+0xbc/0x1d0
> > __platform_driver_register+0x78/0x88
> > axg_driver_init+0x18/0x20
> > do_one_initcall+0xc8/0x24c
> > kernel_init_freeable+0x2b0/0x344
> > kernel_init+0x10/0x128
> > ret_from_fork+0x10/0x18
> >
> > This checks if N is null before doing the division.
>
> Thanks for reporting this
>
> >
> > Fixes: 8289aafa4f36 ("clk: meson: improve pll driver results with
> > frac")
>
> In mainline, the commit above went in with sha1 3c4fe763d64d.
>
> Also, this commit is not really responsible for the problem. Having HW
> initialized with N = 0 would have failed since the beginning, I believe.
>
> In this case the correct fixes would be:
> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
>
>
> > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> > ---
> > drivers/clk/meson/clk-pll.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> > index ddb1e5634739..6649659f216a 100644
> > --- a/drivers/clk/meson/clk-pll.c
> > +++ b/drivers/clk/meson/clk-pll.c
> > @@ -66,6 +66,10 @@ static unsigned long __pll_params_to_rate(unsigned long parent_rate,
> > (1 << pll->frac.width));
> > }
> >
> > + /* Avoid by zero division */
> > + if (n == 0)
> > + return 0;
>
> This can only really happen after init, in recalc() rate.
>
> I would much prefer if you could check the n value right after it is
> read (meson_parm_read()) in .recalc_rate() and add a comment explaining
> that some HW may have this parameter set 0 on init.
>
Sure will do.
Thanks for reviewing this.
--
Remi
> > +
> > return DIV_ROUND_UP_ULL(rate, n);
> > }
>
WARNING: multiple messages have this Message-ID (diff)
From: Remi Pommarel <repk@triplefau.lt>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] clk: meson: pll: Fix by 0 division in __pll_params_to_rate()
Date: Sun, 15 Dec 2019 12:00:20 +0100 [thread overview]
Message-ID: <20191215110020.GA7304@voidbox> (raw)
In-Reply-To: <1jo8whesj2.fsf@starbuckisacylon.baylibre.com>
On Mon, Dec 09, 2019 at 10:51:13AM +0100, Jerome Brunet wrote:
>
> On Sun 08 Dec 2019 at 22:22, Remi Pommarel <repk@triplefau.lt> wrote:
>
> > Some meson pll registers can be initialized with 0 as N value, introducing
> > the following division by 0 when computing rate :
> >
> > UBSAN: Undefined behaviour in drivers/clk/meson/clk-pll.c:75:9
> > division by zero
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc3-608075-g86c9af8630e1-dirty #400
> > Call trace:
> > dump_backtrace+0x0/0x1c0
> > show_stack+0x14/0x20
> > dump_stack+0xc4/0x100
> > ubsan_epilogue+0x14/0x68
> > __ubsan_handle_divrem_overflow+0x98/0xb8
> > __pll_params_to_rate+0xdc/0x140
> > meson_clk_pll_recalc_rate+0x278/0x3a0
> > __clk_register+0x7c8/0xbb0
> > devm_clk_hw_register+0x54/0xc0
> > meson_eeclkc_probe+0xf4/0x1a0
> > platform_drv_probe+0x54/0xd8
> > really_probe+0x16c/0x438
> > driver_probe_device+0xb0/0xf0
> > device_driver_attach+0x94/0xa0
> > __driver_attach+0x70/0x108
> > bus_for_each_dev+0xd8/0x128
> > driver_attach+0x30/0x40
> > bus_add_driver+0x1b0/0x2d8
> > driver_register+0xbc/0x1d0
> > __platform_driver_register+0x78/0x88
> > axg_driver_init+0x18/0x20
> > do_one_initcall+0xc8/0x24c
> > kernel_init_freeable+0x2b0/0x344
> > kernel_init+0x10/0x128
> > ret_from_fork+0x10/0x18
> >
> > This checks if N is null before doing the division.
>
> Thanks for reporting this
>
> >
> > Fixes: 8289aafa4f36 ("clk: meson: improve pll driver results with
> > frac")
>
> In mainline, the commit above went in with sha1 3c4fe763d64d.
>
> Also, this commit is not really responsible for the problem. Having HW
> initialized with N = 0 would have failed since the beginning, I believe.
>
> In this case the correct fixes would be:
> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
>
>
> > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> > ---
> > drivers/clk/meson/clk-pll.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
> > index ddb1e5634739..6649659f216a 100644
> > --- a/drivers/clk/meson/clk-pll.c
> > +++ b/drivers/clk/meson/clk-pll.c
> > @@ -66,6 +66,10 @@ static unsigned long __pll_params_to_rate(unsigned long parent_rate,
> > (1 << pll->frac.width));
> > }
> >
> > + /* Avoid by zero division */
> > + if (n == 0)
> > + return 0;
>
> This can only really happen after init, in recalc() rate.
>
> I would much prefer if you could check the n value right after it is
> read (meson_parm_read()) in .recalc_rate() and add a comment explaining
> that some HW may have this parameter set 0 on init.
>
Sure will do.
Thanks for reviewing this.
--
Remi
> > +
> > return DIV_ROUND_UP_ULL(rate, n);
> > }
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-12-15 10:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-08 21:22 [PATCH] clk: meson: pll: Fix by 0 division in __pll_params_to_rate() Remi Pommarel
2019-12-08 21:22 ` Remi Pommarel
2019-12-08 21:22 ` Remi Pommarel
2019-12-09 9:51 ` Jerome Brunet
2019-12-09 9:51 ` Jerome Brunet
2019-12-09 9:51 ` Jerome Brunet
2019-12-15 11:00 ` Remi Pommarel [this message]
2019-12-15 11:00 ` Remi Pommarel
2019-12-15 11:00 ` Remi Pommarel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191215110020.GA7304@voidbox \
--to=repk@triplefau.lt \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=narmstrong@baylibre.com \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.