From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EB3C214204; Mon, 20 Apr 2026 10:28:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776680900; cv=none; b=Nrk9UhgFXAxvYOrR1HJBXrE1pfZS+1134dILIm/oTdl/dYFkJZ9/DPAnH0Lt4eKsGGYKN6O1zYlu6/iXPbldGJWtWljc00bXYGByKAqAblpOJ3V9ycv+jTElth2QgdfbEtLazJkO/OTN1/oIaalZ0R62e5GgO6yWOY6gTKrkSME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776680900; c=relaxed/simple; bh=Ndln9vQTZpiFLL6wQKrdieqa21z6eByrPd0QvS1gFb8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mHeLGRNi7oeKown54CB+v6F2T2U68e9gQNoHeuONJItfYQhYx5Qf2Ge4TGvJtEUZ/f7/fsMbxY67rkis5UxRSVS3NLTFcp8siUxmfzt5cqOsUuK6Y6mScGftBh7DDCAzvAmLpY/+PNCk/en7T/iC8wYcLFSLVxJbh4035w01WMc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mMJaDPvY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mMJaDPvY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CDECC19425; Mon, 20 Apr 2026 10:28:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776680900; bh=Ndln9vQTZpiFLL6wQKrdieqa21z6eByrPd0QvS1gFb8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mMJaDPvYVyO7t3gR6EGUpa7cpPBZiqH7/ywZCh9nANqephTKzNzCl+wZ+YoewhE+B W09n9eyGn0HdRCoh6LxwpixOa9UYgRcwU7GNhCNUdcnwLslShTO0IDNYI1Jxj2DoDo +t0GKNhemcX3iNy2sz7kAg4xLdcRWaGguwrTcnoLnwVfNiGcyf6lVONN5vx65N2sDU 7LomD2dDKftkucHQ63ivJiRG3diRD7koZ9P961FAsFYlrt4/7NVnwd3+5a6TTZIGko FQGZJWWKYqIaARmVYEgOQySolBf8dX+qwpwHKT1V5HeG/4kF4RWS5aE19C4TJq1nG3 BJU5+XXuV5s/Q== Date: Mon, 20 Apr 2026 19:28:17 +0900 From: "Harry Yoo (Oracle)" To: Marco Elver Cc: Vlastimil Babka , Andrew Morton , Nathan Chancellor , Nicolas Schier , Dennis Zhou , Tejun Heo , Christoph Lameter , Hao Li , David Rientjes , Roman Gushchin , Kees Cook , "Gustavo A. R. Silva" , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Alexander Potapenko , Dmitry Vyukov , Nick Desaulniers , Bill Wendling , Justin Stitt , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, kasan-dev@googlegroups.com, llvm@lists.linux.dev, Andrey Konovalov , Florent Revest , Jann Horn , KP Singh , Matteo Rizzo , GONG Ruiqi , Danilo Krummrich , Uladzislau Rezki , rust-for-linux@vger.kernel.org Subject: Re: [PATCH v2] slab: support for compiler-assisted type-based slab cache partitioning Message-ID: References: <20260415143735.2974230-1-elver@google.com> Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Apr 20, 2026 at 11:30:23AM +0200, Marco Elver wrote: > On Mon, 20 Apr 2026 at 09:25, Harry Yoo (Oracle) wrote: > > [CC'ing RUST ALLOC folks for rust bindings] > > On Wed, Apr 15, 2026 at 04:37:05PM +0200, Marco Elver wrote: > > A few comments on V2: > > > > # comment 1 > > > > I'm not a big fan of how k[v]realloc_node_align() > > and kmalloc_nolock() define and pass the token parameter. > > > > IMHO it'll be fine to use {DECL,PASS}_KMALLOC_PARAMS() in those > > functions, since SLAB_BUCKETS users already passes NULL bucket > > to most of __kmalloc*() calls anyway. > > I'm not sure I agree. 2 reasons: > > 1. Even though it's "just" k[v]realloc_node_align() and > kmalloc_nolock() - despite their relatively less frequent use - just > put one of them in a hot path and you're sacrificing performance even > further. There are only so many arguments that can be passed in > registers (depending on arch), and may cause more stack spilling. > > 2. We'd misleadingly declare that these functions do something with > the bucket arg. This is wrong. Both are valid points. But it still feels wrong to have: void *krealloc_node_align_noprof(const void *objp, size_t new_size, unsigned long align, gfp_t flags, int nid DECL_TOKEN_PARAM(token)); n = krealloc_node_align_noprof(p, size, align, kmalloc_gfp_adjust(flags, size), nid _PASS_TOKEN_PARAM(token)); Actually the problem here is that some of parameters in DECL_KMALLOC_PARAMS() are not necessary in some functions. Perhaps we could have DECL_KMALLOC_PARAMS(size, b, token) # declare size, bucket, token DECL_BUCKET_PARAMS(size, token) # declare size, bucket; # but, actually, we don't need this! DECL_TOKEN_PARAMS(size, b) # declare size, token only; # for kmalloc_nolock and k[v]realloc_node_align() and use DECL_TOKEN_PARAMS(), PASS_TOKEN_PARAMS() for those functions? (just like how DECL_BUCKET_PARAMS() worked before) What do you think? > Both feels wrong, and would only make this change if you confirm both > are trade-offs that you strongly prefer. > > > # comment 2 > > > > This breaks Documentation/. > > > > Problems: > > > > - The document generator doesn't handle DECL_KMALLOC_PARAMS() well. > > > > - The signature of the function that users call (krealloc_node_align()) > > and the function that has kerneldoc (krealloc_node_align_noprof()) > > don't match. > > > > - Even worse, moving kerneldoc to the macro doesn't work because > > it uses variable arguments (...) > > Well, some were broken before, now it's just broken more. :-) Ouch... ;-) > We could move the documentation to macros and switch to explicit args > instead of (...). That works for me! > Otherwise, I don't see any way to fix this. Preferences? > > > # comment 3 > > > > Looking at how rust generates helper functions, > > in rust/helpers/slab.c: > > | // SPDX-License-Identifier: GPL-2.0 > > | > > | #include > > | > > | __rust_helper void *__must_check __realloc_size(2) > > | rust_helper_krealloc_node_align(const void *objp, size_t new_size, unsigned long align, > > | gfp_t flags, int node) > > | { > > | return krealloc_node_align(objp, new_size, align, flags, node); > > | } > > | > > | __rust_helper void *__must_check __realloc_size(2) > > | rust_helper_kvrealloc_node_align(const void *p, size_t size, unsigned long align, > > | gfp_t flags, int node) > > | { > > | return kvrealloc_node_align(p, size, align, flags, node); > > | } > > > > Rust code probably won't pass any meaningful token? > > (something you may want to address in the future) > > Yes, it'll just pass '0' by default. We could force Rust's allocation > to be in the pointer-containing range - if we assume Rust code is less > prone to contain bugs, but the assumption is that such allocations > both originate and are confined to the Rust side. One easy way to do > this is to write: > > return kvrealloc_node_align(p, size + 0 * sizeof(long*), align, > flags, node); > > But I'd defer that for now, until we're sure the above assumption > holds (Rust originated + confined). Ack. By the way, since Allocator trait uses realloc() to allocate new memory, IIUC all k[v]malloc, k[v]realloc usage from Rust will be affected. -- Cheers, Harry / Hyeonggon