From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753081AbcLBT1J (ORCPT ); Fri, 2 Dec 2016 14:27:09 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:38911 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbcLBT1H (ORCPT ); Fri, 2 Dec 2016 14:27:07 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Yisheng Xie Cc: Andrew Morton , , , , , , , , , , , , References: <1480501852-36968-1-git-send-email-xieyisheng1@huawei.com> <20161130133358.d508cc8931be6f08ee88561f@linux-foundation.org> <97ca5661-fcae-fe34-810b-d5c6843289e7@huawei.com> Date: Fri, 02 Dec 2016 13:24:07 -0600 In-Reply-To: <97ca5661-fcae-fe34-810b-d5c6843289e7@huawei.com> (Yisheng Xie's message of "Fri, 2 Dec 2016 14:54:32 +0800") Message-ID: <87fum616eg.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1cCtU1-0000CM-MC;;;mid=<87fum616eg.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.225.221;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19Nezc+yrrhRrqi3yII996psMXnXTOkhOs= X-SA-Exim-Connect-IP: 67.3.225.221 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 XM_H_SpoofStaff3 XMission Staff Spoof * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Yisheng Xie X-Spam-Relay-Country: X-Spam-Timing: total 5558 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.7 (0.1%), b_tie_ro: 2.6 (0.0%), parse: 1.23 (0.0%), extract_message_metadata: 26 (0.5%), get_uri_detail_list: 2.5 (0.0%), tests_pri_-1000: 8 (0.1%), tests_pri_-950: 1.94 (0.0%), tests_pri_-900: 1.65 (0.0%), tests_pri_-400: 32 (0.6%), check_bayes: 31 (0.6%), b_tokenize: 12 (0.2%), b_tok_get_all: 8 (0.1%), b_comp_prob: 4.0 (0.1%), b_tok_touch_all: 3.0 (0.1%), b_finish: 0.89 (0.0%), tests_pri_0: 835 (15.0%), check_dkim_signature: 0.82 (0.0%), check_dkim_adsp: 4.6 (0.1%), tests_pri_500: 4642 (83.5%), poll_dns_idle: 4634 (83.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] kernel/sysctl: return -EINVAL if write invalid val to ulong type sysctl X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yisheng Xie writes: > On 2016/12/1 5:33, Andrew Morton wrote: >> On Wed, 30 Nov 2016 18:30:52 +0800 Yisheng Xie 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. So while changes are possible a reasonable argument needs to be made that nothing in userspace cares. Eric