NetBSD Problem Report #59935

From dholland@netbsd.org  Thu Jan 22 04:47:37 2026
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A044B1A923D
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 22 Jan 2026 04:47:37 +0000 (UTC)
Message-Id: <20260122044737.3260D85614@mail.netbsd.org>
Date: Thu, 22 Jan 2026 04:47:37 +0000 (UTC)
From: dholland@NetBSD.org
Reply-To: dholland@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: vn_union_readdir_hook
X-Send-Pr-Version: 3.95
X-From4GNATS: "dholland@NetBSD.org via gnats" <gnats-admin@NetBSD.org>

>Number:         59935
>Category:       kern
>Synopsis:       vn_union_readdir_hook
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 22 04:50:00 +0000 2026
>Originator:     David A. Holland
>Release:        NetBSD 11.99.4 (20260101)
>Organization:
Astariel, the weeper
>Environment:
System: NetBSD valkyrie 11.99.4 NetBSD 11.99.4 (VALKYRIE2) #0: Thu Jan  1 22:38:54 EST 2026  dholland@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE2 amd64
Architecture: x86_64
Machine: amd64
>Description:

sys/vnode.h defines this:
   extern int (*vn_union_readdir_hook) (struct vnode **, struct file *, struct lwp *);

which is a global variable set by onionfs to get a custom extra call
from inside vn_readdir.

There is a long-standing mechanism for making calls into filesystems
from the VFS layer. Someone back in 4.4 apparently decided they were
too special to add a new VOP call for this -- they inlined a bunch of
onionfs logic directly into vfs_syscalls.c, which eventually became
this "hook".

(Also, the global is partially but not correctly integrated into the
extra nonfunctional copy of onionfs in sys/fs/unionfs. This doesn't
much matter in light of this copy being nonfunctional; but it's
additionally untidy.)

>How-To-Repeat:

Code reading.

>Fix:

Add a VOP_READDIR_NEXT or something call (name to be bikeshedded) to
fetch the next subcomponent vnode to call VOP_READDIR on. Or something
like that.

Note that the current "hook" code in onionfs calls vn_close on the
original vnode from inside the fs, which is definitely not cool; the
overall logic needs to be strengthened as well.

Given how readdir for onionfs works and interacts with libc, it should
be sufficient to just expose in turn each of the underlying vnodes.
However, it would be tidier to not add a new VOP at all but instead
add a component number argument to VOP_READDIR that the VFS code just
increments each time it sees an EOF from VOP_READDIR, until it gets
two EOFs in a row. Or something like that.

Home	PR Database Search