Re: kern/60688 (npf: wrong module/config dependency for bpf filter?)

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60688; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Thor Lancelot Simon <tls%panix.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, tls%netbsd.org@localhost,
	kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost
Subject: Re: kern/60688 (npf: wrong module/config dependency for bpf filter?)
Date: Tue, 8 Sep 2026 14:57:02 +0000

 > Date: Mon, 7 Sep 2026 12:06:42 -0400
 > From: Thor Lancelot Simon <tls%panix.com@localhost>
 >=20
 > Apologies - I had committed a mangled patch after test building in the wr=
 ong
 > tree (sigh).  This should be fully fixed by npf_os.c 1.25, bpf.c 1.258, a=
 nd
 > bpg_filter.c 1.74.
 
 Thanks, I'll take a look.
 
 > The symptom is that a kernel without MODULAR nor pseudo-device bpfilter,
 > but with pseudo-device npf, fails module initialization for built-in modu=
 le
 > npf:
 >=20
 > WARNING: module error: Built-in module 'npf' prerequisite 'bpf' failed, e=
 rror 2
 >=20
 > Subsequently, "npfctl reload" will yield a quick panic because the module=
  is
 > uninitialized - the usual uvm_fault from a NULL pointer dereference.
 
 That sounds like another bug with module loading.  If the module load
 fails, `npfctl reload' should fail gracefully, not crash.
 
 However, that's also consistent with bpf_ops being null.  Can you show
 the stack trace?
 
 > I don't think there is an issue with bpf_mtap2; it's a static inline from=
  the
 > bpf.h header file and is supplied by bpf_stub.c, not bpf.c.
 
 Yes but it works via the global pointer bpf_ops which might be null if
 something went wrong with module initialization, and the logic I see
 in bpf_stub.c looks awfully sketchy at quick glance:
 
 https://nxr.netbsd.org/xref/src/sys/net/bpf_stub.c?r=3D1.8