From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752986AbbIKNtr (ORCPT <rfc822;w@1wt.eu>);
	Fri, 11 Sep 2015 09:49:47 -0400
Received: from smtprelay0117.hostedemail.com ([216.40.44.117]:37325 "EHLO
	smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1752167AbbIKNtp (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 11 Sep 2015 09:49:45 -0400
X-Session-Marker: 726F737465647440676F6F646D69732E6F7267
X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1539:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2693:3138:3139:3140:3141:3142:3352:3622:3865:3866:3868:3870:3871:3872:3873:3874:5007:6261:6742:7514:7875:7903:10004:10400:10471:10848:10967:11232:11658:11914:12517:12519:12740:13069:13161:13229:13255:13311:13357:21080:21212,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0
X-HE-Tag: wheel74_37c6434a9025f
X-Filterd-Recvd-Size: 3049
Date: Fri, 11 Sep 2015 09:49:41 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Sean Fu <fxinrong@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Austin S Hemmelgarn <ahferroin7@gmail.com>,
        Andrey Ryabinin <ryabinin.a.a@gmail.com>,
        Ulrich Obergfell <uobergfe@redhat.com>,
        Prarit Bhargava <prarit@redhat.com>,
        Eric B Munson <emunson@akamai.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Thomas Gleixner <tglx@linutronix.de>, Don Zickus <dzickus@redhat.com>,
        Heinrich Schuchardt <xypron.glpk@gmx.de>,
        David Rientjes <rientjes@google.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel/sysctl.c: If "count" including the terminating
 byte '\0' the write system call should retrun success.
Message-ID: <20150911094941.784c8a93@gandalf.local.home>
In-Reply-To: <CAGk-QBsj6WMJZfhTedhn1zSqS4zSe=rjnvazK+GY8HJbzFE90g@mail.gmail.com>
References: <CAGk-QBt147T_A-BuPn1M2rHkQaCn0_RXgZvx3Zbf9L3_7CDQtQ@mail.gmail.com>
	<CAGk-QBsNhHH5p4PrG3-sCjKGaUbv1cQ8vAJmdQKVF2iFCbt0+g@mail.gmail.com>
	<20150825101507.4e3be4ca@gandalf.local.home>
	<CAGk-QBsHeddJ3Ywu+6GM6=4iL8E+M97i-KgCEYWRFPM+tfQZMA@mail.gmail.com>
	<55DCA705.8000903@gmail.com>
	<20150825150536.546a73e5@gandalf.local.home>
	<CAGk-QBte6bWGWWYGy=UmyqFuchy_94pr2o7B9p1tK=dgU+CK1Q@mail.gmail.com>
	<20150826163621.28d7990a@gandalf.local.home>
	<CAGk-QBtv5a4+x=XAi5TE+icUjuiZwnZNkfMvcAAOOOCt=uRzGw@mail.gmail.com>
	<20150826223230.4348d936@grimm.local.home>
	<CAGk-QBvVXmviuM4i6TzBqGV8q+1H4pOa8mMn3DreYMPytRwWag@mail.gmail.com>
	<CAGk-QBtmbkVukWO-kSxUEj_nyZHnxho-RfHRoH_PgcPRdmZxDA@mail.gmail.com>
	<CAGk-QBstqwMwYVBtWJbzcGnsEYX_JkkzopNex=wd_U-kqB6H8g@mail.gmail.com>
	<20150908111730.6a1ecca6@gandalf.local.home>
	<87si6oq3y5.fsf@x220.int.ebiederm.org>
	<20150908123616.09589bfe@gandalf.local.home>
	<CAGk-QBsj6WMJZfhTedhn1zSqS4zSe=rjnvazK+GY8HJbzFE90g@mail.gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 11 Sep 2015 17:05:31 +0800
Sean Fu <fxinrong@gmail.com> wrote:


> > Sounds like a reasonable compromise. Sean, can you make a patch that
> > only affects the one proc file (comment it well in the code), and have
> > it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
> > would only see "1 "

> The current code uses uniform handler (e.g. "proc_dointvec") for all
> same type proc file.
> So all integer type proc file are affected.
> In fact, The behavior of all integer type proc file should be changed.


Then at least make it where the \0 is the terminating string. Nothing
after it will be seen by the rest of the code in the kernel.

-- Steve