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