makedev(9): drop an additional note about cdevpriv dtors

These were previously somewhat safe to call destroy_dev(9), but will now
also cause a deadlock in the same fashion that d_close doing so would
previously.  Amend the note to point it out, in case it's useful for
someone.

Reviewed by:	imp, kib, markj
Differential Revision:	https://reviews.freebsd.org/D53439
This commit is contained in:
Kyle Evans
2025-11-04 18:28:02 -06:00
parent 96c1d8db39
commit 90314c04f1
+8 -4
View File
@@ -25,7 +25,7 @@
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE. .\" SUCH DAMAGE.
.\" .\"
.Dd January 19, 2025 .Dd November 4, 2025
.Dt MAKE_DEV 9 .Dt MAKE_DEV 9
.Os .Os
.Sh NAME .Sh NAME
@@ -387,14 +387,18 @@ function is the same as:
destroy_dev_sched_cb(cdev, NULL, NULL); destroy_dev_sched_cb(cdev, NULL, NULL);
.Ed .Ed
.Pp .Pp
The Neither the
.Fn d_close .Fn d_close
driver method cannot call driver method, nor a
.Xr devfs_cdevpriv 9
.Fa dtr
method can
.Fn destroy_dev .Fn destroy_dev
directly. directly.
Doing so causes deadlock when Doing so causes deadlock when
.Fn destroy_dev .Fn destroy_dev
waits for all threads to leave the driver methods. waits for all threads to leave the driver methods and finish executing any
per-open destructors.
Also, because Also, because
.Fn destroy_dev .Fn destroy_dev
sleeps, no non-sleepable locks may be held over the call. sleeps, no non-sleepable locks may be held over the call.