Hi Nathan,
On 02/10/2024 17:22, Nathan Chancellor wrote:
Hi Andrej,
On Wed, Oct 02, 2024 at 04:12:17PM +0200, Andrej Shadura wrote:
Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main:
len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build.
The same issue occurs in rfcomm in functions rfcomm_sock_bind and rfcomm_sock_getsockopt_old.
Was this found by inspection or is there an actual instance of the same warning? For what it's worth, I haven't seen a warning from this file in any of my build tests.
We’ve seen build errors in rfcomm in the Chromium OS 4.14 kernel.
Change the type of len to size_t in both rfcomm_sock_bind and rfcomm_sock_getsockopt_old and replace min_t() with min().
Cc: stable@vger.kernel.org Fixes: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()")
I am not sure that I totally agree with this Fixes tag since I did not have a warning to fix but I guess it makes sense to help with backporting.
It’s a shame there isn’t a Complements: or Improves: tag :)