Date: Tue, 19 Oct 2004 22:26:14 +0200 From: Andre Oppermann <andre@freebsd.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/sys protosw.h src/sys/kern uipc_domain.cuipc_socket2.c Message-ID: <41757866.EB97169@freebsd.org> References: <200410191513.i9JFDUbf072176@repoman.freebsd.org> <417532A2.9000901@errno.com> <41753522.1E39FEAE@freebsd.org> <20041019175807.GM22681@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41757866.EB97169>