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>