From nobody Sun Mar 10 01:52:35 2024 X-Original-To: dev-commits-src-all@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 4Tsjb801dTz5CwQQ; Sun, 10 Mar 2024 01:52:36 +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 4Tsjb76GP3z4xSq; Sun, 10 Mar 2024 01:52:35 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710035555; 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=cDlVNeiKtiYf5F0j7eXrwVtxQ42fO7TDkP6rpNIO/TU=; b=yGIcpDaIapLpF1L1KDOgbDd7/d9kSZEgGLqp4dzM3xY0NKTD0FhYNS4FsKqfXuGUFxq1IN GTIC0hYtOgADRd1HZVR0B87s8Pbna2Y38BY5tHo0GToxLi3mgOBfl8oBLHdZESw6yED8ck BX4Zs85g/Lq7dHpRnYsYpDaphbbT+fdmmFWwHlIalfQEAtzRyYSKhj+EAlJsGEjq16DwKm lrnO4HAkH2rYpgPWuLHkKUmiKXRJ8y40xNkgArCdBuU0B8n9mAvRqi+YUrs08kEz3+OdwL /urF732JXYTR7ixynq3sm9x14+gvoHtKAw9he9nMG1Yq1U1Us7cU19w6BbMIiA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710035555; a=rsa-sha256; cv=none; b=xOtqrGE5RlSsm6ydgxNh7Cvt+iszobQNcpdicF7dVOmSYCoxGOa4t+7mdObw41W6Jfqv2f DyxHY+uNDKWnGWs+IG58gM9zqP3NKGauRtkbURLvDgw7zDlezV26WDOZ8GfLwHe/yf/pKY QE/Q4iEGEAmqcCoCt3cF6KjFkroZ9XKBQy1BqNBhMCvNGmRBil3HK8hv5OgpyGf9W7YElQ ZE/z1tBZIwnrUb36SJiU5tlGtLyZy1xyCqsA5O1kyROaWxVdXEVsLBhv+/HmdeM4ourscM BT7gX753rOSFf97bKDhVJx85lBkS+N6UYhubjrUkaXsabuk5vuGf1e5zA+WV5A== 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=1710035555; 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=cDlVNeiKtiYf5F0j7eXrwVtxQ42fO7TDkP6rpNIO/TU=; b=bM1dr1rfvuJ+JgoCWlYIDrO7D4/gmNhxjjJgg0korODSdKUDSYSzD0b4y5ZNgoUxHiGIXs y5DmSXQUFAwHcXNOHGAHkXAYDwM4zTopCYrGnlSM1i26BVgUK0kvEAWGOiAa/Httfrl1+w EQB5ES0+uVHw6nePEJu+KwI+WdSxfM7Q7kFXRzHR1uKBu2dT2212c6T4YCPf5VIwy2Tv01 gVCLn11gmi8f4b8kUH7GNq7CCCusk7GGCPctHBrzASyRl3XMWp51EenuuFCBRYP/8cKRu9 TZKybXu4x/Vtl6MW9rdmEbJl5A+8+WhGCtdrrHkP9+9IVarKCoZ3UFJu8O/DBw== 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 4Tsjb75sffzRR3; Sun, 10 Mar 2024 01:52:35 +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 42A1qZX5017335; Sun, 10 Mar 2024 01:52:35 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.17.1/8.17.1/Submit) id 42A1qZeX017332; Sun, 10 Mar 2024 01:52:35 GMT (envelope-from git) Date: Sun, 10 Mar 2024 01:52:35 GMT Message-Id: <202403100152.42A1qZeX017332@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: "Jason A. Harmening" Subject: git: d56c175ac935 - main - uipc_bindat(): Explicitly specify exclusive locking for the new vnode List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@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/main X-Git-Reftype: branch X-Git-Commit: d56c175ac9353bd701a488bb2606a3372623dcc5 Auto-Submitted: auto-generated The branch main has been updated by jah: URL: https://cgit.FreeBSD.org/src/commit/?id=d56c175ac9353bd701a488bb2606a3372623dcc5 commit d56c175ac9353bd701a488bb2606a3372623dcc5 Author: Jason A. Harmening AuthorDate: 2024-02-03 17:07:16 +0000 Commit: Jason A. Harmening CommitDate: 2024-03-10 01:48:02 +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 MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D44047 --- 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 20facd9b0a44..6e83e2be6f05 100644 --- a/sys/kern/uipc_usrreq.c +++ b/sys/kern/uipc_usrreq.c @@ -594,8 +594,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);