Re: knlist_empty locking fix

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Fri, 27 Jan 2012 10:56:56 +0200
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.

Received on Fri Jan 27 2012 - 08:38:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:23 UTC