Date: Tue, 19 Oct 2004 10:58:07 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> 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: <20041019175807.GM22681@funkthat.com> In-Reply-To: <41753522.1E39FEAE@freebsd.org> References: <200410191513.i9JFDUbf072176@repoman.freebsd.org> <417532A2.9000901@errno.com> <41753522.1E39FEAE@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
I had to do this with the kqueue subsystem when dynamicly loading
filters..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041019175807.GM22681>