Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> Wes Peters writes:
> : state the code is in now, and if someone wants it to be better, we await
> : their patches. As always. ;^)
>
> Tanimura-san did contribute patches. This problem isn't a race at the
> eject, but rather the network layer incompletely cleaning up after a
> device has gone away.
Robert Watson and I had a nice discussion about how to approach that
problem a while back. I've since gotten busy and forgotten about it,
as has he (apparently).
The quick (-ish) fix I came up with is to double all those cache ifp's
all over the code, and always check the first pointer for a null
reference before diving off through it. The disadvantage is the check
and dereference on every access, the advantage is being able to
nullify one pointer in the interface take-down and automagically have
all the cached references die. You would leak a single pointer for
every interface detach, unless you did reference counting or something
like that.
The full solution would be to implement reference counting in the if
objects, and to always check the state of the interface before trying
to exercise an associated function. It's an ugly problem with no real
simple solutions (in C).
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
[EMAIL PROTECTED] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
