Re: race condition in knote deletion?

["Samuel J. Greear" <sjg@xxxxxxxxxxxx>]

On Wed, Feb 2, 2011 at 10:59 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :I have been contemplating this a bit too -- how to make the filters
> :more stateless (get rid of the lists) or at least make the list
> :handling more implicit.
> :
> :This seems like a reasonable approach. I think I would be in favor of
> :going about a refactor in the way you describe, assuming that we
> :export a new interface/api from devfs for devices with a devfs node
> :and that api is kept seperate from the existing kq api's (I guess it
> :would be a wrapper), which will continue to service files/sockets (and
> :devfs) directly. I think it is already a relatively confusing
> :subsystem and drawing a line there would at least keep it from
> :becoming more complicated.
> :
> :Sam
>
>    Another option is to register the kq lists via a kernel API, and
>    have the kernel kqueue code kmalloc() the structures independently.
>    Then on detach the kqueue API can clear the callback into the device
>    and keep the structure intact until all users of it go away.
>
>    We already have a structure that will almost do it.... struct filterops.
>    The problem with struct filterops is that devices will use just one copy
>    of the struct filterops for all the sub-devices so it isn't a suitable
>    structure to hold the kq lists itself.  Plus it is declared statically
>    so if a module detaches the declaration goes away (which is bad).
>
>    This kinda implies we should refactor the entire initialization portion
>    of the API, perhaps just using struct filterops as a skeleton and
>    have the kqueue code allocate its own internal copy for each instance
>    that also includes the kq lists.
>
>                                        -Matt
>                                        Matthew Dillon
>                                        <dillon@backplane.com>
>

This could conceivably be done using the existing kq initialization
functions that are embedded in the various dev_ops and other
structures. Instead of just assigning to (knote *)->kn_fop the static
filterops, this could be rolled up into public function(s) that these
initialization functions would call. This seems like a logical and
relatively straightforward improvement that might even be able to
simplify some of the boilerplate used in the many kqfilter init
functions.

That said, I don't see how either of these approaches is mutually
exclusive. It might be beneficial to do both.

Sam