From nobody Tue Apr 22 00:55:43 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZhP1N2TZSz5tHs5 for ; Tue, 22 Apr 2025 00:55:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZhP1M0Svxz3WX7; Tue, 22 Apr 2025 00:55:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 53M0thpi033917; Tue, 22 Apr 2025 03:55:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 53M0thpi033917 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 53M0thsw033916; Tue, 22 Apr 2025 03:55:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 22 Apr 2025 03:55:43 +0300 From: Konstantin Belousov To: Rick Macklem Cc: FreeBSD CURRENT , Konstantin Belousov Subject: Re: LK_RETRY set in cn_lkflags for VOP_LOOKUP? Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [2.13 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_SHORT(-0.87)[-0.874]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_SOFTFAIL(0.00)[~all]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; HAS_XAW(0.00)[] X-Rspamd-Queue-Id: 4ZhP1M0Svxz3WX7 X-Spamd-Bar: ++ On Mon, Apr 21, 2025 at 03:37:55PM -0700, Rick Macklem wrote: > Hi, > > I just spotted something in the NFS server that seems like > it is a bug, but I thought I'd check. > (Note that I have never seen this cause a problem, but I > think it might if a server file system is being forced > dismounted while the NFS server is accessing it.) > > What I spotted was a few places where: > cnp->cn_lkflags = LK_SHARED | LK_RETRY; > ... > error = VOP_LOOKUP(..); > I don't think LK_RETRY should be set here. > For example vget_finish() uses the flags argument > for a "error = vn_lock(..flags);", which would retry > instead of returning an error when the vnode is VI_DOOMED. > > So, is this a bug that needs to be fixed? I think LK_RETRY is not appropriate there, and ought to be removed. But it should not be critical by itself. The doomed vnode might cause some further VOP calls to fail, and NFS server must be prepared to that, correctly handling the error. I looked at the output of grep 'cn_lkflags.*LK_RETRY', and it seems that the error handling is proper, although the readdirplus code is somewhat too much to make the claim. As a curiousity, there is one more place with this pattern in zfs.