From: Masahiro Yamada <masahiroy@kernel.org> To: Dan Carpenter <dan.carpenter@oracle.com> Cc: Colin King <colin.king@canonical.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, linux-clk <linux-clk@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, kernel-janitors@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] clk: uniphier: Fix potential infinite loop Date: Fri, 16 Apr 2021 11:53:07 +0900 [thread overview] Message-ID: <CAK7LNATySocPRr4BdaKr5_GZ=G4tQYgPQEDe0piiTS_qiWawkA@mail.gmail.com> (raw) In-Reply-To: <20210415181850.GD6021@kadam> On Fri, Apr 16, 2021 at 3:19 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > On Fri, Apr 09, 2021 at 03:46:47PM +0900, Masahiro Yamada wrote: > > On Thu, Apr 8, 2021 at 12:25 AM Colin King <colin.king@canonical.com> wrote: > > > > > > From: Colin Ian King <colin.king@canonical.com> > > > > > > The for-loop iterates with a u8 loop counter i and compares this > > > with the loop upper limit of num_parents that is an int type. > > > There is a potential infinite loop if num_parents is larger than > > > the u8 loop counter. Fix this by making the loop counter the same > > > type as num_parents. > > > > > > Addresses-Coverity: ("Infinite loop") > > > Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver") > > > Signed-off-by: Colin Ian King <colin.king@canonical.com> > > > --- > > > drivers/clk/uniphier/clk-uniphier-mux.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c > > > index 462c84321b2d..ce219e0d2a85 100644 > > > --- a/drivers/clk/uniphier/clk-uniphier-mux.c > > > +++ b/drivers/clk/uniphier/clk-uniphier-mux.c > > > @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw) > > > int num_parents = clk_hw_get_num_parents(hw); > > > int ret; > > > unsigned int val; > > > - u8 i; > > > + int i; > > > > > > ret = regmap_read(mux->regmap, mux->reg, &val); > > > if (ret) > > > -- > > > 2.30.2 > > > > > > > clk_hw_get_num_parents() returns 'unsigned int', so > > I think 'num_parents' should also have been 'unsigned int'. > > > > Maybe, the loop counter 'i' also should be 'unsigned int' then? > > The clk_hw_get_num_parents() function returns 0-255 so the original code > works fine. True. clk->core->num_parents is u8, but it is not clear just by looking at the prototype of clk_hw_get_num_parents(). At least, it is not clear enough for tools, and actually Coverity raised a flag. Personally, I prefer 'unsigned int' (or 'int') when I count the number of something. Historically, the clk subsystem uses u8, (maybe to save memory??), and there exists distortion. For example, the return type of uniphier_clk_mux_get_parent() is u8, but it actually returns -EINVAL for error cases. So, u8 is not wide enough, in my opinion. > > It should basically always be "int i;" That's the safest assumption. > There are other case where it has to be size_t but in those cases I > think people should call the list iterator something else instead of "i" > like "size_t pg_idx;". > > Making everthing u32 causes more bugs than it prevents. Signedness bugs > with comparing to zero, type promotion bugs, or subtraction bugs where > subtracting wraps to a high value. It's rare to loop more than INT_MAX > times in the kernel. When we do need to count about 2 million then > we're probably not going to stop counting at 4 million, we're going to > go to 10 million or higher so size_t is more appropriate than u32. > > Btw, if you have a loop that does: > > for (i = 0; i < UINT_MAX; i++) { > > that loop works exactly the same if "i" is an int or if it's a u32 > because of type promotion. You are right. Perhaps, in hindsight, the following were natural: unsigned int num_parents = clk_hw_get_num_parents(hw); ... int i; I am fine with this if it is not too late. But, Stephen has already picked up this patch. > So you have to look really hard to find a > place where changing a loop iterator from int to u32 fixes bug in real > life. > > regards, > dan carpenter -- Best Regards Masahiro Yamada
WARNING: multiple messages have this Message-ID (diff)
From: Masahiro Yamada <masahiroy@kernel.org> To: Dan Carpenter <dan.carpenter@oracle.com> Cc: Colin King <colin.king@canonical.com>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, linux-clk <linux-clk@vger.kernel.org>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, kernel-janitors@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] clk: uniphier: Fix potential infinite loop Date: Fri, 16 Apr 2021 11:53:07 +0900 [thread overview] Message-ID: <CAK7LNATySocPRr4BdaKr5_GZ=G4tQYgPQEDe0piiTS_qiWawkA@mail.gmail.com> (raw) In-Reply-To: <20210415181850.GD6021@kadam> On Fri, Apr 16, 2021 at 3:19 AM Dan Carpenter <dan.carpenter@oracle.com> wrote: > > On Fri, Apr 09, 2021 at 03:46:47PM +0900, Masahiro Yamada wrote: > > On Thu, Apr 8, 2021 at 12:25 AM Colin King <colin.king@canonical.com> wrote: > > > > > > From: Colin Ian King <colin.king@canonical.com> > > > > > > The for-loop iterates with a u8 loop counter i and compares this > > > with the loop upper limit of num_parents that is an int type. > > > There is a potential infinite loop if num_parents is larger than > > > the u8 loop counter. Fix this by making the loop counter the same > > > type as num_parents. > > > > > > Addresses-Coverity: ("Infinite loop") > > > Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver") > > > Signed-off-by: Colin Ian King <colin.king@canonical.com> > > > --- > > > drivers/clk/uniphier/clk-uniphier-mux.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/clk/uniphier/clk-uniphier-mux.c b/drivers/clk/uniphier/clk-uniphier-mux.c > > > index 462c84321b2d..ce219e0d2a85 100644 > > > --- a/drivers/clk/uniphier/clk-uniphier-mux.c > > > +++ b/drivers/clk/uniphier/clk-uniphier-mux.c > > > @@ -34,7 +34,7 @@ static u8 uniphier_clk_mux_get_parent(struct clk_hw *hw) > > > int num_parents = clk_hw_get_num_parents(hw); > > > int ret; > > > unsigned int val; > > > - u8 i; > > > + int i; > > > > > > ret = regmap_read(mux->regmap, mux->reg, &val); > > > if (ret) > > > -- > > > 2.30.2 > > > > > > > clk_hw_get_num_parents() returns 'unsigned int', so > > I think 'num_parents' should also have been 'unsigned int'. > > > > Maybe, the loop counter 'i' also should be 'unsigned int' then? > > The clk_hw_get_num_parents() function returns 0-255 so the original code > works fine. True. clk->core->num_parents is u8, but it is not clear just by looking at the prototype of clk_hw_get_num_parents(). At least, it is not clear enough for tools, and actually Coverity raised a flag. Personally, I prefer 'unsigned int' (or 'int') when I count the number of something. Historically, the clk subsystem uses u8, (maybe to save memory??), and there exists distortion. For example, the return type of uniphier_clk_mux_get_parent() is u8, but it actually returns -EINVAL for error cases. So, u8 is not wide enough, in my opinion. > > It should basically always be "int i;" That's the safest assumption. > There are other case where it has to be size_t but in those cases I > think people should call the list iterator something else instead of "i" > like "size_t pg_idx;". > > Making everthing u32 causes more bugs than it prevents. Signedness bugs > with comparing to zero, type promotion bugs, or subtraction bugs where > subtracting wraps to a high value. It's rare to loop more than INT_MAX > times in the kernel. When we do need to count about 2 million then > we're probably not going to stop counting at 4 million, we're going to > go to 10 million or higher so size_t is more appropriate than u32. > > Btw, if you have a loop that does: > > for (i = 0; i < UINT_MAX; i++) { > > that loop works exactly the same if "i" is an int or if it's a u32 > because of type promotion. You are right. Perhaps, in hindsight, the following were natural: unsigned int num_parents = clk_hw_get_num_parents(hw); ... int i; I am fine with this if it is not too late. But, Stephen has already picked up this patch. > So you have to look really hard to find a > place where changing a loop iterator from int to u32 fixes bug in real > life. > > regards, > dan carpenter -- Best Regards Masahiro Yamada _______________________________________________ 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:[~2021-04-16 2:54 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-07 15:24 [PATCH] clk: uniphier: Fix potential infinite loop Colin King 2021-04-07 15:24 ` Colin King 2021-04-09 6:46 ` Masahiro Yamada 2021-04-09 6:46 ` Masahiro Yamada 2021-04-09 8:42 ` Colin Ian King 2021-04-09 8:42 ` Colin Ian King 2021-04-15 18:18 ` Dan Carpenter 2021-04-15 18:18 ` Dan Carpenter 2021-04-16 2:53 ` Masahiro Yamada [this message] 2021-04-16 2:53 ` Masahiro Yamada
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='CAK7LNATySocPRr4BdaKr5_GZ=G4tQYgPQEDe0piiTS_qiWawkA@mail.gmail.com' \ --to=masahiroy@kernel.org \ --cc=colin.king@canonical.com \ --cc=dan.carpenter@oracle.com \ --cc=kernel-janitors@vger.kernel.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=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: linkBe 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.