From nobody Sun Mar 24 03:04:42 2024 X-Original-To: dev-commits-src-branches@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 4V2LWv29Myz5Dmxt; Sun, 24 Mar 2024 03:04:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V2LWt721nz4tN1; Sun, 24 Mar 2024 03:04:42 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711249483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=J7gF6a0lPs3v1J4uAlJWQ7dytUBjiNj7DvWGMEJL1Xo=; b=Vs+Xo0R3NufQCOagjLB73CDz/yjN+6d/JGQ5hqQpC11cooABypfC0r60EvQmYLkDybhxgB ZDTgFG0fzqD8sPvAZyICnxgXAGB1Cv2UX1fS+YM0rik4tQJmaoA1TJRHhrN/czGkSsiQ2d RLDMfcyYIvIt/maS3zPq9Cc9RmM7YA9c9MKxNT1NsrPD2xuSfq7RnH6To3esn5l3p3i+xd 5DaOMNSGwQhHy9xdwrazJ+fmUdc3O5TOX11LAp1tZ+15cms9Af5zy4s1w9EUiEwWMnE8V+ NIpdd0+RfomwcoOs6QK52FibIu6rz2PH14ylyOLj4zU0ysWGK1UdwW4jwlhuZA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711249483; a=rsa-sha256; cv=none; b=gSqAuW4dZbgbQN4xmCq8l7ztIKbPmTtnGuguLVnpdv8DsUC0qv8HNtswiby9K6GmENuw/N QT8TqV1myTvbiYI9EMLZR3UrlB5BT8yQD82KdLwksM0LdV5lHkmxsaqPdH3VQHMjZC8BDu zq+q8xe01q0SfYwWVuFmG/gB8/ZSdSmoEgMGAxhEK5xwmlr80cGr3jxVN26q5miUmh9gyY nEXm4JvGBJLdfMkBzENdyRPzkGNYmCouZOR0ZzRuRQsY+l6ZRVPV/NeGV7BEyYakvqZHVv 9bs+pcMgTQ3IWrYs2wqBUpRezZy7AjO4EfOwpi0hZ1W2ShdYVKU5YJS7tH9HaQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711249483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=J7gF6a0lPs3v1J4uAlJWQ7dytUBjiNj7DvWGMEJL1Xo=; b=jkiEeh6UWhUdUL+WP0o7dTn/CaIObGazloaoOzbNEkLREhSuNzZPOJBNdOui9OymUyS7kG 4IlkpwzU3f4Hv/WnlM2Ow2onhYNpPhQmA8GwKjpk3cjZxiRbBOCG1SLbL/a+5vEqyAb5m/ USfV6yhO0zqOryL9ob6TvVuWKUpEowfgzb2qkXSejquLTKdRpxjMmXQ8wRzEz9Nonk4EvV hs4TeynISsCIVjXjS2X5ioIVnjPGMMkO6MLbIi4bC6WBRizZVaOSCbtgIiIV0Rjk7f5sL0 gMj0OFLjzVnReMFah1DkvO7r9NNXn0OVdy/GMR7CyZltyqfa8sEXbPEDZbTi9A== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V2LWt6dWzzG3p; Sun, 24 Mar 2024 03:04:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.17.1/8.17.1) with ESMTP id 42O34gHC038604; Sun, 24 Mar 2024 03:04:42 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.17.1/8.17.1/Submit) id 42O34ge2038601; Sun, 24 Mar 2024 03:04:42 GMT (envelope-from git) Date: Sun, 24 Mar 2024 03:04:42 GMT Message-Id: <202403240304.42O34ge2038601@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org From: "Jason A. Harmening" Subject: git: 61d9b0cb38bb - stable/14 - uipc_bindat(): Explicitly specify exclusive locking for the new vnode List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-branches@freebsd.org X-BeenThere: dev-commits-src-branches@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: jah X-Git-Repository: src X-Git-Refname: refs/heads/stable/14 X-Git-Reftype: branch X-Git-Commit: 61d9b0cb38bb0b057929997c7eab689105bfdeb6 Auto-Submitted: auto-generated The branch stable/14 has been updated by jah: URL: https://cgit.FreeBSD.org/src/commit/?id=61d9b0cb38bb0b057929997c7eab689105bfdeb6 commit 61d9b0cb38bb0b057929997c7eab689105bfdeb6 Author: Jason A. Harmening AuthorDate: 2024-02-03 17:07:16 +0000 Commit: Jason A. Harmening CommitDate: 2024-03-24 02:55:38 +0000 uipc_bindat(): Explicitly specify exclusive locking for the new vnode When calling VOP_CREATE(), uipc_bindat() reuses the componentname object from the preceding lookup operation, which is likely to specify LK_SHARED. Furthermore, the VOP_CREATE() interface technically only requires the newly-created vnode to be returned with a shared lock. However, the socket layer requires the new vnode to be locked exclusive and asserts to that effect. In most cases, this is not a practical concern because most if not all base-layer filesystems (certainly FFS, ZFS, and msdosfs at least) always return the vnode locked exclusive regardless of the lock flags. However, it is an issue for unionfs which uses cn_lkflags to determine how the new unionfs wrapper vnode should be locked. While it would be easy enough to work around this issue within unionfs itself, it seems better for the socket layer to be explicit about its locking requirements when issuing VOP_CREATE(). Reviewed by: kib, olce Differential Revision: https://reviews.freebsd.org/D44047 (cherry picked from commit d56c175ac9353bd701a488bb2606a3372623dcc5) --- sys/kern/uipc_usrreq.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c index 5d39e5ea91c1..e54cd01956bf 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -622,8 +622,19 @@ restart: error = mac_vnode_check_create(td->td_ucred, nd.ni_dvp, &nd.ni_cnd, &vattr); #endif - if (error == 0) + if (error == 0) { + /* + * The prior lookup may have left LK_SHARED in cn_lkflags, + * and VOP_CREATE technically only requires the new vnode to + * be locked shared. Most filesystems will return the new vnode + * locked exclusive regardless, but we should explicitly + * specify that here since we require it and assert to that + * effect below. + */ + nd.ni_cnd.cn_lkflags = (nd.ni_cnd.cn_lkflags & ~LK_SHARED) | + LK_EXCLUSIVE; error = VOP_CREATE(nd.ni_dvp, &nd.ni_vp, &nd.ni_cnd, &vattr); + } NDFREE_PNBUF(&nd); if (error) { VOP_VPUT_PAIR(nd.ni_dvp, NULL, true);