From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05F9123B612 for ; Wed, 25 Mar 2026 13:28:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774445310; cv=none; b=nQ2hZwpgEK+tryn1vHsD5p+dgAsQMZBcpATb40WcB+0KEpGzA3RmCs6vEbw5v1xmjDh0xxvk7hswG8qotGuj3Dy6OZU3Pum2r4OdjtzL2tnuD95Rv3bBi/cX4O07lrV+IdlnorSAjdezuxH92/k87kK1ZuzX4HAjJON0Ff99+5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774445310; c=relaxed/simple; bh=VrtayuYLKmIwdMELbRfNa0BOEz+16aqgLPxRX1NOKPE=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=S2AemWMv6lP7dhP7466Z4ufr2jI5UOFYZsusIGUZb+fWicVQ1Hc09fZ1PzOFRpXUA5/Y/LM4qpDzCiSUfHg0Ffa9ClJNZhGi3JpUconH5gDNUtD8HfjLZmbac4mydlmf60b95Lp80yReZ04rAIW6lSPbP1TXM9D1yRLU/y9bKnk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ufpw2dmd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ufpw2dmd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 733D1C4CEF7; Wed, 25 Mar 2026 13:28:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774445309; bh=VrtayuYLKmIwdMELbRfNa0BOEz+16aqgLPxRX1NOKPE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Ufpw2dmd6/oA4c0ZAHC6bxe982nbyCkMRRmaYIDHiYe3iM/dbxnTP+6cYA3/IlQjC KF6VRYAq4jSZvVgPPuKK1jXNLPWkZSRIyRnWxAeOLn7nxSkpKTvfShyCqJlkwe+A44 fnxV8sh8/LeW38RSE1q1ccPSMwbvMS0IaNm8EK3nwqqrjMj/uGEs4KP+SKtyrnYw0M Lqyo3KPyxaEzqJ6o4lQySiQ9PPQsxAaE7HWV8oVh+H9ZiR+2u8I1N2aRQkUsRmDSka 8n6WHFfXyEp809GMPV99+pndJgphFxD0hT/uJ+YM4qHGdQ+mXLewhHNrZuaCqXyJet 23PRSY16BkIDg== Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfauth.phl.internal (Postfix) with ESMTP id 68894F40070; Wed, 25 Mar 2026 09:28:28 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-10.internal (MEProxy); Wed, 25 Mar 2026 09:28:28 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdefvdegheekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedfvehhuhgt khcunfgvvhgvrhdfuceotggvlheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrh hnpeejhfdutdetfeetvdevfeevtdelueelffdtleefledtteefteefgffhieefgeelieen ucffohhmrghinhepuggvsghirghnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheptghhuhgtkhhlvghvvghrodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdduieefgeelleelheelqdefvdelkeeggedvfedqtggvlh eppehkvghrnhgvlhdrohhrghesfhgrshhtmhgrihhlrdgtohhmpdhnsggprhgtphhtthho peekpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehnvghilhessghrohifnhdrnh grmhgvpdhrtghpthhtohepudduvdekkeeiudessghughhsrdguvggsihgrnhdrohhrghdp rhgtphhtthhopehjlhgrhihtohhnsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehrvg hgrhgvshhsihhonhhssehlvggvmhhhuhhishdrihhnfhhopdhrtghpthhtohepthhjrdhi rghmrdhtjhesphhrohhtohhnrdhmvgdprhgtphhtthhopehokhhorhhnihgvvhesrhgvug hhrghtrdgtohhmpdhrtghpthhtoheplhhinhhugidqnhhfshesvhhgvghrrdhkvghrnhgv lhdrohhrghdprhgtphhtthhopehsthgrsghlvgesvhhgvghrrdhkvghrnhgvlhdrohhrgh X-ME-Proxy: Feedback-ID: ifa6e4810:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 3C3FF780076; Wed, 25 Mar 2026 09:28:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: A_jyC0Lb0WUR Date: Wed, 25 Mar 2026 09:28:08 -0400 From: "Chuck Lever" To: NeilBrown Cc: "Jeff Layton" , "Thorsten Leemhuis" , 1128861@bugs.debian.org, Tj , linux-nfs@vger.kernel.org, "Olga Kornievskaia" , stable@vger.kernel.org Message-Id: In-Reply-To: <177442248735.2237155.773724155681455344@noble.neil.brown.name> References: <177266540127.7472.3460090956713656639@noble.neil.brown.name> <6ba41798-9c69-44f5-9a4e-09336c75a4b9@leemhuis.info> <177434721528.7102.13514118512738778346@noble.neil.brown.name> <177442248735.2237155.773724155681455344@noble.neil.brown.name> Subject: Re: [PATCH] lockd: fix TEST handling when not all permissions are available. Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Mar 25, 2026, at 3:08 AM, NeilBrown wrote: > On Wed, 25 Mar 2026, Chuck Lever wrote: >> >> On Tue, Mar 24, 2026, at 6:13 AM, NeilBrown wrote: >> > From: NeilBrown >> > >> > The F_GETLK fcntl can work with either read access or write access or >> > both. It can query F_RDLCK and F_WRLCK locks in either case. >> > >> > However lockd currently treats F_GETLK similar to F_SETLK in that read >> > access is required to query an F_RDLCK lock and write access is required >> > to query a F_WRLCK lock. >> > >> > This is wrong and can cause problem - e.g. when qemu accesses a >> > read-only (e.g. iso) filesystem image over NFS (though why it queries >> > if it can get a write lock - I don't know. But it does, and this works >> > with local filesystems). >> > >> > So we need TEST requests to be handled differently. To do this: >> > >> > - change nlm_do_fopen() to accept O_RDWR as a mode and in that case >> > succeed if either a O_RDONLY or O_WRONLY file can be opened. >> > - change nlm_lookup_file() to accept a mode argument from caller, >> > instead of deducing base on lock time, and pass that on to nlm_do_fopen() >> > - change nlm4svc_retrieve_args() and nlmsvc_retrieve_args() to detect >> > TEST requests and pass O_RDWR as a mode to nlm_lookup_file, passing >> > the same mode as before for other requests. Also set >> > lock->fl.c.flc_file to whichever file is available for TEST requests. >> > - change nlmsvc_testlock() to also not calculate the mode, but to use >> > whenever was stored in lock->fl.c.flc_file. >> > >> > Reported-by: Tj >> > Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861 >> > Fixes: 7f024fcd5c97 ("Keep read and write fds with each nlm_file") >> > Signed-off-by: NeilBrown >> >> Hi Neil, which kernels should this fix apply to? >> > > v6.13 and later. So linux-6.18.y and linux-6.19.y Assuming that includes upstream, I recommend that I take this into nfsd-testing / nfsd-next and let nature, ah, er, stable automation, take it's course. > The Fixes: tag is actually wrong. This bug has been present forever. > However a different bug that > Commit: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") > fixed was hiding the bug. > > So it should probably be marked > Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") > with an explanation. IIUC, we want Fixes: to point to the commit that introduced the issue (Fixes: since forever) and then use a "# v6.13+" comment on the Cc: stable to control how far back to backport it. Commit message could mention that 4cc9b9f2bf4d uncovered the issue. -- Chuck Lever