From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-244108.protonmail.ch (mail-244108.protonmail.ch [109.224.244.108]) (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 045B23D301E; Fri, 29 May 2026 12:30:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=109.224.244.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780057828; cv=none; b=V5mLp6oBTEdawUMYOOUuSY9uS1nUWjfqqQYcjJrICKT+nwDncJrm147xTvZrx+3EFtfy62q0SQJKYZy6TJNjdput2JucnK1x5+WqruNiomJSobyIwCBcfawkWtH6T5bzOA/1QDo2bbng4ioNdMzwAZaohuPR3T7D3O8hUpcG2vc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780057828; c=relaxed/simple; bh=3YWG/XEThhBNbhY+I5jYNB6brXYZQmiktIHaCDq+k5Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mmCcNWxhfoGIwdaqv1UaElh43f7kH4rVwf7kAGLfpyRT1j7sWi2sGiOXf6KULFtcJIVTir+vW+2dponwx1Xbkon+CrX388QdDUaO/KlzdXLvcLaNTUvg2d1a+Pde80D+CMN/y86VitcYDJ9iKsvFlonukqxk5UVf30H9yijJRk0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=onurozkan.dev; spf=pass smtp.mailfrom=onurozkan.dev; dkim=pass (2048-bit key) header.d=onurozkan.dev header.i=@onurozkan.dev header.b=Eb6puIo6; arc=none smtp.client-ip=109.224.244.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=onurozkan.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=onurozkan.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=onurozkan.dev header.i=@onurozkan.dev header.b="Eb6puIo6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onurozkan.dev; s=protonmail; t=1780057823; x=1780317023; bh=gO3pl4aT30adoKRKjlcgNs56IednDpwZ7K7MxewOJws=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:From:To: Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Eb6puIo64YVRLmN09iZuubFZbRYwmOno860qrsZl52o2O1bVKFsxTRAyTnDXhmeVj NVT+Iabcpm00pffh4u53gAh2j4gFBil/jEm6Lch7xeo8q3jTKZPhPpjw+hG+YdZh+b u/3mDDCNMYMSeuZoYhS//rHKBFRekXc6Ywo79z0j3GgrSJQWMVdSBcJgcVUPt3ts1l 7iG3As8cg+9hP0qzY4rcpx9cCGCkmeZOoCIr08bIwp0ePxYcck+j0YSlzFcZwPt9FM GGetkIk4cYxmOVF74eHQLU9oA3wDaoxhVd8rOTZcuF8nSfMtqLpokArSaWFJgEFEEB gHc1dQqpGAMNw== X-Pm-Submission-Id: 4gRjP82SXhz1DDLL From: =?UTF-8?q?Onur=20=C3=96zkan?= To: Gary Guo Cc: rcu@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, ojeda@kernel.org, boqun@kernel.org, bjorn3_gh@protonmail.com, lossin@kernel.org, a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu, dakr@kernel.org, peterz@infradead.org, fujita.tomonori@gmail.com, tamird@kernel.org, jiangshanlai@gmail.com, paulmck@kernel.org, josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com Subject: Re: [PATCH v8 1/4] rust: helpers: add SRCU helpers Date: Fri, 29 May 2026 15:30:07 +0300 Message-ID: <20260529123018.177238-1-work@onurozkan.dev> X-Mailer: git-send-email 2.51.2 In-Reply-To: References: <20260529114449.112066-1-work@onurozkan.dev> <20260529114449.112066-2-work@onurozkan.dev> <20260529120759.145202-1-work@onurozkan.dev> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 29 May 2026 13:16:17 +0100=0D Gary Guo wrote:=0D =0D > On Fri May 29, 2026 at 1:07 PM BST, Onur =C3=96zkan wrote:=0D > > On Fri, 29 May 2026 12:58:17 +0100=0D > > Gary Guo wrote:=0D > >=0D > >> On Fri May 29, 2026 at 12:43 PM BST, Onur =C3=96zkan wrote:=0D > >> > Add helper wrappers for SRCU functions that are exposed to Rust=0D > >> > through generated bindings.=0D > >> >=0D > >> > Reviewed-by: Paul E. McKenney =0D > >> > Signed-off-by: Onur =C3=96zkan =0D > >> > ---=0D > >> > include/linux/srcu.h | 5 +++++=0D > >> > rust/helpers/helpers.c | 1 +=0D > >> > rust/helpers/srcu.c | 30 ++++++++++++++++++++++++++++++=0D > >> > 3 files changed, 36 insertions(+)=0D > >> > create mode 100644 rust/helpers/srcu.c=0D > >> >=0D > >> > diff --git a/include/linux/srcu.h b/include/linux/srcu.h=0D > >> > index 81b1938512d5..790a4ef713c0 100644=0D > >> > --- a/include/linux/srcu.h=0D > >> > +++ b/include/linux/srcu.h=0D > >> > @@ -57,6 +57,11 @@ int __init_srcu_struct_fast_updown(struct srcu_st= ruct *ssp, const char *name,=0D > >> > #else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */=0D > >> > =0D > >> > int init_srcu_struct(struct srcu_struct *ssp);=0D > >> > +static inline int __init_srcu_struct(struct srcu_struct *ssp, const= char *name,=0D > >> > + struct lock_class_key *key)=0D > >> > +{=0D > >> > + return init_srcu_struct(ssp);=0D > >> > +}=0D > >> =0D > >> =0D > >> This looks like a different strategy than, say, how mutex handles lock= dep. IMO=0D > >> the way that mutex handles this is more clear.=0D > >=0D > > Initially it was the same strategy, this one was suggested by Paul [1] = and it=0D > > didn't sound like a bad idea to me. Also, in previous revisions, Boqun = once=0D > > said:=0D > =0D > I'm talking about changing how this is handled in SRCU side, not helper s= ide.=0D > =0D > >=0D > > "Having a "#ifdef" in a function body is generally considered as bad c= ode=0D > > (I know we have some of these in rust helpers, but helpers are a bit=0D > > special and maybe we should clean them up). So could you move this=0D > > function into include/linux/srcutiny.h and include/linux/srcutree.h?"= =0D > =0D > mutex.h doesn't use ifdef inside function body, it just define two static= inline=0D > functions with the same signature in different ifdef branches.=0D > =0D =0D I might have confused them, let me check them again.=0D =0D Thanks,=0D Onur=0D =0D > Best,=0D > Gary=0D > =0D > >=0D > > So putting them together, I decided to follow Paul's suggestion.=0D > >=0D > > [1]: https://lore.kernel.org/all/05906890-cf06-414c-a625-02f9d7150d57@p= aulmck-laptop=0D > >=0D > >> =0D > >> If we follow the way mutex is handles this, the `init_srcu_struct` wou= ld always=0D > >> create lock class key and forward to `__init_srcu_struct`, and=0D > >> `__init_srcu_struct` is an inline function that either calls=0D > >> `init_srcu_struct_lockdep` with all args, or discard name/key and forw= ard to=0D > >> `init_srcu_struct_mutex`.=0D > >> =0D > >> This is beneficial because the usage flows one way. You don't have in = one config=0D > >> `init_srcu_struct` call `__init_srcu_struct` and have the opposite in = another=0D > >> config, which I think can be quite confusing.=0D