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=-11.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=ham 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 B6107C4320A for ; Fri, 20 Aug 2021 13:57:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 629DA6113D for ; Fri, 20 Aug 2021 13:57:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 629DA6113D 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 C73886B0072; Fri, 20 Aug 2021 09:57:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C244D6B0071; Fri, 20 Aug 2021 09:57:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEAAA8D0001; Fri, 20 Aug 2021 09:57:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id 907716B0071 for ; Fri, 20 Aug 2021 09:57:13 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 27FC118479F29 for ; Fri, 20 Aug 2021 13:57:13 +0000 (UTC) X-FDA: 78495610746.34.6B870D4 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP id CAD8130000A0 for ; Fri, 20 Aug 2021 13:57:12 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C8368610E6; Fri, 20 Aug 2021 13:57:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1629467830; bh=8MnTVdYClbddCsTsLNbTMsCRF2Gxk95s2pj8wLFwQd0=; h=From:To:Cc:Subject:Date:From; b=t2HxBUM9QOrlPdcAaWYWdwKfXD7QFuBmZx3OUE5KT2Y1RrRgrlG401SCGys5CG8Fc +lcVOwSK0F1uRH0K8QJLDIwYW3EmP2b4Ceco7wMOADwIq3h+lqnTB1niclYqvdm+d7 2enkha2NLg5vfDHEe2r8OXXRW79B3laihEfbtfBlVEsjUkdLaKnZVY3+uH2dh+qDQt utX2JoYLcmwYrQrNOrxt/rOswI8UjaFYpiDcbSrgc9rnqPDeyRgQkinXLuc7PBcbGt 6iedGwdHK4/mUMLaWC3veuKd1igYYNJE82n3G60q/Ne/nfjplocJEfqwkX2HW7hZLL IPdEki8PItNtQ== From: Jeff Layton To: torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Cc: ebiederm@xmission.com, david@redhat.com, willy@infradead.org, linux-nfs@vger.kernel.org, viro@zeniv.linux.org.uk, linux-doc@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-afs@lists.infradead.org, cluster-devel@redhat.com, ocfs2-devel@oss.oracle.com, linux-mm@kvack.org, akpm@linux-foundation.org, luto@kernel.org, bfields@fieldses.org, w@1wt.eu, rostedt@goodmis.org Subject: [PATCH v2 0/2] fs: remove support for mandatory locking Date: Fri, 20 Aug 2021 09:57:05 -0400 Message-Id: <20210820135707.171001-1-jlayton@kernel.org> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t2HxBUM9; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf08.hostedemail.com: domain of jlayton@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=jlayton@kernel.org X-Stat-Signature: yrs56pbksfso4nsyrhswqjpxbyi6ezke X-Rspamd-Queue-Id: CAD8130000A0 X-Rspamd-Server: rspam05 X-HE-Tag: 1629467832-806749 Content-Transfer-Encoding: quoted-printable 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: The first patch in this series adds a new warning that should pop on kernels have mandatory locking enabled when someone mounts a filesystem with -o mand. The second patch removes support for mandatory locking altogether. What I think we probably want to do is apply the first to v5.14 before it ships and allow the new warning to trickle out into stable kernels. Then we can merge the second patch in v5.15 to go ahead and remove it. Sound like a plan? Jeff Layton (2): fs: warn about impending deprecation of mandatory locks fs: remove mandatory file locking support .../filesystems/mandatory-locking.rst | 188 ------------------ fs/9p/vfs_file.c | 12 -- fs/Kconfig | 10 - fs/afs/flock.c | 4 - fs/ceph/locks.c | 3 - fs/gfs2/file.c | 3 - fs/locks.c | 116 +---------- fs/namei.c | 4 +- fs/namespace.c | 31 +-- fs/nfs/file.c | 4 - fs/nfsd/nfs4state.c | 13 -- fs/nfsd/vfs.c | 15 -- fs/ocfs2/locks.c | 4 - fs/open.c | 8 +- fs/read_write.c | 7 - fs/remap_range.c | 10 - include/linux/fs.h | 84 -------- mm/mmap.c | 6 - mm/nommu.c | 3 - 19 files changed, 20 insertions(+), 505 deletions(-) delete mode 100644 Documentation/filesystems/mandatory-locking.rst --=20 2.31.1