Page MenuHomeFreeBSD

uipc_bindat(): Explicitly specify exclusive locking for the new vnode
ClosedPublic

Authored by jah on Feb 23 2024, 5:55 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 4:10 PM
Unknown Object (File)
Thu, Nov 7, 1:43 PM
Unknown Object (File)
Sep 25 2024, 7:41 PM
Unknown Object (File)
Sep 25 2024, 9:17 AM
Unknown Object (File)
Sep 24 2024, 8:19 PM
Unknown Object (File)
Sep 24 2024, 7:36 PM
Unknown Object (File)
Sep 24 2024, 4:37 PM
Unknown Object (File)
Sep 18 2024, 4:26 PM
Subscribers

Details

Summary

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().

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jah requested review of this revision.Feb 23 2024, 5:55 PM

This is needed for upcoming work to adopt VOP_UNP_* in unionfs.

sys/kern/uipc_usrreq.c
606

Fine. I just would prefer to use ~LK_SHARED instead. IIRC, cn_lkflags is not supposed to contain anything else than LK_SHARED or LK_EXCLUSIVE (we should probably assert that at several other places).

This revision is now accepted and ready to land.Feb 24 2024, 12:02 AM