From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E22FB29ACFD for ; Sat, 17 Jan 2026 13:11:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768655516; cv=none; b=VpPtSntO/QwRQQOlb54dRm1lGd63OmmbB3YQMmEODc52reWEhssbiVs26T57ey2i/5SuZAlKY0Q99jkwvG49VnxFWgmFEejIMMFY07pXb3aM6Ty2TeoBWEPvrqW9pCiqgAne0F3LSoOxuqoczfdwbDe3dfhsABLimf3flep0nhc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768655516; c=relaxed/simple; bh=F9+NetmOvfbgFjslgvJwK7ZP49AbY0olv9NCAZ1pnFs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XC/9rTrRlDI99neSqP/cvFAcxPQWX0Ei45i50S5dwR8EGmvYVh1DGBMckwp6Ta92owYjaSsdZVz2PCK6knSEYYbxaVsjkvntj3C7jIADJ+6WY3SKLcbMUMJygGPmxbrTIrddUhkIKHaDlahzrdS1qlQCRFI/wbSC9ahPOGisiLE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aTV4OR8Q; arc=none smtp.client-ip=209.85.219.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aTV4OR8Q" Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-88a2fe9e200so27647226d6.0 for ; Sat, 17 Jan 2026 05:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768655514; x=1769260314; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=BTrHmEc1BYd79fY4MjqTS6sMPKSqsWTUhgoBbfphsL0=; b=aTV4OR8Q2kYqFCxCHgWuOCs6uGDptnVVby5EGdflQys6tPoN8E0WKgpNfzfznFXipc f4Ogy97L9qWgA9asx0cIzgbn8z3kSEyc67zXuNAbQYS65VUQt6Z1f+CU8dlM0+4ueCc2 QJm99nH29WPvYC/zjwth0x4FWfH1gnDVPzTCdKBt9N7ub8jEFKv04VLsD5oxFYvSt7D4 vXih48KYKQsC+9u533SVsmXT5En5wUslWAVhaD0kg+y95A6E4deHPWNG3uSoUuJcC4JP kKGnnbGtt8wWvqRpSIo9LzY0JSUtcn+eMBVeZ4YrlBef6pXoJvqFRDibrlT07Xay3nn2 2ENg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768655514; x=1769260314; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BTrHmEc1BYd79fY4MjqTS6sMPKSqsWTUhgoBbfphsL0=; b=TsUUdODCBxYBa5XZ4i5HLq6xpKh/0TFGM4fyvoNhYg89VGYUhoyWmuth29FEPgVYC7 TS6gZcUjQ2SGMr5JiOAS36G8ddTdzeDtY55zS/t4sPhAQ5CMEglDjDJrN5j98OeLkKlB rbT+zHfOhcl0T1kCfuc0JZWqxOQfFielXxFxi7WRisB3fHfc9r98je2qD/z7X9ASoLNB LITxkgD87kZBydOqUzfKdluR/d542mZBB1mwGpawBEre7z1Sy7Y3D4CJNjj0vu2Oy630 PjgxPeY/4wtlBFWpAj+u9utY5tlgvzFQnm2uvC075mJUlLltSinSTX44Yq6bKK06appE imtg== X-Forwarded-Encrypted: i=1; AJvYcCXVQpqiz8sWWoxdL2BfckTOVNkfXZ4Slg/3QtmtHuHO0kww5NNQhg3wgGfZoI8VwsqNX7Lk4i2pWeOv3EQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwrXz0xFT5JL+FvBpdD1O2cruiVemg8AqqNUjxvyfUuOWwOgarB z/dRHpj9Wnj8T4lHZ7V4ZX5+t7eHiuU2aJYg8TEbtXXcFZOiu83IHv0K X-Gm-Gg: AY/fxX4tAePIT7QsSx2IDZ8fjn34JJJ9K3SL9cbvaQJTsVRMoYg3sDVRsi+p1Rlgnua tTxWr/db0taXECjId95spgju5pmC+Yvh7j2MFx1G8n6fNnl3iD2XYozyfgmvq393JZ/pAUjwHIF Fdh9MQC6kOTXrFMZIi+981jj9BXWX/QnEe8wKuwQp2oIO0seR4VZj0Z9sznlrSB54kKdfMC/8iW KPt2qxBbOQ0F9Tx8jyWNZF7lswk+txTaZUaLRl4UfpVWmKhfA9j0yCJQUEmDqMrUaGrNyB+2w7B WLy9dV4O9Qfkj+eT4WbjJRs4KyO8wpSU6V1d+L7uDl/oj8KQdzGUmj+GNc1HqrOoTGk0SDQN3uD k4+VdImNSXPbAN8buWPUD2O0uwvKtXfDJI8DL1BpPbn41OV9gC/uexX7RJe0lL1m+/+W5ApXR8f L6tUB9lwlVdPeRkP+6ZNVEEH0/9P0jKq8t9fntaqQf5KW7j1bLv94ZpziVDkeBbDHm3wTu52YQn vN9bVSu+Ya0S4M= X-Received: by 2002:a05:6214:cc1:b0:892:68f8:aaa6 with SMTP id 6a1803df08f44-8942dd29578mr77537336d6.18.1768655513740; Sat, 17 Jan 2026 05:11:53 -0800 (PST) Received: from fauth-a2-smtp.messagingengine.com (fauth-a2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c6b22bb7cbsm154629785a.39.2026.01.17.05.11.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Jan 2026 05:11:53 -0800 (PST) Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id 6D76CF40070; Sat, 17 Jan 2026 08:11:52 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Sat, 17 Jan 2026 08:11:52 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddufedukeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpeehudfgudffffetuedtvdehueevledvhfelleeivedtgeeuhfegueevieduffei vdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsoh hquhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdeiledvgeehtdeigedq udejjeekheehhedvqdgsohhquhhnrdhfvghngheppehgmhgrihhlrdgtohhmsehfihigmh gvrdhnrghmvgdpnhgspghrtghpthhtohepvdeipdhmohguvgepshhmthhpohhuthdprhgt phhtthhopegrlhhitggvrhihhhhlsehgohhoghhlvgdrtghomhdprhgtphhtthhopehprg hulhhmtghksehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihgrmhdrhhhofihlvght thesohhrrggtlhgvrdgtohhmpdhrtghpthhtohepghgrrhihsehgrghrhihguhhordhnvg htpdhrtghpthhtohepohhjvggurgeskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepsghj ohhrnhefpghghhesphhrohhtohhnmhgrihhlrdgtohhmpdhrtghpthhtoheplhhoshhsih hnsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrrdhhihhnuggsohhrgheskhgvrhhn vghlrdhorhhgpdhrtghpthhtohepthhmghhrohhsshesuhhmihgthhdrvgguuh X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 17 Jan 2026 08:11:51 -0500 (EST) Date: Sat, 17 Jan 2026 21:11:49 +0800 From: Boqun Feng To: Alice Ryhl Cc: "Paul E. McKenney" , "Liam R. Howlett" , Gary Guo , Miguel Ojeda , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Ballance , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, rcu@vger.kernel.org, maple-tree@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH RFC 0/2] rcu box container for Rust + maple tree load_rcu Message-ID: References: <20260116-rcu-box-v1-0-38ebfbcd53f0@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Jan 17, 2026 at 08:11:17PM +0800, Boqun Feng wrote: [...] > > > > An RcuBox is like a Box except that it lets you obtain a &T that > > > > outlives the box by a grace period. It does not allow mutable access to > > > > > > I think the `RcuBox` can be folded into the more generic RCU pointer api > > > [1], e.g. Rcu>> where RcuBoxInner: HasRcuHead. The > > > benefits are at least 1) we use relaxed atomic read for RCU readers > > > which guarantees address dependency that RCU needs under LKMM (while in > > > the RcuBox here, we just use plain reads), 2) we also support mutable > > > access as well. > > > > 1) But mtree_load() does use rcu_dereference() to obtain the pointer? I see, I need to change my reply to "RcuOld" below.. [...] > > > > Hmm, so I looked over [2], and I think my RcuBox is an RcuOld<_> rather > > than an Rcu<_> under this model. Though I can't afford to pay > > I don't think so, `RcuOld` represents an unpublished object while `Rcu` > represents a published object, you can update an `Rcu` pointer to > another object, which is normally how you update with RCU. But maybe > it's easy to discuss this with updater side code in picture. > I think a more accurate reply should be `RcuOld` is still not designed for the usage of `RcuBox`. You're right that `RcuBox` is not an `Rcu<_>` since `RcuBox` don't have the atomic pointer part, instead it relies other atomic pointer operations to work (for example, the rcu_dereference() in mtree_load()). `RcuBox` represents an object pointed (and protected) by RCU. `Rcu<_>` is an atomic pointer that maintains read and update for RCU, in your usage, you don't need it because maple tree does that for you. `RcuOld<_>` works with `Rcu<_>` to provide an API for users to decide how to handle RCU reclaim. In Rcu + RcuOld design, RcuBox is just a Box because these two pointer types handle reclaim + accesses. We will need to use `Rcu` and `RcuOld` where the RCU access code is in Rust. I think there are similarities between `RcuOld` and `RcuBox`, but they are sort of designed with different usages in mind, lemme think more.. Regards, Boqun > > synchronize_rcu() for cleanup - I need kfree_rcu(). > > > > That's something we can add later, for example, we can give `Rcu` (we > can add the similar thing to `RcuOld`) a generic const like: > > struct Rcu(..) > > where Rcu use synchronize_rcu() and Rcu use kfree_rcu() or > call_rcu() (once we have HasRcuHead support). > > Regards, > Boqun > > > Alice