Date: Thu, 18 Jan 2001 23:27:12 -0500 From: "Bosko Milekic" <bmilekic@technokratis.com> To: <freebsd-current@freebsd.org> Subject: Small HEADS-UP Message-ID: <010401c081d0$183b8b30$1f90c918@jehovah>
next in thread | raw e-mail | index | archive | help
Hello,
A few hours ago, this has been committed to -CURRENT:
Commit log:
[...]
> Log:
> Implement MTX_RECURSE flag for mtx_init().
> All calls to mtx_init() for mutexes that recurse must now include
> the MTX_RECURSE bit in the flag argument variable. This change is in
> preparation for an upcoming (further) mutex API cleanup.
> The witness code will call panic() if a lock is found to recurse but
> the MTX_RECURSE bit was not set during the lock's initialization.
>
> The old MTX_RECURSE "state" bit (in mtx_lock) has been renamed to
> MTX_RECURSED, which is more appropriate given its meaning.
>
> The following locks have been made "recursive," thus far:
> eventhandler, Giant, callout, sched_lock, possibly some others declared
> in the architecture-specific code, all of the network card driver locks
> in pci/, as well as some other locks in dev/ stuff that I've found to
> be recursive.
[...]
This is a small HEADS-UP to let people who have WITNESS turned on that if
they stumble into a panic() with a message such as:
"[...] recursed on non-recursive mutex foo [...]"
to take note of it and report it as soon as possible to the lists (feel free
to CC me). I believe that I have covered the large majority of recursive
mutexes in the patch, but it's difficult to go through all the surrounding
code. So, if I happened to have missed some, it would be good to modify the
required mtx_init()s immediately, before further cleanups are done.
Thanks,
Bosko.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?010401c081d0$183b8b30$1f90c918>