From owner-freebsd-current@FreeBSD.ORG Sat Jul 18 00:10:47 2009 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 B8E24106564A for ; Sat, 18 Jul 2009 00:10:47 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 75B458FC14 for ; Sat, 18 Jul 2009 00:10:46 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.13.7/8.13.7) with ESMTP id n6HCQYZC033308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jul 2009 15:26:35 +0300 (EEST) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 796351CC39; Fri, 17 Jul 2009 15:26:38 +0300 (EEST) Date: Fri, 17 Jul 2009 15:26:38 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20090717122638.GA44356@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on comsys.ntu-kpi.kiev.ua Cc: freebsd-current@freebsd.org Subject: Re: help w.r.t. vfs_event_signal(..VQ_NOTRESPLOCK) in nlm 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: Sat, 18 Jul 2009 00:10:48 -0000 Hello, On Wed, 15 Jul 2009 12:16:27 -0400, Rick Macklem wrote: > The crashes occur because nlm_down() and nlm_up() assume that the > mount point structure still exists, when it might not. The part > that I don't understand is that they do the following: > vfs_event_signal(&nmp->nm_mountp->mnt_stat.f_fsid, > VQ_NOTRESPLOCK, 0); > once for each cycle of down/up, using a per-mountpoint flag. It's > the per-mountpoint flag that you don't actually have access to. > So, does anyone happen to know what the above does and whether it > has to happen once/mountpoint OR would once for all mountpoints be > sufficient? (Although fsid is the first argument, it appears that > it isn't actually used.) This part of code is related to kqueue, kqueue(2) and kevent(2) allow user processes to monitor some kernel events. These kernel events have different properties like filter number, flags value, data value. This is true that the first argument is not used in vfs_event_signal(). I guess that originally there was some idea to use some data with VFS related events to identify file system for which some event occurred, but actually this data is not used, unlike filters for files for example. When I was implementing "NFS exports atomic updates" (PR kern/136865) I used VQ_MOUNT/VQ_UNMOUNT to synchronize nfsserver and mountd visions of exported file systems and had to verify each VFS event, since 1) current API does not allow to identify VFS events and 2) multiple events that trigger the filter do not result in multiple kevents. The second property in some situations requires verification of triggered kevent from userland because multiple kevents are aggregated as I understand. The third argument looks like on/off flag for the same event, again it is not used.