From owner-cvs-all@FreeBSD.ORG Tue Oct 19 20:26: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 4769016A4CE for ; Tue, 19 Oct 2004 20:26:13 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4295443D60 for ; Tue, 19 Oct 2004 20:26:10 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 61592 invoked from network); 19 Oct 2004 20:25:06 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2004 20:25:06 -0000 Message-ID: <41757866.EB97169@freebsd.org> Date: Tue, 19 Oct 2004 22:26:14 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney References: <200410191513.i9JFDUbf072176@repoman.freebsd.org> <417532A2.9000901@errno.com> <41753522.1E39FEAE@freebsd.org> <20041019175807.GM22681@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 20:26:13 -0000 John-Mark Gurney wrote: > > Andre Oppermann wrote this message on Tue, Oct 19, 2004 at 17:39 +0200: > > > > Modified files: > > > > sys/sys protosw.h > > > > sys/kern uipc_domain.c uipc_socket2.c > > > > Log: > > > > Support for dynamically loadable and unloadable protocols within existing protocol > > > > families. > > > > > > > > > > I don't recall seeing this posted anywhere for comment. I have some > > > concerns about this general topic and this code seems incomplete (e.g. I > > > see no locking). > > > > Locking is not needed because there are no dead moments in transitioning > > from unregistered to registered and back. All calls to any of the protocol > > specific functions will return a valid result (even if it is only EOPNOTSUPP). > > There is no list manipulation going on. > > > > The caller of the function is required to assure that no dangeling sockets, > > references or memory allocations are left behind after unregistering. It's > > simply impossible to solve otherwise. For IPDIVERT which I have converted > > this works very well (it will simply refuse to unload if a divert socket is > > open). > > > > What remaining concerns do you have? > > I don't see any GIANT_REQUIRE, or locking around adding a new protocol.. > This means there could be a race where two modules loading a protocol > get assigned the same slot... Ok, that makes sense. Luckily loading protocols is a relatively rare occourence and highly unlikely to bite anyone soon. I'll add the giant lock just to be sure as you suggest though. > I had to do this with the kqueue subsystem when dynamicly loading > filters... I'll have a look how you solved it there. -- Andre