On Wed, Apr 20, 2016 at 11:38:20AM -0700, Ravi Pokala wrote: > Hi folks, > > My colleague Sushanth (CCed) tried to send this to hackers@ yesterday, but it > didn't go through for some reason. Resending on his behalf, adding geom@, and > noting that while we saw this on 7-STABLE, it looks like it could still be an > issue in -HEAD. > > -------------------------------- > > Hello, > > We have a home-grown geom driver that creates sysctl in the device creation > path. Device creation is handled by the geom event thread. The call to > SYSCTL_ADD_NODE() takes the sysctllock in exclusive mode. If the event thread > is racing with another thread that calls sysctl_disks(), then you end up with > a deadlock since sysctl_disks() tickles the event thread and goes to sleep > while holding the sysctllock. It is expected to woken up by the event thread > when the event of listing all the disks is processed. But the geom event is > blocked waiting for the sysctllock. > > I did see g_disk_create() adds a sysctl variable in a similar fashion, hence > the email. I'm thinking of fixing the sysctl_disks() to drop the sysctllock > before going to sleep and reacquiring it after being woken up. Let me know > your thoughts. >
This is not an issue in head. r216060 modified the sysctl code so that the sysctl lock is dropped before handlers are called. So sysctl_disks() is no longer executed with the sysctl lock held, and this addresses the problem you described. This change was MFCed to stable/7 in r220012 though. Do you have that revision? _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
