knlist_empty locking fix

[Kostik Belousov]

On Thu, Jan 26, 2012 at 01:03:26PM -0800, Doug Ambrisko wrote:
> Ran into problems with running kqueue/aio with WITNESS etc.  Sometimes
> things are locked sometimes not.  knlist_remove is called telling it
> whether it is locked or not ie:
> 	 extern void    knlist_remove(struct knlist *knl, struct knote *kn, int islocked);
> so I changed:
> 	extern int     knlist_empty(struct knlist *knl);
> to:
> 	extern int     knlist_empty(struct knlist *knl, int islocked);
> 
> and then updated things to reflect that following what that state of the
> lock for knlist_remove.  If it is not locked, it gets a lock and 
> frees it after.
> 
> This now fixes a panic when a process using kqueue/aio is killed on
> shutdown with WITNESS.
> 
> It changes an API/ABI so it probably can't merged back.  If there are
> no objections then I'll commit it.
> 
Change to knlist_init() does not make sense at all, the knlist shall
not be exposed to other consumers during initialization, so no need
to exclude the parallel access.

Regarding the knlist_empty(), I propose to keep it as is. Locking
the knlist inside knlist_empty() does not make sense, because lock
is immediately dropped afterward, and relocked for remove. This way,
the entry could be removed from the list meantime (can it, really ?).

I think that you should take a lock around the whole if() {} statement,
and call knlist_remove with locked == 1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120127/4b63678c/attachment.pgp