From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 574FDC83F09 for ; Tue, 8 Jul 2025 15:11:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F114C6B0092; Tue, 8 Jul 2025 11:11:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC2096B0095; Tue, 8 Jul 2025 11:11:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8A266B009A; Tue, 8 Jul 2025 11:11:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C23536B0092 for ; Tue, 8 Jul 2025 11:11:34 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 922C5140622 for ; Tue, 8 Jul 2025 15:11:34 +0000 (UTC) X-FDA: 83641436508.08.50D3E10 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf28.hostedemail.com (Postfix) with ESMTP id EA785C0017 for ; Tue, 8 Jul 2025 15:11:32 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ohnQET+e; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of dakr@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751987493; a=rsa-sha256; cv=none; b=prqwsy/NraU71Z5pAL1/7PHQ9zLucV6PAMY/2rzf68nSAz2EZYqVXKg4Lgf4RewSXvIKWn ktqNudr1mWyoaujBr6yvLk3R6ursJAefrCqmw6ziQKK1Lmn2AjilXNH4WmUbf/0D7l0qk/ QmTcjZiA6kmWWQm4ohbE76HymI+bZ2U= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ohnQET+e; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of dakr@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751987493; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xp02AM+w8VgUErLi4gsLAhx0TlSrUTbISZW908O1H6w=; b=QE28dBtfYiYAg5adfBW/agKs2ikyvVRlIbwwNOalKmj/F+Pikso1k+r6Q6teeeIjhL2e1q vaIvJhjVoZDLVZG8OK75geGLndNs3AOBtDt3i6De6izOv61xql5Z88DPQxef5syJ+jpIr5 leT6BTmKKKN7WQpFfgFZ/J1vqetmVeA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 3BE7261426; Tue, 8 Jul 2025 15:11:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11743C4CEED; Tue, 8 Jul 2025 15:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751987491; bh=NRRNtg6vb+K/sjejePJsbFo5EUJno2MwHh8cVe80W/M=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=ohnQET+eQxGJXcUGGacq3S9BmTACp9gcbeanlc8UFNYikvcNwBLqA3wp7IAx88NDN mQhwZ4Fbv+SNQRI33D6CAj2qHgR/VWgyyiz/QUgLfAWeGrmNlrCeS+U/sq27ocWSgW 2w97t8GUtWaa8YpBO37ZY/4go8HuwLheGNZPEfbkI7O5goC3AyWTLI90fuNqt0iyo6 Y/HZ4haLXe4nBArO7sOiuxZLJ78+vt4pH6OMF4YtUVJiVrDBD1NHTFy5QFkaJlpoGJ C2ThD/lJMOH1clYyfb7uz6zVdH1teZ8xik/B+iAv9NadUV4To5lgasIkriO5/UZL58 g4oo/teCrkyYA== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 08 Jul 2025 17:11:28 +0200 Message-Id: Subject: Re: [PATCH v11 0/4] support large align and nid in Rust allocators Cc: "Vitaly Wool" , , , , "Uladzislau Rezki" , "Alice Ryhl" , "Vlastimil Babka" , , "Liam Howlett" To: "Lorenzo Stoakes" From: "Danilo Krummrich" References: <20250707164755.631374-1-vitaly.wool@konsulko.se> <824065ea-1f5c-4cd4-9917-4b7a91882af8@lucifer.local> <54fc10ce-c3b6-4571-93e7-eebfc538d0c7@lucifer.local> <4c122436-db58-4ca5-bc64-5ca596f03952@lucifer.local> In-Reply-To: <4c122436-db58-4ca5-bc64-5ca596f03952@lucifer.local> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EA785C0017 X-Stat-Signature: y8zdts1qq68rux1pc4tjghkwy113xn16 X-Rspam-User: X-HE-Tag: 1751987492-43071 X-HE-Meta: U2FsdGVkX186VNFlaWfzQoEVy4821BGWag59DmFTE69JIGwxdK+2P92oRpGTF1OwbdfPmuJSmlR2M9vH+VQ7rbvv8fiTIqjwcdrBGB6yWbuvwk+pr1y/OnSPc4mJgcQ+izukaVJNrphFlnwRtmgpYk6wKjGTxb4wj43BgUj7USWPQlrkGTWknp6X7LzJzAFoOt1t5Dy6UfkOD/P+IV6r+8zil2lx4LTcpaFSOkZe/iCWD1ON45a1QhPvw2aYX4oJTFOXZQyP41iAeL3rDAciT4c1wluqpp7+DnTc0D7tgkxlo/Bue2ZpyxDdvzirZcW2BrHNsNpiSbI3mFFrdSktJLpiQ6aDhgIMX5LOQfLXcuT6JMFIDYbof0XGJU72PjonVzeAcVHTZSjylPUhqDvKcecFKFuBGKxuAcnmVxouXO6LyMYkMI6H1Tm4CGivtiegHRzkyfRyyh0kvCC0cgDTIsQh8jXrzfyjf6b+KmdtHHEtwpuwL4Nonqm3DdiJMrrcl9PpHmxP8j96qecqjHLWPLuHmXD2VnstmHfFo0+Nqek8UZJS2absc24hqcX0+aySyux2+4zQ+e/4M/56TxcdXX1sm7tTauivdUojqUBcVJTbAYbZN1VZuj3FSOa5Rp2r/6c8KbUAXBLoC6eWsy2/Qid2Y0ewswNshQBVI3uGTuFp7yAWErxMFRuiYKBvccyWE35nj/rHorS/ZBGYsP5KcGKpcBrqH9Nq9woNbwhDUlKExfpN9ikLdU/fTt4kiNhyHq6LegX+NeRMNr/6HJueUlqGUCdPQDxJUi1Vfh7UKa937sORrufGQeFAohbEkjFVozbfXRk2wP53v019isPSicP0/CI1FEfjHGN2ao9vdF88M6N/bwtZU3PfvEcRKhqSc9Lx1Q53oF0iKvwPU9SA6oIeNiUwPcBDs4tTou2tHfE8LwwJ86ffN+vRwKVLIFyQNF0B8GfZrrDvdm5LO5G 1bP9Mn3b mNV6Bmi6gt8h7A26jtS519Ac6FiQDUXVOU3jbqd0AG4M9qfbJaOkpM4U1g+oBRN1ER40UGBPUaFoGNHdMgAsDZ5OALKrK62NVqiWZWoTUjEnYxhVKXBqG0J7SGxIIBUPM3HSZzK7R4WLuZ+V7VmKyJEat1mL8c7BhBaOn4R3e2SEtLz4a8QozKEptgpcHWorazJH8Q4Qdlq+WI8vPKbhYxPZPr3A73MuOK+85Nix/pLTpPd9JTUWL0jce3gpIoQ4vq/5F+bENJ6Uu4ISc+uLJrke8RdsGQofRg8rfJHCBRH4nKiQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue Jul 8, 2025 at 4:39 PM CEST, Lorenzo Stoakes wrote: > On Tue, Jul 08, 2025 at 04:16:48PM +0200, Danilo Krummrich wrote: >> (Please also see the explanation in [1].) >> >> There's a thin abstraction layer for allocators in Rust, represented by = the >> kernel's Allocator trait [2] (which has a few differences to the Allocat= or trait in >> upstream Rust, which, for instance, can't deal with GFP flags). >> >> This allocator trait is implemented by three backends, one for each of >> krealloc(), vrealloc() and kvrealloc() [3]. >> >> Otherwise, the alloc module implements Rust's core allocation primitives= Box and >> Vec, which each of them have a type alias for allocator backends. For in= stance, >> there is KBox, VBox and KVBox [4]. >> >> This was also mentioned in the mm rework in [5] and in the subsequent pa= tch >> series reworking the Rust allocator module [6]. >> >> Before [6], the Rust allocator module only covered the kmalloc allocator= (i.e. >> krealloc()) and was maintained under the "RUST" entry. >> >> Since [6], this is maintained under the "RUST [ALLOC]" entry by me. >> >> Given that, there is a clear and documented responsibility, which also A= ndrew is >> aware of. >> >> To me the current setup looks reasonable, but feel free to take a look a= t the >> code and its relationship to mm and Rust core infrastructure and let me = know >> what you think -- I'm happy to discuss other proposals. > > Thanks for the explanation. > > To me this is clearly mm rust code. This is an abstraction over mm bits t= o > provide slab or vmalloc allocations for rust bits. > > To be clear - I'm not suggesting anything dramatic here, nor in any way > suggesting you ought not maintain this (apologies if this wasn't clear :) > > It's really a couple points: > > 1. Purely pragmatically - how can we make sure relevant people are pinged= ? I'm very happy to add more reviewers to the RUST [ALLOC] entry for this pur= pose. Can you please send a patch for this? > 2. Having clarity on what does/does not constitute 'MEMORY MANAGEMENT - R= UST' > (again, perhaps Alice best placed to give some input here from her poi= nt of > view). In the end that's a question of definition. The reason RUST [ALLOC] is a thing is because it is very closely related to= Rust core infrastructure with only a thin backend using {k,v}realloc(). Compared to other abstractions, the main purpose is not to expose a Rust interface for an existing kernel specific API, but rather implement a very = Rust specific concept while being a user of an existing kernel C API. > We could solve 1 very simply by just using the fact we can have files in > multiple sections in MAINTAINERS. Please not -- I don't want to have files in multiple entries in MAINTAINERS= , especially when there are different maintainers and different trees. I pref= er clear responsibility. > Doing a scripts/get_maintainers.pl invocation will very clearly tell you > who's in charge of what so there'd be no lack of clarity on this. How's that when a file is in multiple entries? > It's a bit messy, obviously. But it'd solve the issue of mm people not > getting notified when things change. > > However, at this stage you might want to just limit this to people who ha= ve > _opted in_ to look at mm/rust stuff. In which case then it'd make sense t= o > add only to the "MEMORY MANAGEMENT - RUST" section (but here we need to > address point 2 obviously). > > Alternatively we could just add reviewers to the rust alloc bit. Yeah, let's do that instead please. >> >> [1] https://lore.kernel.org/all/aG0HJte0Xw55z_y4@pollux/ >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t= ree/rust/kernel/alloc.rs#n139 >> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t= ree/rust/kernel/alloc/allocator.rs#n130 >> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t= ree/rust/kernel/alloc/kbox.rs >> [5] https://lore.kernel.org/all/20240722163111.4766-1-dakr@kernel.org/ >> [6] https://lore.kernel.org/all/20241004154149.93856-1-dakr@kernel.org/ > > > I feel it's really important to not separate rust _too much_ from the > subsystems it utilises - if we intend to have rust be used more and more > and integrated further in the kernel (something I'd like to see, more so > when I learn it :P) - the only practical way forward is for the rust stuf= f > to be considered a first class citizen and managed hand-in-glove with the > not-rust stuff. You're preaching to the choir with this on my end. I'm recommending subsyst= ems that receive the first Rust bits to get involved in one or the other way al= l the time. And if it's only by reading along. :)