[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiZnS6n1ROQg3FHd=bcVTHi-sKutKT+toiViQEH47ZACg@mail.gmail.com>
Date: Tue, 15 Mar 2022 09:48:19 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Mark Brown <broonie@...nel.org>,
linux-spi <linux-spi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SPI fixes for v5.17-rc7
On Tue, Mar 15, 2022 at 2:08 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> I had noticed while reviewing the patch, but changing to size_t wouldn't
> help much, as other related code paths treat the value as unsigned int
> anyway.
.. but it really would.
Note that the paths *after* this code don't matter. Because the result
is guaranteed to fit in 'unsigned int' anyway.
Put another way:
min_t(unsigned int,x,y)
is buggy if one of x/y is 'size_t'. Why? Because if that one gets
truncated, you're doing 'min()' with a value that may be artificially
much too small (that was exactly the problem commit 1a4e53d2fc4f:
"spi: Fix invalid sgs value")fixed).
But the situation is _not_ true in the reverse. Look:
min(size_t,x,y)
is guaranteed to fit in 'unsigned int' as long as _one_ of x,y fits in
'unsigned int' - even if the other doesn't. Because then 'min()' will
just pick the one that already had the right size.
To make it really concrete, compare
min_t(unsigned int, 5, 0x100000001);
min_t(size_t, 5, 0x100000001);
on a 64-bit machine (ie size_t is 64-bits, and unsigned int is 32-bit).
One returns 1. The other returns 5. Both fit the result in 'unsigned
int', but one of them is wrong.
Linus
Powered by blists - more mailing lists