Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Aug 2011 23:01:01 +0200
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: kqueue and device driver experience anyone ?
Message-ID:  <20110826210101.GA5822@onelab2.iet.unipi.it>
In-Reply-To: <201108261313.03441.jhb@freebsd.org>
References:  <20110826153940.GA3800@onelab2.iet.unipi.it> <201108261313.03441.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 26, 2011 at 01:13:03PM -0400, John Baldwin wrote:
> 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()).

ok, got it -- i see that bpf calls knlist_init_mtx() at init time.
So i can try to do something similar in my case, though i need to
deal with multiqueue cards which might be a bit trickier.

The other thing i need (but i believe i know how to handle it)
is tell whether .f_event() is called by KNOTE() or by kqueue_scan(),
but i believe i can use the "hint" argument to tell the two.

I guess i should add some notes to kqueue(9) once i understand it
better.

thanks for the clarification
luigi

The o

> -- 
> John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110826210101.GA5822>