From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Liping Zhang <zlpnobody@163.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
David Miller <davem@davemloft.net>,
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Liping Zhang <zlpnobody@gmail.com>
Subject: Re: [PATCH 3/3] sysctl: report EINVAL if value is larger than UINT_MAX for proc_douintvec
Date: Fri, 07 Apr 2017 16:01:16 -0500 [thread overview]
Message-ID: <87k26w0w6b.fsf@xmission.com> (raw)
In-Reply-To: <CA+55aFy4b8ir1mg2ToGfYyLh_GLa+07iYcx0m+_cXkgTbh-sYg@mail.gmail.com> (Linus Torvalds's message of "Fri, 7 Apr 2017 09:49:25 -0700")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, Apr 7, 2017 at 8:51 AM, Liping Zhang <zlpnobody@163.com> wrote:
>> From: Liping Zhang <zlpnobody@gmail.com>
>>
>> Currently, inputting the following command will succeed but actually the
>> value will be truncated:
>> # echo 0x12ffffffff > /proc/sys/net/ipv4/tcp_notsent_lowat
>>
>> This is not friendly to the user, so instead, we should report error
>> when the value is larger than UINT_MAX.
>
> I applied the two other patches, but I didn't apply this one.
>
> It's entirely possible that people end up doing something like
>
> echo -1 > /proc/sys/some_random_uint
>
> because that's a fairly normal thing to do to set all bits. Making
> that an error seems wrong.
Except that doesn't help in this case. The function do_uintvec_conv
rules already rejects all negative values on write. So -1 is already
rejected.
In fact the function proc_douintvec_conv has always rejected negative
values so this change won't even create a regression.
So it looks perfectly reasonable to reject values that are simply too
large to be written to the uint.
So even today to write all bits set you do have to do:
echo 0xffffffff > /proc/sys/some_random_uint
Eric
next prev parent reply other threads:[~2017-04-07 21:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 15:51 [PATCH 0/3] sysctl: fix some bugs related to proc_douintvec Liping Zhang
2017-04-07 15:51 ` [PATCH 1/3] sysctl: add sanity check for proc_douintvec Liping Zhang
2017-04-07 15:51 ` [PATCH 2/3] sysctl: don't print negative flag " Liping Zhang
2017-04-07 15:51 ` [PATCH 3/3] sysctl: report EINVAL if value is larger than UINT_MAX " Liping Zhang
2017-04-07 16:49 ` Linus Torvalds
2017-04-07 21:01 ` Eric W. Biederman [this message]
2017-04-08 17:21 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k26w0w6b.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=subashab@codeaurora.org \
--cc=torvalds@linux-foundation.org \
--cc=zlpnobody@163.com \
--cc=zlpnobody@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.