Re: Current state of the sysctl constification effort

[Joel Granados]

On Fri, Jun 07, 2024 at 03:54:01PM +0200, Thomas Weißschuh wrote:
> On 2024-06-07 11:40:53+0000, Joel Granados wrote:
> > On Fri, May 31, 2024 at 12:50:32PM +0200, Thomas Weißschuh wrote:
...
> > Is there anything left to do besides
> > what is being discussed in this mail, to start changing the ctl_tables
> > to `static const`?
> 
> The changes to the tables also need (as per [0] and [1]):
> 
> * sysctl: move internal interfaces to const struct ctl_table
> * sysctl: allow registration of const struct ctl_table
> 
> I think we do the handlers for v6.11, the rest of [0] and [1] for v6.12
> and then we can go through the rest of the trees ctl_tables.

LGTM. Once you send "sysctl: move internal interfaces to const struct ctl_table" and
"sysctl: allow registration of const struct ctl_table", I'll put them
into sysctl-testing and have them there until they can go into sysctl-next
(after the end of the next merge window). Please send both of them in one
series and remember to work on the "what" and the "why" for the commit
messages and cover letter.

You can be inspired by this
"""
# Motivation
The reason we are constifying is:
1. It provides increased safety: Having things in .rodata section reduces the
   attack surface. This is especially relevant for structures that have function
   pointers (like ctl_table); having these in .rodata means that these pointers
   always point to the "intended" function and cannot be changed.
2. Readability: because it is easier to know up-front that data is not supposed
   to change or its obvious that a function is re-entrant. Actually a lot of the
   readability reasons is about knowing things "up-front".
As we move forward with the constification in sysctl, please include a more
detailed motivation in all your cover letters. This helps maintainers (that
don't have the context) understand what you are trying to do.
"""

Best

-- 

Joel Granados