Re: kqueue and device driver experience anyone ?

On Friday, August 26, 2011 11:39:40 am Luigi Rizzo wrote:
> a question for the kqueue experts out there:
> 
> I am trying to add kqueue support to a device driver, and am puzzled
> on what the .f_event() function may assume.
> 
> I see that some of the examples (e.g. bpf, audit_pipe.c)
> expect that the function is called with the device lock held
> (and even have a LOCK_ASSERT).
> 
> Others (if_tap, cam/scsi/scsi_target.c) either do not use the lock
> or explicitly acquire it.
> 
> As far as i can tell the .f_event() function is called in two places:
> 
> - within knote() which in turn (through KNOTE_*() ) is called
>   by the driver itself near selrecord() . So it is up to the
>   device driver to call it with the device lock held;
> 
> - within kqueue_scan(), which instead is called from the upper half
>   of the kernel as part of kern_kevent(). Here there seems to be no
>   way that the device lock is acquired when .f_event() is called.
>   Unless, of course, the knote's on which these .f_event() are
>   called are not the same ones attached to devices -- so there is
>   a different .f_event() function called ?
> 
> So, is there a bug in the kqueue support for bpf.c and audit_pipe.c,
> or i am missing something important ?

Note that the top-half code may end up locking the device's mutex
if the mutex was tied to the knote list when the knote list was
created (e.g. knlist_init_mtx()).  In general if you want to use
locking to protect your knlist, you should tell the knlist about
the locking to use, then there are variants of KNOTE() that let it
know if the calling code already holds the appropriate lock or not
(KNOTE_LOCKED() and KNOTE_UNLOCKED()).

-- 
John Baldwin