From owner-freebsd-current@FreeBSD.ORG Fri Aug 26 17:13:05 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 897EC1065672 for ; Fri, 26 Aug 2011 17:13:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 60F5F8FC17 for ; Fri, 26 Aug 2011 17:13:05 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 19A7246B51; Fri, 26 Aug 2011 13:13:05 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A0CDE8A02F; Fri, 26 Aug 2011 13:13:04 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 26 Aug 2011 13:13:03 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20110826153940.GA3800@onelab2.iet.unipi.it> In-Reply-To: <20110826153940.GA3800@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108261313.03441.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 26 Aug 2011 13:13:04 -0400 (EDT) Cc: Luigi Rizzo 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 17:13:05 -0000 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