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
--nextPart8580614.MdTMLZGYMr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 are introduceing something that is not fully though about. We will have problems with this and I really think that it should be backed= =20 out now and fixed before reconsidered! Unloading (of divert) has races that can be triggered. Claiming that they w= ill=20 not be "most of the time" is not exactly the right approach for serious=20 development. And for pointing out specifics: ip_encap is going to be a lot of fun. And=20 that's just the most obvious, I could find. I will not scan the tree for mo= re=20 places, but the ip_icmp.c example shows that you didn't scan the tree=20 carefully enough before you committed this work without previous discussion= =2E=20 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 th= is=20 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 lik= e: > > > > 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 t= o=20 panic the box. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart8580614.MdTMLZGYMr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBdaNyXyyEoT62BG0RApIqAJ4wRz6J8Hm1f+ggtZQVYt1I8YKUPQCfbfT7 V70uCc7XYCrzxWRylZ3Qb6o= =CajA -----END PGP SIGNATURE----- --nextPart8580614.MdTMLZGYMr--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410200129.54320.max>