From: David Laight <david.laight.linux@gmail.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org, io-uring@vger.kernel.org
Subject: Re: [PATCH 04/44] io_uring/net: Change some dubious min_t()
Date: Thu, 20 Nov 2025 15:48:17 +0000 [thread overview]
Message-ID: <20251120154817.0160eeac@pumpkin> (raw)
In-Reply-To: <3202c47d-532d-4c74-aff9-992ec1d9cbeb@kernel.dk>
On Thu, 20 Nov 2025 07:48:58 -0700
Jens Axboe <axboe@kernel.dk> wrote:
> On 11/19/25 3:41 PM, david.laight.linux@gmail.com wrote:
> > From: David Laight <david.laight.linux@gmail.com>
> >
> > Since iov_len is 'unsigned long' it is possible that the cast
> > to 'int' will change the value of min_t(int, iov[nbufs].iov_len, ret).
> > Use a plain min() and change the loop bottom to while (ret > 0) so that
> > the compiler knows 'ret' is always positive.
> >
> > Also change min_t(int, sel->val, sr->mshot_total_len) to a simple min()
> > since sel->val is also long and subject to possible trunctation.
> >
> > It might be that other checks stop these being problems, but they are
> > picked up by some compile-time tests for min_t() truncating values.
>
> Fails with clang-21:
>
> io_uring/net.c:855:26: error: call to '__compiletime_assert_2006' declared with 'error' attribute: min(sel->val, sr->mshot_total_len) signedness error
> 855 | sr->mshot_total_len -= min(sel->val, sr->mshot_total_len);
I'll take a look, I normally use gcc but there must be something subtle going on.
Actually which architecture?
I only tested x86-64.
David
> | ^
> ./include/linux/minmax.h:105:19: note: expanded from macro 'min'
> 105 | #define min(x, y) __careful_cmp(min, x, y)
> | ^
> ./include/linux/minmax.h:98:2: note: expanded from macro '__careful_cmp'
> 98 | __careful_cmp_once(op, x, y, __UNIQUE_ID(x_), __UNIQUE_ID(y_))
> | ^
> ./include/linux/minmax.h:93:2: note: expanded from macro '__careful_cmp_once'
> 93 | BUILD_BUG_ON_MSG(!__types_ok(ux, uy), \
> | ^
> note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
> ././include/linux/compiler_types.h:590:2: note: expanded from macro '_compiletime_assert'
> 590 | __compiletime_assert(condition, msg, prefix, suffix)
> | ^
> ././include/linux/compiler_types.h:583:4: note: expanded from macro '__compiletime_assert'
> 583 | prefix ## suffix(); \
> | ^
> <scratch space>:319:1: note: expanded from here
> 319 | __compiletime_assert_2006
> | ^
>
next prev parent reply other threads:[~2025-11-20 15:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 22:40 [PATCH 00/44] Change a lot of min_t() that might mask high bits david.laight.linux
2025-11-19 22:41 ` [PATCH 04/44] io_uring/net: Change some dubious min_t() david.laight.linux
2025-11-20 14:48 ` Jens Axboe
2025-11-20 15:48 ` David Laight [this message]
2025-11-20 15:53 ` Jens Axboe
2025-11-22 11:31 ` David Laight
2025-11-20 1:47 ` [PATCH 00/44] Change a lot of min_t() that might mask high bits Jakub Kicinski
2025-11-20 9:38 ` Lorenzo Stoakes
2025-11-20 14:52 ` (subset) " Jens Axboe
2025-11-24 9:49 ` Herbert Xu
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=20251120154817.0160eeac@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox