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 7AB5DC43214 for ; Thu, 19 Aug 2021 18:39:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29D1F610A6 for ; Thu, 19 Aug 2021 18:39:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 29D1F610A6 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 B94256B006C; Thu, 19 Aug 2021 14:39:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6B296B0071; Thu, 19 Aug 2021 14:39:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5A408D0001; Thu, 19 Aug 2021 14:39:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id 8BCC16B006C for ; Thu, 19 Aug 2021 14:39:44 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3637582F9B3C for ; Thu, 19 Aug 2021 18:39:44 +0000 (UTC) X-FDA: 78492693888.01.AC4339B Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id CECFFF00038C for ; Thu, 19 Aug 2021 18:39:43 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E89B6610A0; Thu, 19 Aug 2021 18:39:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629398382; bh=jHO3uuuSNNb+D5SxjZMugPbA3W7D6YrNvZkgLiJJxD0=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=UgRYoPsod6sraSn+DDJ/LiWLR7N5pGbb/T5ZxmvN2JicMBNa6rXd3tiLzqVsW1kBt PdOEHZlwkMqB12V1XvoQq/h9hMg9cKo/sZ8Ym9GYeNBPyGq3wxF2D2UTVf87+DUCrL uIzMHxE/uUlOPPjAjjJvfOuH3+A7T1gelycJiVjD6SEfuFoe48UZE+4tL1YOQm7hyM iwcjrOTBwFAE+nDAHD2JxiA7dfTEecbeCJh4/s1FJjzZuAWDXI/JC1a0z1nH2yDuTW PXOYGqMfbNKogGp4RJjeNMAp17ZwzzflYuKIkTdBrn8HWNmDNTr5+nbJ4bI0aB5N8o SyAj+clyqyilg== Message-ID: <0c2af732e4e9f74c9d20b09fc4b6cbae40351085.camel@kernel.org> Subject: Re: Removing Mandatory Locks From: Jeff Layton To: "Eric W. Biederman" , Matthew Wilcox Cc: Andy Lutomirski , Linus Torvalds , 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 14:39:36 -0400 In-Reply-To: <87k0kkxbjn.fsf_-_@disp2133> 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> 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 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CECFFF00038C X-Stat-Signature: ypymd7ufy4gx4rd4rawtb6cwhqnts7fs Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UgRYoPso; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of jlayton@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=jlayton@kernel.org X-HE-Tag: 1629398383-208362 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, 2021-08-17 at 11:48 -0500, Eric W. Biederman wrote: > Matthew Wilcox writes: > > > On Fri, Aug 13, 2021 at 05:49:19PM -0700, Andy Lutomirski wrote: > > > [0] we have mandatory locks, too. Sigh. > > > > I'd love to remove that. Perhaps we could try persuading more of the > > distros to disable the CONFIG option first. > > Yes. The support is disabled in RHEL8. > > Does anyone know the appropriate people to talk to encourage other > distro's to encourage them to disable the CONFIG_MANDATORY_FILE_LOCKING? > > Either that or we can wait until the code bit-rots, but distro's > disabling and removing a feature on their own is the more responsible > path. > > Given how many hoops need to be jumped through to use mandatory file > locking once it is enabled, and the fact it has never worked in > containers makes me suspect there are no more users. > I'm all for ripping it out too. It's an insane interface anyway. I've not heard a single complaint about this being turned off in fedora/rhel or any other distro that has this disabled. Cheers, -- Jeff Layton