On 03/13/2018 01:46 PM, Eric W. Biederman wrote:
> Waiman Long <long...@redhat.com> writes:
>> When minimum/maximum values are specified for a sysctl parameter in
>> the ctl_table structure with proc_dointvec_minmax() handler, update
>> to that parameter will fail with error if the given value is outside
>> of the required range.
>> There are use cases where it may be better to clamp the value of
>> the sysctl parameter to the given range without failing the update,
>> especially if the users are not aware of the actual range limits.
>> Reading the value back after the update will now be a good practice
>> to see if the provided value exceeds the range limits.
> What use cases? Who will break. Examples would be good.
See my response to the 4/6 patch.
>> To provide this less restrictive form of range checking, a new flags
>> field is added to the ctl_table structure.
>> When the CTL_FLAGS_CLAMP_RANGE flag is set in the ctl_table
>> entry, any update from the userspace will be clamped to the given
>> range without error if either the proc_dointvec_minmax() or the
>> proc_douintvec_minmax() handlers is used.
> As this is constructed it will increase the size of ctl_table for
> everyone. Better would be to add a new function that behaves similary
> but differently than to burden struct ctl_table for the rest of time.
If you have concern about increasing the size of the ctl_table, I can
revert it back to use unsigned short for flag which will fit into the
hole left by the 16-bit mode field. I thought increasing the size of
ctl_table a bit isn't a big problem, I may be wrong on that.
Adding the new flags field will afford us the ability to better
customize the sysctl parameters to different needs that may arise in the