From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965413AbeEITcE (ORCPT ); Wed, 9 May 2018 15:32:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:32804 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964850AbeEITcD (ORCPT ); Wed, 9 May 2018 15:32:03 -0400 Date: Wed, 9 May 2018 19:32:00 +0000 From: "Luis R. Rodriguez" To: Waiman Long Cc: "Luis R. Rodriguez" , Kees Cook , Andrew Morton , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, Al Viro , Matthew Wilcox , "Eric W. Biederman" Subject: Re: [PATCH v7 1/4] ipc: IPCMNI limit check for msgmni and shmmni Message-ID: <20180509193200.GU27853@wotan.suse.de> References: <1525726752-29281-1-git-send-email-longman@redhat.com> <1525726752-29281-2-git-send-email-longman@redhat.com> <20180507223910.GW27853@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 07, 2018 at 07:57:12PM -0400, Waiman Long wrote: > On 05/07/2018 06:39 PM, Luis R. Rodriguez wrote: > > On Mon, May 07, 2018 at 04:59:09PM -0400, Waiman Long wrote: > >> A user can write arbitrary integer values to msgmni and shmmni sysctl > >> parameters without getting error, but the actual limit is really > >> IPCMNI (32k). This can mislead users as they think they can get a > >> value that is not real. > >> > >> The right limits are now set for msgmni and shmmni so that the users > >> will become aware if they set a value outside of the acceptable range. > >> > >> Signed-off-by: Waiman Long > >> --- > >> ipc/ipc_sysctl.c | 7 +++++-- > >> 1 file changed, 5 insertions(+), 2 deletions(-) > >> > >> diff --git a/ipc/ipc_sysctl.c b/ipc/ipc_sysctl.c > >> index 8ad93c2..f87cb29 100644 > >> --- a/ipc/ipc_sysctl.c > >> +++ b/ipc/ipc_sysctl.c > >> @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, > >> static int zero; > >> static int one = 1; > >> static int int_max = INT_MAX; > >> +static int ipc_mni = IPCMNI; > >> > >> static struct ctl_table ipc_kern_table[] = { > >> { > >> @@ -120,7 +121,9 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, > >> .data = &init_ipc_ns.shm_ctlmni, > >> .maxlen = sizeof(init_ipc_ns.shm_ctlmni), > >> .mode = 0644, > >> - .proc_handler = proc_ipc_dointvec, > >> + .proc_handler = proc_ipc_dointvec_minmax, > >> + .extra1 = &zero, > >> + .extra2 = &ipc_mni, > >> }, > >> { > >> .procname = "shm_rmid_forced", > >> @@ -147,7 +150,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table, int write, > >> .mode = 0644, > >> .proc_handler = proc_ipc_dointvec_minmax, > >> .extra1 = &zero, > >> - .extra2 = &int_max, > >> + .extra2 = &ipc_mni, > >> }, > >> { > >> .procname = "auto_msgmni", > >> -- > >> 1.8.3.1 > > It seems negative values are not allowed, if true then having > > a caller to use proc_douintvec_minmax() would help with ensuring > > no invalid negative input values are used as well. > > > > Luis > > Negative value doesn't mean sense here. So it is true that we can use > proc_douintvec_minmax() instead. However, the data types themselves are > defined as "int". So I think it is better to keep using > proc_dointvec_minmax() to be consistent with the data type. Huh, no... If you *know* the valid values *are* only positive, the right thing to do is to then *change* the data type. Tons of odd bugs can creep up because of these stupid things. Luis