NetBSD Problem Report #60547

From www@netbsd.org  Thu Aug  6 18:59:47 2026
Return-Path: <www@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 "YR2" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 007641A9252
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  6 Aug 2026 18:59:46 +0000 (UTC)
Message-Id: <20260806185945.C84391A9253@mollari.NetBSD.org>
Date: Thu,  6 Aug 2026 18:59:45 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: fileops(9) can't be safely unloaded in a module
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60547
>Category:       kern
>Synopsis:       fileops(9) can't be safely unloaded in a module
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 06 19:00:01 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
NetBSD Fileops Unloaded Ltd.
>Environment:
>Description:

	There is no mechanism by which a module which is about to be
	unloaded can block new use of struct fileops operations and
	wait for all pending ones to complete.

	This is necessary to make it safe to unmap the .data memory
	where the struct fileops object lives and the .text memory
	where the code implementing the operations lives.

	Drivers that provide bdevsw/cdevsw can use vdevgone to revoke
	all vnodes in order to block the bdev/cdev entry points, and
	devsw_detach will wait for them to all return.  But there is no
	corresponding mechanism for drivers with, e.g., cloning devices
	that provide fileops.

>How-To-Repeat:

	code inspection

>Fix:

	Yes, please!

	Need some pserialize/localcount around struct fileops access
	just like we added in subr_devsw.c for struct bdevsw/cdevsw
	access.

Home	PR Database Search