cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c

[Max Laier]

On Wednesday 20 October 2004 01:04, Andre Oppermann wrote:
> Please point them out.  We can discuss specifics then instead of creating
> a clout of FUD.

Okay, that's the last straw. This is not FUD. We are really concerned that you 
are introduceing something that is not fully though about.

We will have problems with this and I really think that it should be backed 
out now and fixed before reconsidered!

Unloading (of divert) has races that can be triggered. Claiming that they will 
not be "most of the time" is not exactly the right approach for serious 
development.

And for pointing out specifics: ip_encap is going to be a lot of fun. And 
that's just the most obvious, I could find. I will not scan the tree for more 
places, but the ip_icmp.c example shows that you didn't scan the tree 
carefully enough before you committed this work without previous discussion. 
It seems that you just assume that everything is fine. It really is not!

I understand that you didn't want to slow things down in a bikeshed, but this 
is not ready, sorry.

> > > > Another point: If you really want to keep the possibility to remove a
> > > > protocol, you have to introduce some busy counter that pervents
> > > > removal while the kernel is inside a protocol function. This has to
> > > > be handled by the protocol itself, but it has to be taken care of
> > > > somehow.
> > >
> > > Yes, the protocol has to be able to handle its own unloading.  I have
> > > documented that fact.  If a protocol in unable to do so it should
> > > simply refuse any unload attempts with EBUSY.
> >
> > Divert can be paniced with the sysctl code, btw. You have something like:
> >
> > lock;
> > unlock;
> > SYSCTL_OUT; <-- this can be made to take *some* time
> > lock;  <-- this will panic once the lock is destroyed
>
> Oh well...

Pardon me?

> > And there are other problems. Yes, it is not a problem in the common
> > case, but you have to account for edge cases as well!
>
> And you have to account for that unloads do not happen for every packet
> that goes through the box.

The fact that an unload happens very seldom, is not an excuse to allow it to 
panic the box.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20041020/b0f7f75d/attachment.bin