Date: Fri, 26 Aug 2011 17:39:40 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: current@freebsd.org Subject: kqueue and device driver experience anyone ? Message-ID: <20110826153940.GA3800@onelab2.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
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 ? cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110826153940.GA3800>