> Yes - that's why I am wondering if we want a general 'sysctl' mutex or
I think for the strings it would be better to just do a kind of copy-on-write.
As in don't use the array directly, but a pointer instead and then sysctl
allocates a new string, switches the pointer around
and then does a RCU delayed free on the old string if it wasn't in .data.
This would also have the advantage that the small upper limits these
strings currently have are gone and actually save a little memory in
the common case of them not being changed.
Only case that wouldn't fix would be someone keeping the string accessed
over a sleep point. And for preemptible kernels it would need rcu_read_lock().
So no free lunch without code auditing. But it would be probably the best
way to go forward longer term.
For multi number arrays the code ideally needs to be robust against temporary
inconsistencies.
BTW while interesting in theory in practice i suspect the actual likelyhood
of a user actually hitting such a race is pretty small because sysctls tend
to be set up a boot only where not much is going on.
-Andi
--
