On 2016/12/3 3:24, Eric W. Biederman wrote: > Yisheng Xie <xieyishe...@huawei.com> writes: > >> On 2016/12/1 5:33, Andrew Morton wrote: >>> On Wed, 30 Nov 2016 18:30:52 +0800 Yisheng Xie <xieyishe...@huawei.com> >>> wrote: >>> >>>> I tried to echo an invalid value to an unsigned long type sysctl on >>>> 4.9.0-rc6: >>>> linux:~# cat /proc/sys/vm/user_reserve_kbytes >>>> 131072 >>>> linux:~# echo -1 > /proc/sys/vm/user_reserve_kbytes >>>> linux:~# cat /proc/sys/vm/user_reserve_kbytes >>>> 131072 >>>> >>>> The echo operation got error and the value do not write to >>>> user_reserve_kbytes, however, user do not know it until checking >>>> the value again. >>>> >>>> This patch return -EINVAL when write an invalid value to unsigned >>>> long type sysctl to make user know what happened without >>>> checking its value once more, just as what proc_douintvec do. >>> >>> hmpf. >>> >>> # echo 18446744073709551615 > /proc/sys/vm/user_reserve_kbytes >>> >>> # cat /proc/sys/vm/user_reserve_kbytes >>> 18446744073709551615 >>> >>> I think that when taking in an unsigned long the kernel should simply >>> treat -1 as 0xffffffff (or 0xffffffffffffffff). It's natural and >>> normal and everyone knows what it means? >>> >> Hi Andrew, >> Thank you for your reply. >> Do you means it should be like this: >> # echo -1 > /proc/sys/vm/user_reserve_kbytes >> # cat /proc/sys/vm/user_reserve_kbytes >> 18446744073709551615 >> >> I looks ok to me, however, I not sure whether other code in the kernel >> will also use its complement if user write a negative number for an >> unsigned long. Does anyone have other opinion ? > > Largely we need to be very careful with changing these functions as > they have been around for a long time, and have a very diverse set of > users. Hi Eric, Thanks for your reply. That right.
> > So while changes are possible a reasonable argument needs to be made > that nothing in userspace cares. > So the patch's original aim that return -EINVAL when user write invalid val to ulong type sysctl is more reasonable, Right? Thanks, Yisheng Xie > Eric > > . >
