LOR with sysctl lock
kabaev at gmail.com
Thu Nov 25 00:16:28 UTC 2010
On Wed, 24 Nov 2010 11:53:58 -0800
mdf at FreeBSD.org wrote:
> The sysctl lock can cause "random" LOR warnings. These usually show
> on reboot/shutdown when sysctl_ctx_free() is called by a kernel
> module, since the mod handler is called with the module lock. The
> reason for the LOR is that, at least theoretically, the sysctl lock is
> the first lock in any hierarchy, because a SYSCTL_PROC handler can
> take any locks it wants, and will be called with the sysctl lock held
> The below patch will fix the problem generically and with no changes
> to other code. I slightly prefer this to an explicit
> sysctl_ctx_free_sched(9), because many times code doesn't know if some
> caller holds *any* lock at all; this is especially true for mod
> handlers who shouldn't be expected to know how FreeBSD locks calls to
> the handler.
> I also note that the return value from sysctl_ctx_free(9) is almost
> never checked on CURRENT, and the only places it is, the value is
> merely used to print a warning. The only exception is canbus_detach()
> in pc98/pc98/canbus.c. So I wonder if sysctl_ctx_free(9) should
> return void and print a warning itself.
> If there are no objections, I'd like to commit this next week.
Correct me if I am wrong, but doesn't this open a race where, say,
device detach routine destroys the device softc and schedules sysctl
context to be destroyed asynchronously via task queue? Since sysctl
entries are still visible in between the point where softc is destroyed
and the point where task queue picks the sysctl destroy task up, can any
access to said sysctls potentially operate on now freed softc data?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 188 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101125/3468015b/signature.pgp
More information about the freebsd-arch