Repository navigation
libkernel_sys: fpathconf on a kqueue or shm descriptor returns the UFS constants instead of EOPNOTSUPP #11291
Description
fpathconf on a descriptor with no vnode only special-cases FIFOs and sockets, so a kqueue and a shm_open(SHM_ANON, ...) descriptor still get the UFS constants. I haven't run this myself; the numbers are from wachi35676's runs on Windows and WSL2 in #10427 (comment).
In those runs _PC_LINK_MAX / _PC_NAME_MAX / _PC_PIPE_BUF return 32767 / 255 / 512 for both descriptor kinds. FreeBSD 11.4 returns -1 with EOPNOTSUPP (kern_fpathconf, kern_descrip.c:1411-1429): after _PC_ASYNC_IO, which is answered for every descriptor and is 200112 on both sides, only descriptors with a vnode, pipes and sockets are answered.
The code is _fpathconf_nid_postfix in core/libs/prx/libkernel_sys/Export.cpp. This isn't caused by #10427; that PR just made the gap visible. A guest test next to the existing socket cases would cover it.
Activity
MarcZX10 commentedon Oct 26, 2026
I checked current
mainand the openfpathconfwork._fpathconf_nid_postfixcurrently treats FIFOs and sockets specially; PR #10427 adds Windows socket recognition but does not cover kqueue or shared-memory descriptors, so this issue remains a distinct gap. FreeBSD 11.4kern_fpathconfconfirms the stated split: vnode-backed descriptors useVOP_PATHCONF, pipes/sockets getPIPE_BUFonly for_PC_PIPE_BUF, and other descriptors without a vnode returnEOPNOTSUPP(source: https://github.com/freebsd/freebsd-src/blob/8c639945a44588f6cfdddfb057bb5aad88735da0/sys/kern/kern_descrip.c). The Windows/WSL observations are useful host evidence; as the issue says, they do not establish console-measured behavior.MarcZX10 commentedon Oct 26, 2026
Open PR #11296 adds the
fpathconfspecial case and its focused descriptor tests, but the latest Windows run in that PR reports theSHM_ANONcase still returning UFS values (3/3 failures). The Windows anonymous shared-memory object is backed by a temporary file and is not in the descriptor registry that the new branch checks. The PR remains changes requested for coverage of that case; this issue is not resolved yet.MarcZX10 commentedon Oct 26, 2026
Status update on #11296: its latest head
52c8d6749a3dadd8268ec6ade827c3634896ab76changed the regression fromSHM_ANONto a named shared-memory object. That gives cross-platform coverage for the named descriptor case, which the author reports is recognized on Windows and returnsEOPNOTSUPP. The original issue specifically reportsshm_open(SHM_ANON, ...); the author confirms Windows still backs that object with an unregistered temporary file, so the new shared-memory predicate remains false and the reported Windows descriptor still gets the UFS values. I asked on #11296 to either cover Windows anonymous-descriptor recognition and test both platforms, or narrow the PR claim and keep thisSHM_ANONcase explicitly unresolved. The PR also needs a current-main refresh and exact-head Linux/Windows rerun; no closure is implied.