From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7052C433E0 for ; Fri, 12 Feb 2021 23:49:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 97E4F64E2A for ; Fri, 12 Feb 2021 23:49:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231663AbhBLXta (ORCPT ); Fri, 12 Feb 2021 18:49:30 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:38418 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231743AbhBLXtU (ORCPT ); Fri, 12 Feb 2021 18:49:20 -0500 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lAiAw-001KYF-6b; Fri, 12 Feb 2021 16:48:38 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lAiAs-00AAwv-BU; Fri, 12 Feb 2021 16:48:37 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Matthew Wilcox Cc: Joe Perches , Andrew Morton , Alexey Dobriyan , linux-fsdevel , LKML References: <85ff6fd6b26aafdf6087666629bad3acc29258d8.camel@perches.com> <20210212221918.GA2858050@casper.infradead.org> Date: Fri, 12 Feb 2021 17:48:16 -0600 In-Reply-To: <20210212221918.GA2858050@casper.infradead.org> (Matthew Wilcox's message of "Fri, 12 Feb 2021 22:19:18 +0000") Message-ID: 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=1lAiAs-00AAwv-BU;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/kBYeaNDremxU4TaUBAJy1fsy5iUdwbQQ= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] proc: Convert S_ permission uses to octal X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Matthew Wilcox writes: > On Fri, Feb 12, 2021 at 04:01:48PM -0600, Eric W. Biederman wrote: >> Joe Perches writes: >> >> > Convert S_ permissions to the more readable octal. >> > >> > Done using: >> > $ ./scripts/checkpatch.pl -f --fix-inplace --types=SYMBOLIC_PERMS fs/proc/*.[ch] >> > >> > No difference in generated .o files allyesconfig x86-64 >> > >> > Link: >> > https://lore.kernel.org/lkml/CA+55aFw5v23T-zvDZp-MmD_EYxF8WbafwwB59934FV7g21uMGQ@mail.gmail.com/ >> >> >> I will be frank. I don't know what 0644 means. I can never remember >> which bit is read, write or execute. So I like symbolic constants. > > Heh, I'm the other way, I can't remember what S_IRUGO means. > > but I think there's another way which improves the information > density: > > #define DIR_RO_ALL(NAME, iops, fops) DIR(NAME, 0555, iops, fops) > ... > (or S_IRUGO or whatever expands to 0555) > > There's really only a few combinations -- > root read-only, > everybody read-only > root-write, others-read > everybody-write > > and execute is only used by proc for directories, not files, so I think > there's only 8 combinations we'd need (and everybody-write is almost > unused ...) I guess it depends on which part of proc. For fs/proc/base.c and it's per process relatives something like that seems reasonable. I don't know about fs/proc/generic.c where everyone from all over the kernel registers new proc entries. >> Perhaps we can do something like: >> >> #define S_IRWX 7 >> #define S_IRW_ 6 >> #define S_IR_X 5 >> #define S_IR__ 4 >> #define S_I_WX 3 >> #define S_I_W_ 2 >> #define S_I__X 1 >> #define S_I___ 0 >> >> #define MODE(TYPE, USER, GROUP, OTHER) \ >> (((S_IF##TYPE) << 9) | \ >> ((S_I##USER) << 6) | \ >> ((S_I##GROUP) << 3) | \ >> (S_I##OTHER)) >> >> Which would be used something like: >> MODE(DIR, RWX, R_X, R_X) >> MODE(REG, RWX, R__, R__) >> >> Something like that should be able to address the readability while >> still using symbolic constants. > > I think that's been proposed before. I don't think it has ever been shot down. Just no one care enough to implement it. Come to think of it, that has the nice property that if we cared we could make it type safe as well. Something we can't do with the octal for obvious reasons. Eric