[PATCH] rcuscale: Constify struct rcu_scale_ops

[PATCH] rcuscale: Constify struct rcu_scale_ops

[Christophe JAILLET]

'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.
---
 kernel/rcu/rcuscale.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
index 1097ec15879c..522f7bc2e693 100644
--- a/kernel/rcu/rcuscale.c
+++ b/kernel/rcu/rcuscale.c
@@ -159,7 +159,7 @@ struct rcu_scale_ops {
 	const char *name;
 };
 
-static struct rcu_scale_ops *cur_ops;
+static const struct rcu_scale_ops *cur_ops;
 
 /*
  * Definitions for rcu scalability testing.
@@ -185,7 +185,7 @@ static void rcu_sync_scale_init(void)
 {
 }
 
-static struct rcu_scale_ops rcu_ops = {
+static const struct rcu_scale_ops rcu_ops = {
 	.ptype		= RCU_FLAVOR,
 	.init		= rcu_sync_scale_init,
 	.readlock	= rcu_scale_read_lock,
@@ -247,7 +247,7 @@ static void srcu_scale_synchronize_expedited(void)
 	synchronize_srcu_expedited(srcu_ctlp);
 }
 
-static struct rcu_scale_ops srcu_ops = {
+static const struct rcu_scale_ops srcu_ops = {
 	.ptype		= SRCU_FLAVOR,
 	.init		= rcu_sync_scale_init,
 	.readlock	= srcu_scale_read_lock,
@@ -276,7 +276,7 @@ static void srcu_sync_scale_cleanup(void)
 	cleanup_srcu_struct(srcu_ctlp);
 }
 
-static struct rcu_scale_ops srcud_ops = {
+static const struct rcu_scale_ops srcud_ops = {
 	.ptype		= SRCU_FLAVOR,
 	.init		= srcu_sync_scale_init,
 	.cleanup	= srcu_sync_scale_cleanup,
@@ -313,7 +313,7 @@ static void rcu_tasks_scale_stats(void)
 	rcu_tasks_torture_stats_print(scale_type, SCALE_FLAG);
 }
 
-static struct rcu_scale_ops tasks_ops = {
+static const struct rcu_scale_ops tasks_ops = {
 	.ptype		= RCU_TASKS_FLAVOR,
 	.init		= rcu_sync_scale_init,
 	.readlock	= tasks_scale_read_lock,
@@ -357,7 +357,7 @@ static void rcu_tasks_rude_scale_stats(void)
 	rcu_tasks_rude_torture_stats_print(scale_type, SCALE_FLAG);
 }
 
-static struct rcu_scale_ops tasks_rude_ops = {
+static const struct rcu_scale_ops tasks_rude_ops = {
 	.ptype		= RCU_TASKS_RUDE_FLAVOR,
 	.init		= rcu_sync_scale_init,
 	.readlock	= tasks_rude_scale_read_lock,
@@ -396,7 +396,7 @@ static void tasks_trace_scale_read_unlock(int idx)
 	rcu_read_unlock_trace();
 }
 
-static struct rcu_scale_ops tasks_tracing_ops = {
+static const struct rcu_scale_ops tasks_tracing_ops = {
 	.ptype		= RCU_TASKS_FLAVOR,
 	.init		= rcu_sync_scale_init,
 	.readlock	= tasks_trace_scale_read_lock,
@@ -693,7 +693,7 @@ rcu_scale_writer(void *arg)
 }
 
 static void
-rcu_scale_print_module_parms(struct rcu_scale_ops *cur_ops, const char *tag)
+rcu_scale_print_module_parms(const struct rcu_scale_ops *cur_ops, const char *tag)
 {
 	pr_alert("%s" SCALE_FLAG
 		 "--- %s: gp_async=%d gp_async_max=%d gp_exp=%d holdoff=%d minruntime=%d nreaders=%d nwriters=%d nexp=%d exp_interval=%d writer_holdoff=%d writer_holdoff_jiffies=%d verbose=%d shutdown_secs=%d\n",
@@ -1109,7 +1109,7 @@ rcu_scale_init(void)
 	int firsterr = 0;
 	long i;
 	long j;
-	static struct rcu_scale_ops *scale_ops[] = {
+	static const struct rcu_scale_ops *scale_ops[] = {
 		&rcu_ops, &srcu_ops, &srcud_ops, TASKS_OPS TASKS_RUDE_OPS TASKS_TRACING_OPS
 	};
 
-- 
2.56.0

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Bradley Morgan]

On 7 November 2026 21:02:25 GMT, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> 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
>

Well, thanks. so you just consted rcu_scale_ops()? Uhh, well, this makes
enough sense to be feasible

Reviewed-by: Bradley Morgan
<brads@mainlining.org>

But how is this worth it? Why doesn't this work now? how will this make it
better? Those are my questions. 

Well, I'm shrugging, but my tag would stand here, because it won't break
anything in particular.

>Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>---
>Compile tested only.
>---
> kernel/rcu/rcuscale.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
>diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
>index 1097ec15879c..522f7bc2e693 100644
>--- a/kernel/rcu/rcuscale.c
>+++ b/kernel/rcu/rcuscale.c
>@@ -159,7 +159,7 @@ struct rcu_scale_ops {
> 	const char *name;
> };
> 
>-static struct rcu_scale_ops *cur_ops;
>+static const struct rcu_scale_ops *cur_ops;
> 
> /*
>  * Definitions for rcu scalability testing.
>@@ -185,7 +185,7 @@ static void rcu_sync_scale_init(void)
> {
> }
> 
>-static struct rcu_scale_ops rcu_ops = {
>+static const struct rcu_scale_ops rcu_ops = {
> 	.ptype		= RCU_FLAVOR,
> 	.init		= rcu_sync_scale_init,
> 	.readlock	= rcu_scale_read_lock,
>@@ -247,7 +247,7 @@ static void srcu_scale_synchronize_expedited(void)
> 	synchronize_srcu_expedited(srcu_ctlp);
> }
> 
>-static struct rcu_scale_ops srcu_ops = {
>+static const struct rcu_scale_ops srcu_ops = {
> 	.ptype		= SRCU_FLAVOR,
> 	.init		= rcu_sync_scale_init,
> 	.readlock	= srcu_scale_read_lock,
>@@ -276,7 +276,7 @@ static void srcu_sync_scale_cleanup(void)
> 	cleanup_srcu_struct(srcu_ctlp);
> }
> 
>-static struct rcu_scale_ops srcud_ops = {
>+static const struct rcu_scale_ops srcud_ops = {
> 	.ptype		= SRCU_FLAVOR,
> 	.init		= srcu_sync_scale_init,
> 	.cleanup	= srcu_sync_scale_cleanup,
>@@ -313,7 +313,7 @@ static void rcu_tasks_scale_stats(void)
> 	rcu_tasks_torture_stats_print(scale_type, SCALE_FLAG);
> }
> 
>-static struct rcu_scale_ops tasks_ops = {
>+static const struct rcu_scale_ops tasks_ops = {
> 	.ptype		= RCU_TASKS_FLAVOR,
> 	.init		= rcu_sync_scale_init,
> 	.readlock	= tasks_scale_read_lock,
>@@ -357,7 +357,7 @@ static void rcu_tasks_rude_scale_stats(void)
> 	rcu_tasks_rude_torture_stats_print(scale_type, SCALE_FLAG);
> }
> 
>-static struct rcu_scale_ops tasks_rude_ops = {
>+static const struct rcu_scale_ops tasks_rude_ops = {
> 	.ptype		= RCU_TASKS_RUDE_FLAVOR,
> 	.init		= rcu_sync_scale_init,
> 	.readlock	= tasks_rude_scale_read_lock,
>@@ -396,7 +396,7 @@ static void tasks_trace_scale_read_unlock(int idx)
> 	rcu_read_unlock_trace();
> }
> 
>-static struct rcu_scale_ops tasks_tracing_ops = {
>+static const struct rcu_scale_ops tasks_tracing_ops = {
> 	.ptype		= RCU_TASKS_FLAVOR,
> 	.init		= rcu_sync_scale_init,
> 	.readlock	= tasks_trace_scale_read_lock,
>@@ -693,7 +693,7 @@ rcu_scale_writer(void *arg)
> }
> 
> static void
>-rcu_scale_print_module_parms(struct rcu_scale_ops *cur_ops, const char *tag)
>+rcu_scale_print_module_parms(const struct rcu_scale_ops *cur_ops, const char *tag)
> {
> 	pr_alert("%s" SCALE_FLAG
> 		 "--- %s: gp_async=%d gp_async_max=%d gp_exp=%d holdoff=%d minruntime=%d nreaders=%d nwriters=%d nexp=%d exp_interval=%d writer_holdoff=%d writer_holdoff_jiffies=%d verbose=%d shutdown_secs=%d\n",
>@@ -1109,7 +1109,7 @@ rcu_scale_init(void)
> 	int firsterr = 0;
> 	long i;
> 	long j;
>-	static struct rcu_scale_ops *scale_ops[] = {
>+	static const struct rcu_scale_ops *scale_ops[] = {
> 		&rcu_ops, &srcu_ops, &srcud_ops, TASKS_OPS TASKS_RUDE_OPS TASKS_TRACING_OPS
> 	};
> 
>

--- Thanks!

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Christophe JAILLET]

Le 08/11/2026 à 00:25, Bradley Morgan a écrit :
> On 7 November 2026 21:02:25 GMT, Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> 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
>>
> 
> Well, thanks. so you just consted rcu_scale_ops()? Uhh, well, this makes
> enough sense to be feasible
> 
> Reviewed-by: Bradley Morgan
> <brads@mainlining.org>
> 
> But how is this worth it? Why doesn't this work now? how will this make it
> better? Those are my questions.

Nut sure to fully understand your point.

- how is this worth it?
The patch is simple and easy to review.
The struct rcu_scale_ops is local to this file, so no side effect is 
expected. It is compile tested.
So the additional security it brings (some function pointers that are 
now read-only) is a win to nearly no cost.

- Why doesn't this work now?
It does work now. The patch is not a fix, just an improvement.

-how will this make it better?
The function pointers that are now read-only can't be modified. So the 
code is safer.
A modification could be done by a bug that writes memory at an 
unexpected location or by an attacker that would manage to overwrite 
these function pointers to change the behavior of the code.
In general, RO data is preferred to RW when possible.

Hoping this answers your question.

CJ

> 
> Well, I'm shrugging, but my tag would stand here, because it won't break
> anything in particular.
> 
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> Compile tested only.
>> ---
>> kernel/rcu/rcuscale.c | 18 +++++++++---------
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
>> index 1097ec15879c..522f7bc2e693 100644
>> --- a/kernel/rcu/rcuscale.c
>> +++ b/kernel/rcu/rcuscale.c
>> @@ -159,7 +159,7 @@ struct rcu_scale_ops {
>> 	const char *name;
>> };
>>
>> -static struct rcu_scale_ops *cur_ops;
>> +static const struct rcu_scale_ops *cur_ops;
>>
>> /*
>>   * Definitions for rcu scalability testing.
>> @@ -185,7 +185,7 @@ static void rcu_sync_scale_init(void)
>> {
>> }
>>
>> -static struct rcu_scale_ops rcu_ops = {
>> +static const struct rcu_scale_ops rcu_ops = {
>> 	.ptype		= RCU_FLAVOR,
>> 	.init		= rcu_sync_scale_init,
>> 	.readlock	= rcu_scale_read_lock,
>> @@ -247,7 +247,7 @@ static void srcu_scale_synchronize_expedited(void)
>> 	synchronize_srcu_expedited(srcu_ctlp);
>> }
>>
>> -static struct rcu_scale_ops srcu_ops = {
>> +static const struct rcu_scale_ops srcu_ops = {
>> 	.ptype		= SRCU_FLAVOR,
>> 	.init		= rcu_sync_scale_init,
>> 	.readlock	= srcu_scale_read_lock,
>> @@ -276,7 +276,7 @@ static void srcu_sync_scale_cleanup(void)
>> 	cleanup_srcu_struct(srcu_ctlp);
>> }
>>
>> -static struct rcu_scale_ops srcud_ops = {
>> +static const struct rcu_scale_ops srcud_ops = {
>> 	.ptype		= SRCU_FLAVOR,
>> 	.init		= srcu_sync_scale_init,
>> 	.cleanup	= srcu_sync_scale_cleanup,
>> @@ -313,7 +313,7 @@ static void rcu_tasks_scale_stats(void)
>> 	rcu_tasks_torture_stats_print(scale_type, SCALE_FLAG);
>> }
>>
>> -static struct rcu_scale_ops tasks_ops = {
>> +static const struct rcu_scale_ops tasks_ops = {
>> 	.ptype		= RCU_TASKS_FLAVOR,
>> 	.init		= rcu_sync_scale_init,
>> 	.readlock	= tasks_scale_read_lock,
>> @@ -357,7 +357,7 @@ static void rcu_tasks_rude_scale_stats(void)
>> 	rcu_tasks_rude_torture_stats_print(scale_type, SCALE_FLAG);
>> }
>>
>> -static struct rcu_scale_ops tasks_rude_ops = {
>> +static const struct rcu_scale_ops tasks_rude_ops = {
>> 	.ptype		= RCU_TASKS_RUDE_FLAVOR,
>> 	.init		= rcu_sync_scale_init,
>> 	.readlock	= tasks_rude_scale_read_lock,
>> @@ -396,7 +396,7 @@ static void tasks_trace_scale_read_unlock(int idx)
>> 	rcu_read_unlock_trace();
>> }
>>
>> -static struct rcu_scale_ops tasks_tracing_ops = {
>> +static const struct rcu_scale_ops tasks_tracing_ops = {
>> 	.ptype		= RCU_TASKS_FLAVOR,
>> 	.init		= rcu_sync_scale_init,
>> 	.readlock	= tasks_trace_scale_read_lock,
>> @@ -693,7 +693,7 @@ rcu_scale_writer(void *arg)
>> }
>>
>> static void
>> -rcu_scale_print_module_parms(struct rcu_scale_ops *cur_ops, const char *tag)
>> +rcu_scale_print_module_parms(const struct rcu_scale_ops *cur_ops, const char *tag)
>> {
>> 	pr_alert("%s" SCALE_FLAG
>> 		 "--- %s: gp_async=%d gp_async_max=%d gp_exp=%d holdoff=%d minruntime=%d nreaders=%d nwriters=%d nexp=%d exp_interval=%d writer_holdoff=%d writer_holdoff_jiffies=%d verbose=%d shutdown_secs=%d\n",
>> @@ -1109,7 +1109,7 @@ rcu_scale_init(void)
>> 	int firsterr = 0;
>> 	long i;
>> 	long j;
>> -	static struct rcu_scale_ops *scale_ops[] = {
>> +	static const struct rcu_scale_ops *scale_ops[] = {
>> 		&rcu_ops, &srcu_ops, &srcud_ops, TASKS_OPS TASKS_RUDE_OPS TASKS_TRACING_OPS
>> 	};
>>
>>
> 
> --- Thanks!

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Joel Fernandes]

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?

Do you mind runtime testing it too if you still feel we should do it (and
provide reasons why)?

thanks,

Joel Fernandes


> ---
>  kernel/rcu/rcuscale.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/rcu/rcuscale.c b/kernel/rcu/rcuscale.c
> index 1097ec15879c..522f7bc2e693 100644
> --- a/kernel/rcu/rcuscale.c
> +++ b/kernel/rcu/rcuscale.c
> @@ -159,7 +159,7 @@ struct rcu_scale_ops {
>  	const char *name;
>  };
>  
> -static struct rcu_scale_ops *cur_ops;
> +static const struct rcu_scale_ops *cur_ops;
>  
>  /*
>   * Definitions for rcu scalability testing.
> @@ -185,7 +185,7 @@ static void rcu_sync_scale_init(void)
>  {
>  }
>  
> -static struct rcu_scale_ops rcu_ops = {
> +static const struct rcu_scale_ops rcu_ops = {
>  	.ptype		= RCU_FLAVOR,
>  	.init		= rcu_sync_scale_init,
>  	.readlock	= rcu_scale_read_lock,
> @@ -247,7 +247,7 @@ static void srcu_scale_synchronize_expedited(void)
>  	synchronize_srcu_expedited(srcu_ctlp);
>  }
>  
> -static struct rcu_scale_ops srcu_ops = {
> +static const struct rcu_scale_ops srcu_ops = {
>  	.ptype		= SRCU_FLAVOR,
>  	.init		= rcu_sync_scale_init,
>  	.readlock	= srcu_scale_read_lock,
> @@ -276,7 +276,7 @@ static void srcu_sync_scale_cleanup(void)
>  	cleanup_srcu_struct(srcu_ctlp);
>  }
>  
> -static struct rcu_scale_ops srcud_ops = {
> +static const struct rcu_scale_ops srcud_ops = {
>  	.ptype		= SRCU_FLAVOR,
>  	.init		= srcu_sync_scale_init,
>  	.cleanup	= srcu_sync_scale_cleanup,
> @@ -313,7 +313,7 @@ static void rcu_tasks_scale_stats(void)
>  	rcu_tasks_torture_stats_print(scale_type, SCALE_FLAG);
>  }
>  
> -static struct rcu_scale_ops tasks_ops = {
> +static const struct rcu_scale_ops tasks_ops = {
>  	.ptype		= RCU_TASKS_FLAVOR,
>  	.init		= rcu_sync_scale_init,
>  	.readlock	= tasks_scale_read_lock,
> @@ -357,7 +357,7 @@ static void rcu_tasks_rude_scale_stats(void)
>  	rcu_tasks_rude_torture_stats_print(scale_type, SCALE_FLAG);
>  }
>  
> -static struct rcu_scale_ops tasks_rude_ops = {
> +static const struct rcu_scale_ops tasks_rude_ops = {
>  	.ptype		= RCU_TASKS_RUDE_FLAVOR,
>  	.init		= rcu_sync_scale_init,
>  	.readlock	= tasks_rude_scale_read_lock,
> @@ -396,7 +396,7 @@ static void tasks_trace_scale_read_unlock(int idx)
>  	rcu_read_unlock_trace();
>  }
>  
> -static struct rcu_scale_ops tasks_tracing_ops = {
> +static const struct rcu_scale_ops tasks_tracing_ops = {
>  	.ptype		= RCU_TASKS_FLAVOR,
>  	.init		= rcu_sync_scale_init,
>  	.readlock	= tasks_trace_scale_read_lock,
> @@ -693,7 +693,7 @@ rcu_scale_writer(void *arg)
>  }
>  
>  static void
> -rcu_scale_print_module_parms(struct rcu_scale_ops *cur_ops, const char *tag)
> +rcu_scale_print_module_parms(const struct rcu_scale_ops *cur_ops, const char *tag)
>  {
>  	pr_alert("%s" SCALE_FLAG
>  		 "--- %s: gp_async=%d gp_async_max=%d gp_exp=%d holdoff=%d minruntime=%d nreaders=%d nwriters=%d nexp=%d exp_interval=%d writer_holdoff=%d writer_holdoff_jiffies=%d verbose=%d shutdown_secs=%d\n",
> @@ -1109,7 +1109,7 @@ rcu_scale_init(void)
>  	int firsterr = 0;
>  	long i;
>  	long j;
> -	static struct rcu_scale_ops *scale_ops[] = {
> +	static const struct rcu_scale_ops *scale_ops[] = {
>  		&rcu_ops, &srcu_ops, &srcud_ops, TASKS_OPS TASKS_RUDE_OPS TASKS_TRACING_OPS
>  	};
>  
> -- 
> 2.56.0
> 

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Christophe JAILLET]

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.

CJ

> 
> Do you mind runtime testing it too if you still feel we should do it (and
> provide reasons why)?
> 
> thanks,
> 
> Joel Fernandes
> 

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Paul E. McKenney]

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.

Thoughts?

							Thanx, Paul

> CJ
> 
> > 
> > Do you mind runtime testing it too if you still feel we should do it (and
> > provide reasons why)?
> > 
> > thanks,
> > 
> > Joel Fernandes
> > 

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Dan Carpenter]

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.

regards,
dan carpenter

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Paul E. McKenney]

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.

							Thanx, Paul

Re: [PATCH] rcuscale: Constify struct rcu_scale_ops

[Bradley Morgan]

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!