Re: [GIT PULL] sysctl changes for v7.4-rc1

[Joel Granados]

On Fri, Oct 23, 2026 at 09:44:01AM -1000, Linus Torvalds wrote:
> On Tue, 20 Oct 2026 at 03:09, Joel Granados <joel.granados@xxxxxxxxxx> wrote:
> >
> > * Disallow partial vector updates
> >
> >   Stage sysctl vector writes before updating. Removes the chance of leaving a
> >   sysctl vector partially updated due to erroneous input. This is not an atomic
> >   write; a concurrent reader can still see a partially updated vector.
> 
> I've pulled this, but this feels like it could easily break any number
> of random scripts.
> 
> We used to just update until we hit an error, and I would not be AT
> ALL surprised if there are scripts around that echo some
> not-entirely-cleaned-up string to /proc/sys.

Writing fewer elements than the vector or junk after a complete vector
behave exactly as before. What changes is only a write that already
returned EINVAL.

> 
> Put another way: I do not understand why that commit claims that the
> vector data should be unchanged just because the Nth element wasn't a
> number.

Not because the Nth elem is a number, but because the write fails.

Two comments:
1. The vector must remain unchanged on error for internal custom proc
   handlers (like vm.lowmem_reserve_ratio & kernel.sem) to avoid missing
   post-processing of a partially updated vector.

2. The user space that will be affected are the ones that ignore the
   EINVAL return value of the writable numeric sysctl vectors [1] (14: give
   or take) and depend on a subset of it being updated.

In retrospect I see that I missed clarifying the impact of the change. I
made a note of it for next time.

> 
> What was the impetus for this change? Was there an actual problem it
> fixes, or was it just a random decision to possibly break user space?

This all came about from Jianlin Shi's fix for vm.lowmem_reserve_ratio
[2]. An erroneous return from proc_dointvec_minmax meant that
setup_per_zone_lowmem_reserve was not executed even when the some of
sysctl_lowmem_reserve_ratio vector was changed. Andrew's take was that
the handler should parse into a temporary, and that this is really a
flaw in proc_dointvec_minmax(). So not just a random decision.

I see 2 options:
1. Leave this in and I'll address anything that bubbles up in the
   7.4-rcX cycle. With the option of removing it if the impact to user
   space is to big.

2. We remove it before rc1. And make sure that all custom proc handlers
   stage their vectors on write.

Let me know what you prefer or if you have another option.

Best

Joel

[1] kernel.{printk,acct,sem},
    vm.lowmem_reserve_ratio,
    net.ipv4.{tcp_rmem,tcp_wmem,tcp_mem,udp_mem},
    net.sctp.{sctp_mem,sctp_rmem,sctp_wmem},
    net.tipc.{tipc_rmem,sk_filter}
    net.ipv4.vs.sync_threshold 

[2] https://lore.kernel.org/all/tencent_FFD4F4D728AAE8A8AE0AF277A59854A29A06@xxxxxx

Attachment: signature.asc
Description: PGP signature