Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1998162ybb; Thu, 2 Apr 2020 11:09:04 -0700 (PDT) X-Google-Smtp-Source: APiQypK/muj1Gx1V9HJITs0TIg93uKnLHcocFxhrLd/nBNepXXzSSWOP2G49dsbOa1+91kgLwZ1E X-Received: by 2002:a4a:a88a:: with SMTP id q10mr3831835oom.17.1585850944660; Thu, 02 Apr 2020 11:09:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585850944; cv=none; d=google.com; s=arc-20160816; b=lt8LpuQ6PdH7Rz1r5ksMC+FLlhErD9t8xj1tDUE9BUKBIE0HoIwEA1XDkIn7fS1XLm m3IoTGr36pjd3ggDoDvE3jmSyeW8KvSx0jf5ERmiXjYrjvgySKodxkNpoCtGc+T1EY1p +xwYldzwFM/TzFDbylQ2GLHZ1qDzHL1EoWUZfIIBwwY+YKHzL9zzi8FVQ2AQpOgM6vrR w+Yg3dTr23s1EKY8ayukeNDJj2eEDjMQF9JoeSck9qgNEB+o/E1lohAhLTbu12JIaec/ iPdpWUwr+oD4DqZbHxzf8OO78CO3kqtp2jKdoTnnmUw3urv3E2bgyDh99sEPlTMR+ylV bxKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:mime-version:user-agent :message-id:in-reply-to:date:references:cc:to:from; bh=5kGsITvjo5zaKUOzstmi3zxcc5BsprOjQog9cbuQ2E0=; b=meSaMP5fDnuBjRGjyJF8aScIHVEDTiONGfI2pmWIM4BbMsUKGFzrymllO6ATiDynXl bvbzHH+ILDGYDpQSu7ia4rh+LLcACtzD3+EEZ3o8XNGZdPrV5zn3zHUJC3rSvlJhF8MP zeSXrQbXvNUPODlPRhYl6NRjVDTRHiTFDmliPksxgAJBnq4oOTU275ttG9q9ihiYscRL q3qQ91C5BPjhra1gmxksavWT2pwcswtDqcvnL11SLmUTTIahvHHDRPomNtnukq+f3MpC nDggSxAYGsgFREtGzeKusL8FC9FM6FV/zwqpLWwBdIoSaUTvbiEc3DErE+Zju2ELhxdB zMJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j15si2733687oos.59.2020.04.02.11.08.51; Thu, 02 Apr 2020 11:09:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xmission.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389972AbgDBRBQ (ORCPT + 99 others); Thu, 2 Apr 2020 13:01:16 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:52874 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389711AbgDBRBQ (ORCPT ); Thu, 2 Apr 2020 13:01:16 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jK3DO-0008Jh-Ms; Thu, 02 Apr 2020 11:01:14 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jK3DN-0008NS-8i; Thu, 02 Apr 2020 11:01:14 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Alexey Gladkov Cc: LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , Alexander Viro , Alexey Dobriyan , Alexey Gladkov , Andrew Morton , Andy Lutomirski , Daniel Micay , Djalal Harouni , "Dmitry V . Levin" , Greg Kroah-Hartman , Ingo Molnar , "J . Bruce Fields" , Jeff Layton , Jonathan Corbet , Kees Cook , Linus Torvalds , Oleg Nesterov References: <20200327172331.418878-1-gladkov.alexey@gmail.com> <20200327172331.418878-8-gladkov.alexey@gmail.com> Date: Thu, 02 Apr 2020 11:58:28 -0500 In-Reply-To: <20200327172331.418878-8-gladkov.alexey@gmail.com> (Alexey Gladkov's message of "Fri, 27 Mar 2020 18:23:29 +0100") Message-ID: <875zehkeob.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1jK3DN-0008NS-8i;;;mid=<875zehkeob.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+Ru1GXxpvu1H/HwnkkVQs5oho2OLsbxwc= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa06.xmission.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4832] * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Alexey Gladkov X-Spam-Relay-Country: X-Spam-Timing: total 752 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (1.5%), b_tie_ro: 10 (1.3%), parse: 0.88 (0.1%), extract_message_metadata: 4.2 (0.6%), get_uri_detail_list: 2.1 (0.3%), tests_pri_-1000: 5 (0.7%), tests_pri_-950: 1.25 (0.2%), tests_pri_-900: 1.06 (0.1%), tests_pri_-90: 199 (26.5%), check_bayes: 197 (26.2%), b_tokenize: 10 (1.3%), b_tok_get_all: 99 (13.1%), b_comp_prob: 2.4 (0.3%), b_tok_touch_all: 83 (11.0%), b_finish: 0.96 (0.1%), tests_pri_0: 511 (67.9%), check_dkim_signature: 0.87 (0.1%), check_dkim_adsp: 2.4 (0.3%), poll_dns_idle: 0.31 (0.0%), tests_pri_10: 2.1 (0.3%), tests_pri_500: 8 (1.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v10 7/9] proc: move hidepid values to uapi as they are user interface to mount 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I will just say that I do not understand exporting this to the uapi headers. Why do we want to export the enumeration names? I understand that the values are uapi. This looks like it will make it difficult to make changes that rename enumeration values to make the code more readable. Given that this patchset goes immediately to using string enumerated values, I also don't understand the point of exporting HIDEPID_NOT_PTRACEABLE. I don't think we need to ever let people use the numeric value. My sense is that if we are switching to string values we should just leave the existing numeric values as backwards compatiblity and not do anything to make them easier to use. Eric Alexey Gladkov writes: > Suggested-by: Alexey Dobriyan > Reviewed-by: Alexey Dobriyan > Signed-off-by: Alexey Gladkov > --- > include/linux/proc_fs.h | 9 +-------- > include/uapi/linux/proc_fs.h | 13 +++++++++++++ > 2 files changed, 14 insertions(+), 8 deletions(-) > create mode 100644 include/uapi/linux/proc_fs.h > > diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h > index afd38cae2339..d259817ec913 100644 > --- a/include/linux/proc_fs.h > +++ b/include/linux/proc_fs.h > @@ -7,6 +7,7 @@ > > #include > #include > +#include > > struct proc_dir_entry; > struct seq_file; > @@ -27,14 +28,6 @@ struct proc_ops { > unsigned long (*proc_get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long); > }; > > -/* definitions for hide_pid field */ > -enum { > - HIDEPID_OFF = 0, > - HIDEPID_NO_ACCESS = 1, > - HIDEPID_INVISIBLE = 2, > - HIDEPID_NOT_PTRACEABLE = 4, /* Limit pids to only ptraceable pids */ > -}; > - > /* definitions for proc mount option pidonly */ > enum { > PROC_PIDONLY_OFF = 0, > diff --git a/include/uapi/linux/proc_fs.h b/include/uapi/linux/proc_fs.h > new file mode 100644 > index 000000000000..dc6d717aa6ec > --- /dev/null > +++ b/include/uapi/linux/proc_fs.h > @@ -0,0 +1,13 @@ > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > +#ifndef _UAPI_PROC_FS_H > +#define _UAPI_PROC_FS_H > + > +/* definitions for hide_pid field */ > +enum { > + HIDEPID_OFF = 0, > + HIDEPID_NO_ACCESS = 1, > + HIDEPID_INVISIBLE = 2, > + HIDEPID_NOT_PTRACEABLE = 4, > +}; > + > +#endif