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=-6.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 62087C43214 for ; Thu, 19 Aug 2021 21:43:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 044E561029 for ; Thu, 19 Aug 2021 21:43:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 044E561029 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9B5766B006C; Thu, 19 Aug 2021 17:43:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9644B6B0071; Thu, 19 Aug 2021 17:43:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8056D6B0072; Thu, 19 Aug 2021 17:43:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 62E406B006C for ; Thu, 19 Aug 2021 17:43:19 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1AF6F1813F55B for ; Thu, 19 Aug 2021 21:43:19 +0000 (UTC) X-FDA: 78493156518.33.FAC0BDD Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf20.hostedemail.com (Postfix) with ESMTP id B59FBD0000A9 for ; Thu, 19 Aug 2021 21:43:18 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 0B86860EB5; Thu, 19 Aug 2021 21:43:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629409397; bh=Qis+W6zkQTZYe1xg6ZIKtAmEgvOKVtPfN5JHB97wMwQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=YTUn0yw6nUpw51PPvGczp49OOM+H1/c0m9xuwthLJuMkJqgdjYyHhxg8yOVhLoMhp VQ+kOA2nK3nhlvsSZkMrnAmapLGmZO5D9b5U+9pjr0wEXPLMr89NHRfDOeTICElwOR UDLw9ONtcKXd+UOZ+28FEdQmSXsWLjD6eQtInZHGtle5q5vbJScMkDjxRegKOnVTsA DzTXn6ZIpdre07HZcF0GF/Cg/1+MxL9XJ4erYKgPyBE7EJV0zvxUGYBus1fbx8iV+b 29BaTatgVsRYZK0KFkT7pKy3feYPjYRPQBD3IfHS/hePE0iNlBCAfro/UuzVtKP44L vA+TnCI/ui3iA== Message-ID: <639d90212662cf5cdf80c71bbfec95907c70114a.camel@kernel.org> Subject: Re: Removing Mandatory Locks From: Jeff Layton To: Linus Torvalds Cc: "Eric W. Biederman" , Matthew Wilcox , Andy Lutomirski , David Laight , David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Al Viro , Alexey Dobriyan , Steven Rostedt , "Peter Zijlstra (Intel)" , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Petr Mladek , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , Kees Cook , Greg Ungerer , Geert Uytterhoeven , Mike Rapoport , Vlastimil Babka , Vincenzo Frascino , Chinwen Chang , Michel Lespinasse , Catalin Marinas , Huang Ying , Jann Horn , Feng Tang , Kevin Brodsky , Michael Ellerman , Shawn Anastasio , Steven Price , Nicholas Piggin , Christian Brauner , Jens Axboe , Gabriel Krisman Bertazi , Peter Xu , Suren Baghdasaryan , Shakeel Butt , Marco Elver , Daniel Jordan , Nicolas Viennot , Thomas Cedeno , Collin Fijalkovich , Michal Hocko , Miklos Szeredi , Chengguang Xu , Christian =?ISO-8859-1?Q?K=F6nig?= , "linux-unionfs@vger.kernel.org" , Linux API , the arch/x86 maintainers , "" , Linux-MM , Florian Weimer , Michael Kerrisk Date: Thu, 19 Aug 2021 17:43:12 -0400 In-Reply-To: References: <20210812084348.6521-1-david@redhat.com> <87o8a2d0wf.fsf@disp2133> <60db2e61-6b00-44fa-b718-e4361fcc238c@www.fastmail.com> <87lf56bllc.fsf@disp2133> <87eeay8pqx.fsf@disp2133> <5b0d7c1e73ca43ef9ce6665fec6c4d7e@AcuMS.aculab.com> <87h7ft2j68.fsf@disp2133> <87k0kkxbjn.fsf_-_@disp2133> <0c2af732e4e9f74c9d20b09fc4b6cbae40351085.camel@kernel.org> Content-Type: text/plain; charset="ISO-8859-15" User-Agent: Evolution 3.40.3 (3.40.3-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YTUn0yw6; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of jlayton@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=jlayton@kernel.org X-Stat-Signature: jok43eoeto55f6nqbbnazy1ysase4b4e X-Rspamd-Queue-Id: B59FBD0000A9 X-Rspamd-Server: rspam01 X-HE-Tag: 1629409398-738982 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 Thu, 2021-08-19 at 13:31 -0700, Linus Torvalds wrote: > On Thu, Aug 19, 2021 at 1:18 PM Jeff Layton wrote: > > > > Now that I think about it a little more, I actually did get one > > complaint a few years ago: > > > > Someone had upgraded from an earlier distro that supported the -o mand > > mount option to a later one that had disabled it, and they had an (old) > > fstab entry that specified it. > > Hmm. We might be able to turn the "return -EINVAL" into just a warning. > > Yes, yes, currently if you turn off CONFIG_MANDATORY_FILE_LOCKING, we > already do that > > VFS: "mand" mount option not supported > > warning print, but then we fail the mount. > > If CONFIG_MANDATORY_FILE_LOCKING goes away entirely, it might make > sense to turn that warning into something bigger, but then let the > mount continue - since now that "mand" flag would be purely a legacy > thing. > > And yes, if we do that, we'd want the warning to be a big ugly thing, > just to make people very aware of it happening. Right now it's a > one-liner that is easy to miss, and the "oh, the mount failed" is the > thing that hopefully informs people about the fact that they need to > enable CONFIG_MANDATORY_FILE_LOCKING. > > The logic being that if you can no longer enable mandatory locking in > the kernel, the current hard failure seems overly aggressive (and > might cause boot failures and inability to fix/report things when it > possibly keeps you from using the system at all). > What sort of big, ugly warning did you have in mind? I'm fine with that general approach though and will plan to roll that change into the patch I'm testing. Thanks, -- Jeff Layton