g_event and sysctllock

[Mark Johnston]

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?