Date: Mon, 4 Dec 2000 11:14:15 -0600 (CST) From: Jonathan Lemon <jlemon@flugsvamp.com> To: julian@elischer.org, smp@freebsd.org Subject: Re: Netgraph and SMP Message-ID: <200012041714.eB4HEF152968@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-smp/3A2A5EE3.56E711B8@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-smp/3A2A5EE3.56E711B8@elischer.org> you write:
>
>
>I'm trying to figure out the locking needed for SMP in Netgraph.
>
>Here are some of the various constraints that I see. (some of theme are not just
>SMP issues).
>
>1/ can't remove modules that are being used (the base framework) or have living
>nodes (other netgraph modules).
>2/ Cannot remove a node if it is in use, (or in a return stack somewhere)
>3/ Cannot unlink an 'edge' if someone is passing data across it.
>4/ cannot use edges and nodes that are in the process of being set up or torn
>down.
>5/ Defered deliveries cannot be made to nodes that are being removed.
>6/ Nodes cannot be completely removed if there are pending deliveries for them.
>
>What locking schemes to otther people use for protecting intricate structures of
>objects with various interconnections? The buffer cache is one example that
>comes to mind, as is the routing table.
The routing table (which I'm in the process of locking down) uses
reference counts for outstanding references, plus a separate flag
to indicate the route is in the routing tree. So it's easier than
netgraph, (except trying to untangle the logic).
I have patches to make ng_ether_input (and ng_queue_data) MPSAFE from
the POV of ether_input. At the moment, it appears that since ether
nodes are not removed until the interface is down, there is no race
condition. If this wasn't the case, then there would be two possible
solutions:
1. place a mutex around the check/call to ng_ether_<foo>_p, to
remove the race condition, (possibly using a ref counter).
2. make ng_ether_<foo>_p always point to a valid (possibly NOP)
subroutine, and use another flag word to indicate whether the
routine is should be called or not. Use a timed/delayed delete
for freeing the module, to allow existing code to exit.
The first solution seems a little too heavyweight, and I haven't
extensively checked the second for races with the upper layer code.
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012041714.eB4HEF152968>