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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 C8528C636C9 for ; Wed, 21 Jul 2021 13:15:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5494861221 for ; Wed, 21 Jul 2021 13:15:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5494861221 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 22E426B0070; Wed, 21 Jul 2021 09:15:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18D336B0074; Wed, 21 Jul 2021 09:15:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E561D6B0072; Wed, 21 Jul 2021 09:15:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0216.hostedemail.com [216.40.44.216]) by kanga.kvack.org (Postfix) with ESMTP id BF2B46B0071 for ; Wed, 21 Jul 2021 09:15:30 -0400 (EDT) Received: from forelay.prod.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by fograve02.hostedemail.com (Postfix) with ESMTP id 5F60D22864 for ; Wed, 21 Jul 2021 11:58:06 +0000 (UTC) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 011D8230F5 for ; Wed, 21 Jul 2021 11:58:05 +0000 (UTC) X-FDA: 78386446572.05.C8BF6D6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 663B85019F97 for ; Wed, 21 Jul 2021 11:58:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Ph2AqZJik3maCj0zHoR0Eaz0ZYCauJ76GTQnPNy9/eQ=; b=frAKPN16ZvMVcpmkjtL9GjxVqW nKSa0L0D5hVmwIYoWEuPoE7G3sHa380XEftApyfQ+RVw4aHncPYk0WOwnawZf96LqzDqLExJgKF1t EF17rkVoZqKy3reeJLB7qusYZeGvWwRStxXw1h32I9YJ52orcvQgO3WqvVrRjz1uODBjxP7Z6iE/W ASEAUDaeKqtKieKljk/BTQoEuNzlNjdLB84h79p9gjCgvR+3sqGXq397xoQOH33DRbxSWgQQUea/v udXA8wwFYbDP1NNRBcVQUrQNewiNSWn3VEUoIvlBHDP6AImTkn75DflRjbf5c8q+gjG4A0Mkg5bbC o/U/V0og==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m6Aqu-0099ng-2x; Wed, 21 Jul 2021 11:57:31 +0000 Date: Wed, 21 Jul 2021 12:57:28 +0100 From: Matthew Wilcox To: Mike Kravetz Cc: Andrew Morton , bugs+kernel.org@dtnr.ch, David Howells , Al Viro , bugzilla-daemon@bugzilla.kernel.org, linux-mm@kvack.org Subject: Re: [Bug 213785] New: hugetlbfs scrambles mode when sticky bit is set Message-ID: References: <20210720150704.59f78224be810a0cf9dd5f39@linux-foundation.org> <4a02aa78-c600-f2f4-c7d3-d79164c2c8a1@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4a02aa78-c600-f2f4-c7d3-d79164c2c8a1@oracle.com> Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=frAKPN16; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam05 X-Stat-Signature: zec68iuj7dykujutdyh397kyd1nwsxk7 X-Rspamd-Queue-Id: 663B85019F97 X-HE-Tag: 1626868684-480079 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jul 20, 2021 at 09:38:48PM -0700, Mike Kravetz wrote: > Add David, Al > > On 7/20/21 3:07 PM, Andrew Morton wrote: > >> https://bugzilla.kernel.org/show_bug.cgi?id=213785 > >> > >> Summary: hugetlbfs scrambles mode when sticky bit is set > >> Product: Memory Management > >> Version: 2.5 > >> Kernel Version: >4.19 (certainly >= 5.4) > >> Regression: Yes > >> > >> I noticed the following strange behaviour with hugetlbfs mounts for kernel > >> versions something north of 4.19, but certainly since 5.4: > >> > >> when the mode= option of the mount has the sticky bit set, the mode of the > >> mount point gets scrambled. > >> > >> To test the following command line can be used: > >> mkdir -p /tmp/tlbtest && mount -t hugetlbfs -o mode=.... none /tmp/tlbtest && > >> stat -c 'mode: %04a' /tmp/tlbtest > >> > >> For kernel versions <= 4.19 or if the first byte of mode is 0, stat outputs > >> what was set using "-o mode". > >> > >> But on newer kernel versions if the first byte of mode is 1 the output of stat > >> is as follows (input -> output): > >> 1700 -> 1244 > >> 1750 -> 1326 > >> 1770 -> 1352 > >> 1775 -> 1357 > >> 1777 -> 1361 > >> > >> The behaviour is reproducible across different kernel versions and > >> architectures (5.4.47-amd64, 5.9.8-amd64, 5.10.40-ppc64el, 5.12.15-amd64). > > I took a quick look and believe a change in behavior was caused by > commit 32021982a324 "Convert the hugetlbfs to use the fs_context > during mount". > > Prior to the commit, code processing the mode option used > match_octal() to convert the command line string to a numeric value. > Since match_octal expects a string representing an octal value, it does > not require a leading '0'. As a result, prior to this commit the > argument 'mode=1700' would result in a mode value of 01700. After the > commit one must precede octal values with 0. So, mode=1700 would result > in a mode value of 03244 (& 01777U) = 1244. > > If my analysis is correct, I am not sure how to proceed. IMO, the > current behavior is 'more correct'. However, until v5.1 a preceeding 0 > was not required when specifying mode for hugetlbfs. So, this was > certainly a change in behavior. Suggestions? Probably should follow what shmem does: mm/shmem.c: fsparam_u32oct("mode", Opt_mode), (also several other filesystems)