NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/60547: fileops(9) can't be safely unloaded in a module



>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 | Main Index | Thread Index | Old Index