Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1429501pxb; Fri, 20 Aug 2021 05:33:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzpHujvwMjzUzkcgFHpOa6Pf/2aonj+INLH1k4oC6ZOmD/3+GE2oaxA89fiOymjjA4oPGcx X-Received: by 2002:a05:6402:21e4:: with SMTP id ce4mr16583840edb.377.1629462793845; Fri, 20 Aug 2021 05:33:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629462793; cv=none; d=google.com; s=arc-20160816; b=MlyL4gHaUN3VHYr+oLfTKT9tN5/PGxXO6bgWSj0E9MV7JDzq8Jdrr1bYXPjpo9me7t aPm4eozP1IfKBjIqya+Ur3Ca0lshaksI08AXtdnQGNDcyT5xvmxg7/+MK42q/RqDysg1 pCt0xABQeCMX+ooEyD4rGmtBymsOpZj322ZA8KkOnUZjd3jcc7XBuua0vbtxGlBcZZE9 yBOYi7gdlcryoKZ/gUbI/qSIFELtEjSbWx9D1q7EZurU6FSJRCJKbWSDxP/JinTEOozw hi6/55S+69zgOn1TlWKFs/LQt/fd1Y9Ud2XUC1FJJA7uFQTttMhLQkzXbT+nQpXPVZIc o7fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=ns17uDNU8VJvg6iaNrA1i8lz6A4rQYx6fkieYI3zWvc=; b=c2tGF30vUnZozpDG7ILP0FxaB8nTZSbtBZG/XoUT122SfS/4RB5QQAx1/DYls03F1x gLO+gihk/7IN8e3jsBWg8YRuIxJwJyVWHnnfxaCZZjltOkPbAgimbVvlAUzHMtTFXKXK FKWf4x3fXWBBebCwI2o7W7XWGJ2E7ZBaKJUXYS0jI+SzYD5hu5633++1I0+CfYwqacid 3VdJ1pjluAMoBmoOXUUgoTD1ivMk0Z9DR2VRhHgGEiwN9KDbBILVg3mx/HGEyJIwvYTF pPlAVGOOPKjLtt09bQnF/OL8K1ry0nTv/yE9cv5wEQGRw09sidOz1CWwCWPJalBfGE6Q MYjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=doMJtFh3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b17si6323446edv.518.2021.08.20.05.32.35; Fri, 20 Aug 2021 05:33:13 -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=@kernel.org header.s=k20201202 header.b=doMJtFh3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238510AbhHTM2D (ORCPT + 99 others); Fri, 20 Aug 2021 08:28:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:35284 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230519AbhHTM14 (ORCPT ); Fri, 20 Aug 2021 08:27:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7F5B0610C8; Fri, 20 Aug 2021 12:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629462438; bh=i9pNAmCqBQaLFsjbGkAGOalkIm9Q6ybcuj6sasTCrKc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=doMJtFh3hQD6xLRFFCKx5P3D2uhfPVhN0umskuYxkhPkZYsgPNvGjzuT8WVT5KhA/ ta29i07/fBw5MzkNi9mI0nLegnLeMo+6znQsKLFIHVvAoIWr1jJLXs5hS6abbRRggI qk/S+muiIOr9SSEPs7jdGfZuL8DEhyjV/cDbbP2v52bTnGxm6ydabe0mouAsdWSInN K8cgavcEZ/UIoJHqcr2Oo/cXEnwrlETtZ5Knm0tUT1YZUuke77QXXBnAXElOFmv5g6 JG4of6+YWwEx0Zwn80prchFWxfop5OixdyAyFYyiDGvd1HegL6lMMu7DZbrfncmFSI rc/2oFZR+ojEg== Message-ID: Subject: Re: Removing Mandatory Locks From: Jeff Layton To: Amir Goldstein , 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 , Willy Tarreau Date: Fri, 20 Aug 2021 08:27: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.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2021-08-20 at 10:14 +0300, Amir Goldstein wrote: > On Fri, Aug 20, 2021 at 9:36 AM Amir Goldstein wrote: > > > > On Thu, Aug 19, 2021 at 11:32 PM 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). > > > > > > > Allow me to play the devil's advocate here - if fstab has '-o mand' we have > > no way of knowing if any application is relying on '-o mand' and adding > > more !!!!! to the warning is mostly good for clearing our conscious ;-) > > > > Not saying we cannot resort to that and not saying there is an easy > > solution, but there is one more solution to consider - force rdonly mount. > > Yes, it could break some systems and possibly fail boot, but then again > > an ext4 fs can already become rdonly due to errors, so it wouldn't > > be the first time that sysadmins/users run into this behavior. > > > > Adding an anecdote - this week I got a report from field support > engineers about failure to assemble a RAID0 array, which led to this > warning that *requires* user intervention, in the worse case for boot > device it requires changing kernel boot params: > > md/raid0:%s: cannot assemble multi-zone RAID0 with default_layout setting > md/raid0: please set raid.default_layout to 1 or 2 > > c84a1372df92 md/raid0: avoid RAID0 data corruption due to layout confusion. > > There is no way I would have gotten this report from the field if a failure > was not involved... > > The rdonly mount is only needed to get the attention of support people > to look the the kernel logs and find the warning - at this point, not too > many !!!!! are needed ;-) > > So we could make 'mand' an alias to 'ro' and print a warning that says: > "'mand' mount option is deprecated, please fix your init scripts. > For caution, your filesystem was mounted rdonly, feel free to remount > rw and move on..." That is a possibility, but I'm not sure it's any better than just failing the mount. We could also just keep the code around and throw a big, scary warning about its impending removal for a few releases before ripping it out completely (like Willy T. was suggesting). I'm fine with any of these approaches if the consensus is that it's too risky to just remove it. OTOH, I've yet to ever hear of any application that uses this feature, even in a historical sense. You have to jump through so many hoops that nothing can rely on having it available. -- Jeff Layton