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.8 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 2AB61C4320A for ; Tue, 17 Aug 2021 16:48:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0B1AC60FE6 for ; Tue, 17 Aug 2021 16:48:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230367AbhHQQtI (ORCPT ); Tue, 17 Aug 2021 12:49:08 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:57478 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229716AbhHQQtH (ORCPT ); Tue, 17 Aug 2021 12:49:07 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]:36550) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mG2GG-00B1AV-9W; Tue, 17 Aug 2021 10:48:24 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:53352 helo=email.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 1mG2GE-004s3F-8f; Tue, 17 Aug 2021 10:48:23 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: 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 =?utf-8?Q?K=C3=B6nig?= , "linux-unionfs\@vger.kernel.org" , Linux API , the arch/x86 maintainers , "\" , Linux-MM , Florian Weimer , Michael Kerrisk 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> Date: Tue, 17 Aug 2021 11:48:12 -0500 In-Reply-To: (Matthew Wilcox's message of "Sat, 14 Aug 2021 04:04:09 +0100") Message-ID: <87k0kkxbjn.fsf_-_@disp2133> 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=1mG2GE-004s3F-8f;;;mid=<87k0kkxbjn.fsf_-_@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/RgSCC94xL9aHXm5fqRL3zu5kuwNAWKt8= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Removing Mandatory Locks 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-unionfs@vger.kernel.org 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. Eric