Re: help w.r.t. vfs_event_signal(..VQ_NOTRESPLOCK) in nlm

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.