From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 20:45:59 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4469106566B; Fri, 26 Aug 2011 20:45:59 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 78BAE8FC08; Fri, 26 Aug 2011 20:45:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 662EA7302B; Fri, 26 Aug 2011 23:01:01 +0200 (CEST) Date: Fri, 26 Aug 2011 23:01:01 +0200 From: Luigi Rizzo To: John Baldwin Message-ID: <20110826210101.GA5822@onelab2.iet.unipi.it> References: <20110826153940.GA3800@onelab2.iet.unipi.it> <201108261313.03441.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201108261313.03441.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: kqueue and device driver experience anyone ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:45:59 -0000 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