On 03/13/2018 01:46 PM, Eric W. Biederman wrote: > Waiman Long <longman@xxxxxxxxxx> 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 future. Cheers, Longman
