Date: Wed, 20 Oct 2004 01:29:44 +0200 From: Max Laier <max@love2party.net> To: Andre Oppermann <andre@freebsd.org> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c Message-ID: <200410200129.54320.max@love2party.net> In-Reply-To: <41759D75.1B6BDDC2@freebsd.org> References: <200410191513.i9JFDUbf072176@repoman.freebsd.org> <200410200035.19752.max@love2party.net> <41759D75.1B6BDDC2@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBdaNyXyyEoT62BG0RApIqAJ4wRz6J8Hm1f+ggtZQVYt1I8YKUPQCfbfT7 V70uCc7XYCrzxWRylZ3Qb6o= =CajA -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410200129.54320.max>