From owner-cvs-all@FreeBSD.ORG Tue Oct 19 23:30:13 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E07D016A4CE; Tue, 19 Oct 2004 23:30:12 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4002C43D31; Tue, 19 Oct 2004 23:30:12 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CK3Qh-00063u-00; Wed, 20 Oct 2004 01:30:11 +0200 Received: from [217.227.158.113] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CK3Qh-0000d9-00; Wed, 20 Oct 2004 01:30:11 +0200 From: Max Laier To: Andre Oppermann Date: Wed, 20 Oct 2004 01:29:44 +0200 User-Agent: KMail/1.7 References: <200410191513.i9JFDUbf072176@repoman.freebsd.org> <200410200035.19752.max@love2party.net> <41759D75.1B6BDDC2@freebsd.org> In-Reply-To: <41759D75.1B6BDDC2@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8580614.MdTMLZGYMr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410200129.54320.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Sam Leffler cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 23:30:13 -0000 --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--