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 92160C83F0A for ; Tue, 8 Jul 2025 11:55:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20B6B6B031B; Tue, 8 Jul 2025 07:55:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E3846B031C; Tue, 8 Jul 2025 07:55:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F9596B031D; Tue, 8 Jul 2025 07:55:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F16636B031B for ; Tue, 8 Jul 2025 07:55:27 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7156F128DA0 for ; Tue, 8 Jul 2025 11:55:27 +0000 (UTC) X-FDA: 83640942294.14.596646C Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf09.hostedemail.com (Postfix) with ESMTP id A3C1F14000D for ; Tue, 8 Jul 2025 11:55:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aQH7UWxn; spf=pass (imf09.hostedemail.com: domain of dakr@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aQH7UWxn; spf=pass (imf09.hostedemail.com: domain of dakr@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751975725; a=rsa-sha256; cv=none; b=s04jAeFngp6Qfh+ByWwo6GEZJFlDmFaECvKUxapSkO0wuhwgS/k1HKzNDXzYcYNsvkQURB ffR/ot+4kP68xOtA0tFsh7ateOON58ph3HSSN5khQ34nmmUCiXju1sG1YRdiLuZkeJB9HP U5AFLPvXmPzH3jwbt3mQCJRKWmh9dhE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751975725; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CIJNY+9znZckwb6PdbCI3UqqgJ6c8JJrG0F+uy8NoR8=; b=gvoavYDhxLVUfktxszKwOaTyfGX6cgPheJZnTCma7XOsnmS9VCRYmCWfGBd0RWLT1Vyeu8 6AjLvVUkjwsHT5vuYKEk5IHYf1ErZJ/tWM1I+ctQmkzFnzH9i0qEjlr3jJ1kH6SxWOW0s/ /4hh+95te7qWplAkvHAKwwWnyDvhMt0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 64D9A45024; Tue, 8 Jul 2025 11:55:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 427F6C4CEED; Tue, 8 Jul 2025 11:55:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751975724; bh=+rr5IUZMNLv1aC8gIdC2OTcN+TiRteFK92MBd6ezAYo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aQH7UWxnNBi4BoxndCKPTZn+85+ds7CvXHALFDbLeRWOGooAhY6mFhoI8J3IyDZlR 7gLu6RO/QUgcKaKHrCV5BFc1Qh/Ehga58W8yKUjWxYp3+iU8uHzZKaYMtZWBWZndai ys0KbZ/WkpCMq46ocy/C6Yp0X4dd4q3MTLmLzJehan8LZL5Q00ih/ctUlgBWNLWJR8 R3wgn345vbPxRtJX+dMqrJjxZtEKwx/xWTV4vQ8VqVUvLiK4BotKdPRgRh6NfPKlQO +ActSeB34oHpy+u76senrBTsROrindxj0DZ2/QH18caLVM0+fLsmFjiHlqmkSkUk+q nnUZSiP4um/kQ== Date: Tue, 8 Jul 2025 13:55:18 +0200 From: Danilo Krummrich To: Lorenzo Stoakes Cc: Vitaly Wool , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Alice Ryhl , Vlastimil Babka , rust-for-linux@vger.kernel.org, Liam Howlett Subject: Re: [PATCH v11 0/4] support large align and nid in Rust allocators Message-ID: References: <20250707164755.631374-1-vitaly.wool@konsulko.se> <824065ea-1f5c-4cd4-9917-4b7a91882af8@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <824065ea-1f5c-4cd4-9917-4b7a91882af8@lucifer.local> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A3C1F14000D X-Stat-Signature: 8bcnbhq9e979at9n54ag5kkumpkuj83z X-Rspam-User: X-HE-Tag: 1751975725-637029 X-HE-Meta: U2FsdGVkX1+K4WGBx3K6Skxos0G0EKXua8d7uO+8rT3Ei22M7OrwD5AdDFt3zN5+Jw5gLGzn7DkJYnSaZGaygQ+kpGLtlomvJ2zD61AjuRQcvEEHD4hNKIW2cWLCiXNEOmtZ7hb9ZV08pwohw2alPKdnz1AFk5AlH+9Fz96/GJolz9+QreNAYuDkwkA9GkOpNBENjNgvWqN50QKAY+OOxdxSNGZxzk4WaiJJDo0Xt95h6/vL+CBmlBNQWw2O8kRAtVnvXiYMI2EZME1i1VsHkDKFqf6YYqRvnJtANOLx8ipDVay+P5wbanSzlEnmGhBxJLPTJAGPeUZxG+caiQ4SbVyntLc0ZQva3H3vMSd3M+hirqcZdFsvjfp57PugkR4WqiMzJ4biVQgYkZa8RCI4yLo7ouGPod7flmCSGOOnLQYlKz5J2I29HoWmrNVT8eLCi8xECM1rh0JX/FlMvkfh9ZmCtYMkf2UtPbHVtgi/bvTZib+xhAL6Tq4SWQK6YEZT/18lKM2vFiuQxNMa49gBVVFKYmlH/UFZM0+KrALTOFI7GFqBB/S9QVszyWowBOwGghGjThQLOnGrUHRF67z+U2HnN3N4wwTXfTRtNw33PpNLVO2QLdQb0e3vRuAz5FYebVgagUIAnqOP/trRKuIcjTupczRdnvogyUx6OXuDhKtbnFaWZUD+fEyuEiQ4vvFBAF7IgdTAi5xXemAmztTYwBmB/Ny25BDCnQ5a6gwJcohTmJROSQ3x9gSqBegKruTp593W5DOwptDBVK/pyjbRZFWLJxY1H6FBsn8DUHeLVtRlnCKjCqvs4HcaoefyRJ+VOMPXi+cjG7cBVrhhyLcNBmPvVIYnXJUUgmWZcEn86D8QIgYAO28roNwBX7vjOCc66Wr4opYOlAQjyRPd3JlM/Qi0K0kCTsSeLcKYz/NSXlDz4k/UjLl9I9EwI6ZGfqw7JBmnrJBZ08JDPc50MJM uYITtpeD doggICt5wwONdNJu0yLTYKkjpqF94L2MqA5nWvGoK5INQ8z74ipY5TcncOY6XK3f6+9C2pDv56RpfQdRie7TGNLLzgy1ATzCMlpDsyJI/9W+ULz3hPm/0MAthfXUAzllHfkWXHLtzgw/NNFV8njFcclnVxaBNtAcTW/TMg+5wDN9fpKphZmonw1bcnzstmvkNMUyvtBhxYYVZaj7M9bGnlDbIBIpOGDBs7QWWy9WjEFJgYuZtLOuQpA7Bi1c47m3/E1JJxvkOkQa0o0OfJI8rDE2AFYxRw9BuM/2XB20nOiWWLEErGHJxRB1xUE2NP8Nk6HTbAkUzgqaa9TKq+T6fmvcfrA== 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 08, 2025 at 11:58:06AM +0100, Lorenzo Stoakes wrote: > +cc Liam > > Hi guys, > > We have a section in MAINTAINERS for mm rust (MEMORY MANAGEMENT - RUST), so > it's slightly concerning to find a series (at v11!) like this that changes > mm-related stuff and it involves files not listed there and nobody bothered > to cc- the people listed there. What files are you referring to? Are you referring to: rust/kernel/alloc.rs rust/kernel/alloc/* If so, they're indeed not under the "MEMORY MANAGEMENT - RUST" entry, which so far seems correct. Please also note that we had "RUST [ALLOC]" before "MEMORY MANAGEMENT - RUST" did exist. > I can fully understand there being some process fail here meaning you > missed it - fine if so - but let's fix it please moving forwards. I agree that this series should have a couple more people in Cc. Given the existing entries in the MAINTAINERS file the Rust parts seems to be correct though. > It's really important to me that the rust efforts in mm are collaborative - > I really believe in your mission (well - for me it's about the compiler > _helping_ me not shooting me in the foot :) - and have put substantial > effort in assisting initial work there. So let's make sure we're > collaborative in both directions please. AFAICT, those efforts are collaborative. Back then I sent patches to introduce vrealloc() and improve and align kvrealloc() and krealloc() [1]; it was also mentioned that this was, besides the other advantages, prerequisite work for the Rust allocator patch series [2]. The subsequent Rust allocator patch series [2] was also sent to Andrew and the -mm mailing list; the previous code replaced by this series was maintained under the "RUST" entry in the maintainers file. With the introduction of the new Rust allocator code I took over maintainership. So, Andrew is aware of the Rust allocator tree, please see also [3]. [1] https://lore.kernel.org/all/20240722163111.4766-1-dakr@kernel.org/ [2] https://lore.kernel.org/all/20241004154149.93856-1-dakr@kernel.org/ [3] https://lore.kernel.org/all/20250625143450.2afc473fc0e7124a5108c187@linux-foundation.org/ > We have rust/kernel/mm/ under MEMORY MANAGEMENT - RUST too, I'm not au fait > with your approach to structuring in these folders but seems to me these > helpers should be there? I may be unaware of some rust aspect of this > however. The Rust allocator module is a user of exactly three functions of mm, i.e. krealloc(), vrealloc(), kvrealloc(), with a thin abstraction layer for those three allocator backends. Everything else is rather Rust core infrastructure than mm infrastructure. > Can we please add these files to this section and in future cc people > listed there? We're here to help! What's your proposal regarding maintainership? Are you asking me to drop it to "MEMORY MANAGEMENT - RUST"? > A side-note I wonder if we also need to put specific files also in relevant > mm sections? E.g. the slab helper should also be put under the slab section > perhaps? Yes, we could. But in the end all Rust helper functions are transparent wrappers, simply forwarding a function call *without* any additional logic. They don't really require maintainence effort, and, in the end, are just trivial boilerplate.