Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1062201pxb; Thu, 19 Aug 2021 19:15:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+ACB7NWOI5BiHNs0Afgs1UnAYnKAqGPjd8mvqrfEqYqncxJBfYGQzhwMIXyBPk9bzX4D5 X-Received: by 2002:a6b:f40a:: with SMTP id i10mr14087357iog.139.1629425701028; Thu, 19 Aug 2021 19:15:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629425701; cv=none; d=google.com; s=arc-20160816; b=kGQbWeRWodppd6wrzmgGUL21Ldn2XDi+8oehS30HkY6Lxgb//sl4QWteIXhp8fKsup dwxM9sR1RaDUV86Mw8hhK9/YfR5pQeARUoJZX2lCWU0xF5G8QBIVmlZ1l21tVB1OS4je xUYmJqJz86GEsenG6XkKsiCoTwuqWsk6OsDWXoRqAnljCf+hrjgRsRCECNqq53WGjPWb UkXbLv4gwVDZWVoukUgJyGd0U71loe7YW7jsEDEQHk7ax2cz9OWlVRWzx4wunlM5/zyn LoTQJAJ+jJaGkdZfEWQDz/LeIeUG1UftK4sUe4NjuViRhCWENkYhRndOHopWLJiGJy84 jylw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=XSjREASVEvDR589eO6Ijn0bZU+wzCen1b/RgVCWKb2s=; b=kL+y+xvDYyOp6XvzV63x/F+oq5CTgBJawJlDca6S2A254lmMVGTG2efOoEaq56PNFx RQna1gZrTzsqlBDHClApu7cL9+3gRyALRB/zzImzLyXh0pqjKPmkausCM5FUqNPCgagQ q8iLu+MAZnWm5tS6iUVtab4czs3yGrHgGbKZrCIee1rGrKz5BCIIeLuZ7oAlU8EcUKwZ QYd7VxAT3z7qoZJxksufb6F4sv3fdGqOmgqFCX9WYv8My4pNKpR1uxS/EdSZRFv2XpNe zbxeGZvsoIZAU7hM+I5Rn7WphJyk4vTR2CjZnm/SnTm/5grc/u6V0D4GmHUDTBvpL5ve W2qQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="H4jwt/iw"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k14si4808405ilo.4.2021.08.19.19.14.48; Thu, 19 Aug 2021 19:15:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="H4jwt/iw"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237350AbhHTCOq (ORCPT + 99 others); Thu, 19 Aug 2021 22:14:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234768AbhHTCOo (ORCPT ); Thu, 19 Aug 2021 22:14:44 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2F99C061575; Thu, 19 Aug 2021 19:14:06 -0700 (PDT) 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=XSjREASVEvDR589eO6Ijn0bZU+wzCen1b/RgVCWKb2s=; b=H4jwt/iwZH+J07Ms0xFu4grwYh 6omomnqIBNoFTTCWp0YdBtyQp6jA2olzsf31U0XPG+HjMeaBZRs6AKaozY0P7j9wsPCCKMHV+vcER 8z9egjZURpkPkQH/OQxf1R97pwRN+turgoLRoTu0EcSh+eFkmshp0nG2kC+CinoDpwFLYTez5MVIE dnAwHIZ49meqESwtfsgqjqkWTTWhSQ0k+MoZ9+W5hfZduTGkhy+4t9GN3vIkMiqrAqjoUGsRUvudq AKOjDs5LHGbOnIPKy8zq1pyp9gmQPn4If4jfhDdgb3xEpRCGi3fZQsC8utNkSpZz5H8cEI5OeYP4Z pYYnbQdQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGtys-005stK-2d; Fri, 20 Aug 2021 02:10:21 +0000 Date: Fri, 20 Aug 2021 03:10:02 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: Jeff Layton , "Eric W. Biederman" , 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 Subject: Re: Removing Mandatory Locks Message-ID: References: <5b0d7c1e73ca43ef9ce6665fec6c4d7e@AcuMS.aculab.com> <87h7ft2j68.fsf@disp2133> <87k0kkxbjn.fsf_-_@disp2133> <0c2af732e4e9f74c9d20b09fc4b6cbae40351085.camel@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 19, 2021 at 01:31:35PM -0700, Linus Torvalds wrote: > 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. When I ripped out the NFS "intr" mount option fourteen years ago, I just turned it into a noop (commit 150030b78a45). It has greatly amused me every article I've read that's been written since then that recommends using it. Just shows how much tribal knowledge we have. I think this is a little different, though; I was essetially making the *wanted* behaviour of 'intr' the default (and disabling the unwanted behaviour). With 'mand', we're losing the behaviour entirely, and it's plausible that someone might care. Maybe something more like the old sys_bdflush implementation? if (msg_count < 5) { msg_count++; printk(KERN_INFO "warning: process `%s' used the obsolete bdflush" " system call\n", current->comm); printk(KERN_INFO "Fix your initscripts?\n"); }