From: Matthew Wilcox <willy@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Kees Cook <kees@kernel.org>, Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
"Gustavo A . R . Silva" <gustavoars@kernel.org>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Jann Horn <jannh@google.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Marco Elver <elver@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
linux-mm@kvack.org, Randy Dunlap <rdunlap@infradead.org>,
Miguel Ojeda <ojeda@kernel.org>,
Vegard Nossum <vegard.nossum@oracle.com>,
Harry Yoo <harry.yoo@oracle.com>,
Nathan Chancellor <nathan@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Jakub Kicinski <kuba@kernel.org>,
Yafang Shao <laoar.shao@gmail.com>,
Tony Ambardar <tony.ambardar@gmail.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Jan Hendrik Farr <kernel@jfarr.cc>,
Alexander Potapenko <glider@google.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-doc@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v5 2/4] slab: Introduce kmalloc_obj() and family
Date: Tue, 25 Nov 2025 01:09:42 +0000 [thread overview]
Message-ID: <aSUB1qrfhXp3suGn@casper.infradead.org> (raw)
In-Reply-To: <CAHk-=wgn-2ieKtaHAXLLge1UFckLKa88vo3XOdLz+fP+DLpHGA@mail.gmail.com>
On Mon, Nov 24, 2025 at 03:30:19PM -0800, Linus Torvalds wrote:
> That all a very standard thing in assembly programming, which this is
> all about. 'entry' is a signed offset from its own address.
I used to be an assembly programmer ... 28 years ago. I've mostly put
that world out of my mind (and being able to write a 20,000 instruction
ARM32 program entirely in assembly is just not that useful an
accomplishment to put on my CV). Anyway, this isn't the point ...
> > The warning is ... not the best phrased, but in terms of divining the
> > programmer's intent, I genuinely don't know if this code is supposed
> > to zero-extend or sign-extend the s32 to unsigned long.
>
> What?
>
> A signed value gets sign-extended when cast to a larger type. That's
> how all of this always works. Casting a signed value to 'unsigned
> long' will set the high bits in the result.
>
> That's pretty much the *definition* of a signed value. It gets
> sign-extended when used, and then obviously it becomes a large
> unsigned value, but this is how two's complement addition
> fundamentally works.
Yes, agreed.
> So honestly, what's the problem with this code?
>
> The warning makes no sense, and is garbage. Are we not allowed to add
> signed integers to unsigned 64-bit values now, because that addition
> involves that cast of a signed 32-bit entry to an unsigned 64-bit one?
>
> There is NO WAY that warning is valid, it's; not *ever* something we
> should enable, and the fact that you people are discussing it as such
> is just crazy.
>
> That code would not be improved at all by adding another cast (to
> first cast that s32 to 'long', in order to then add it to 'unsigned
> long').
>
> Imagine how many other places you add integers to 'unsigned long'.
> EVERY SINGLE ONE of those places involves sign-extending the integer
> and then doing arithmetic in unsigned.
I have bad news. Rust requires it.
fn add(base: u64, off: i32) -> u64 {
base + off
}
error[E0308]: mismatched types
--> add.rs:2:12
|
2 | base + off
| ^^^ expected `u64`, found `i32`
error[E0277]: cannot add `i32` to `u64`
--> add.rs:2:10
|
2 | base + off
| ^ no implementation for `u64 + i32`
|
= help: the trait `Add<i32>` is not implemented for `u64`
= help: the following other types implement trait `Add<Rhs>`:
<u64 as Add>
<u64 as Add<&u64>>
<&'a u64 as Add<u64>>
<&u64 as Add<&u64>>
so the Rust language people have clearly decided that this is too
complicated for your average programmer to figure out, and you need
explicit casts to make it work.
next prev parent reply other threads:[~2025-11-25 1:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 1:42 [PATCH v5 0/4] slab: Introduce kmalloc_obj() and family Kees Cook
2025-11-22 1:42 ` [PATCH v5 1/4] compiler_types: Introduce __flex_counter() " Kees Cook
2025-11-22 1:42 ` [PATCH v5 2/4] slab: Introduce kmalloc_obj() " Kees Cook
2025-11-22 19:53 ` Linus Torvalds
2025-11-22 20:54 ` Linus Torvalds
2025-11-24 20:38 ` Kees Cook
2025-11-24 21:12 ` Matthew Wilcox
2025-11-24 21:20 ` Kees Cook
2025-11-24 21:33 ` Matthew Wilcox
2025-11-24 21:44 ` Matthew Wilcox
2025-11-24 21:50 ` Kees Cook
2025-11-24 23:30 ` Linus Torvalds
2025-11-25 1:09 ` Matthew Wilcox [this message]
2025-11-25 3:47 ` Kees Cook
2025-11-25 11:54 ` david laight
2025-11-24 21:35 ` Linus Torvalds
2025-11-25 0:29 ` Kees Cook
2025-11-25 1:25 ` Linus Torvalds
2025-11-22 1:42 ` [PATCH v5 3/4] checkpatch: Suggest kmalloc_obj family for sizeof allocations Kees Cook
2025-11-22 4:51 ` Joe Perches
2025-11-22 1:43 ` [PATCH v5 4/4] coccinelle: Add kmalloc_objs conversion script Kees Cook
2025-11-24 12:50 ` [cocci] " Markus Elfring
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=aSUB1qrfhXp3suGn@casper.infradead.org \
--to=willy@infradead.org \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavoars@kernel.org \
--cc=harry.yoo@oracle.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kuba@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=sashal@kernel.org \
--cc=tony.ambardar@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=vegard.nossum@oracle.com \
/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;
as well as URLs for NNTP newsgroup(s).