Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Bradley Morgan <bradley.morgan@linux.dev>]

On 10 November 2026 18:34:00 GMT, "Paul E. McKenney" <paulmck@kernel.org>
wrote:
>On Tue, Nov 10, 2026 at 08:06:59AM +0300, Dan Carpenter wrote:
>> On Mon, Nov 09, 2026 at 10:44:16AM -0800, Paul E. McKenney wrote:
>> > On Mon, Nov 09, 2026 at 06:32:15PM +0100, Christophe JAILLET wrote:
>> > > Le 09/11/2026 à 00:06, Joel Fernandes a écrit :
>> > > > On Sat, Nov 07, 2026 at 10:02:25PM +0100, Christophe JAILLET
>wrote:
>> > > > > 'struct rcu_scale_ops' is not modified in this driver.
>> > > > > 
>> > > > > Constifying these structures moves some data to a read-only
>section, so
>> > > > > increases overall security, especially when the structure holds
>some
>> > > > > function pointers.
>> > > > > 
>> > > > > On a x86_64, with allmodconfig:
>> > > > > Before:
>> > > > > ======
>> > > > >     text	   data	    bss	    dec	    hex	filename
>> > > > >    45585	  24946	   2816	  73347	  11e83	kernel/rcu/rcuscale.o
>> > > > > 
>> > > > > After:
>> > > > > =====
>> > > > >     text	   data	    bss	    dec	    hex	filename
>> > > > >    46545	  23986	   2816	  73347	  11e83	kernel/rcu/rcuscale.o
>> > > > > 
>> > > > > Signed-off-by: Christophe JAILLET
><christophe.jaillet@wanadoo.fr>
>> > > > > ---
>> > > > > Compile tested only.
>> > > > 
>> > > > rcuscale is a test kernel module, is it worth adding boilerplate
>for
>> > > > non-production code sighting security reasons?
>> > > 
>> > > Oups, now I better understand Bradley Morgan comments.
>> > > 
>> > > I didn't notice it was a test module.
>> > > My patch makes no more sense, as it is not hardening runtime, so
>feel free
>> > > to just drop it.
>> > > 
>> > > Sorry for the noise and not seeing it by myself.
>> > 
>> > Although the header comment does say "Read-Copy Update module-based
>> > scalability-test facility", maybe there is something that should be
>> > done to more clearly mark code that is not to be used in production.
>> > And maybe to inform the LLM review bots of this.
>> > 
>> > But this is bigger than just RCU.
>> 
>> Christophe has been constify things for years and years.  There is
>> an argument to be made that it's just the right thing to do whether
>> this is test code or not.  Someone might copy and paste it, for
>> example.
>> 
>> Of course, everyone is overloaded with AI.  I feel like normal cleanup
>> patches are more likely to get NAKed because everyone is just totally
>> overwhelmed.
>
>Fair enough, though rcutorture.c (in the same directory as rcuscale.c)
>*does* write to its counterpart to this structure.  The point being that
>this is an optimization-like thing rather than a prohibition-like thing.
>
>So we might want some way to differentiate between these two cases.

Well, I'm not saying "no this shouldn't happen", but the benefits are
negligible ISH. Well, Paul, what do you reckon? I'm not fussed, just a bit
"ehhh..."

>
>							Thanx, Paul
>
>

--- Thanks!