[no subject]
On Tue, Aug 19, 2003 at 03:59:27PM -0700, Sam Leffler wrote:
> this note is to insure "everyone" is aware. If your are actively working
> on stuff related to the network code and I haven't already corresponded
> with you; please let me know so we can coordinate our work--I have no
> interest in duplicating the efforts of others. Otherwise, if you are
> working in this area I'd appreciate knowing about any significant changes
> planned that might affect what I'm doing.
I'm preparing to commit the attached, any objections?
(As soon as Jake wakes up, anyway ;).
Was loosely following the flow of things from BSD/OS; it doesn't appear
to impact on locking but I'm grateful for more expert review in this area.
mini@ has looked over it and doesn't see any immediate problems.
provisional log message:
Add the IP_ONESBCAST option, to enable undirected IP broadcasts to be sent on
specific interfaces. This is required by aodvd, and may in future help us
in getting rid of the requirement for BPF from our import of isc-dhcp.
Suggested by: fenestro
Reviewed by:mini
Referenced by: wstevens
Obtained from: BSD/OS
BMS
Generated by diffcoll on Wed 20 Aug 2003 12:08:21 BST
diff -uN src/sys/netinet/in.h.orig src/sys/netinet/in.h
--- /usr/src/sys/netinet/in.h.orig Tue Aug 19 22:57:16 2003
+++ /usr/src/sys/netinet/in.h Wed Aug 20 12:08:16 2003
@@ -388,6 +388,8 @@
#defineIP_IPSEC_POLICY 21 /* int; set/get security policy */
#defineIP_FAITH22 /* bool; accept FAITH'ed connections */
+#defineIP_ONESBCAST23 /* bool: send all-ones broadcast */
+
#defineIP_FW_ADD 50 /* add a firewall rule to chain */
#defineIP_FW_DEL 51 /* delete a firewall rule from chain */
#defineIP_FW_FLUSH 52 /* flush firewall rule chain */
diff -uN src/sys/netinet/ip_var.h.orig src/sys/netinet/ip_var.h
--- /usr/src/sys/netinet/ip_var.h.orig Tue Aug 19 23:08:49 2003
+++ /usr/src/sys/netinet/ip_var.h Wed Aug 20 12:07:48 2003
@@ -139,6 +139,7 @@
/* flags passed to ip_output as last parameter */
#defineIP_FORWARDING 0x1 /* most of ip header exists */
#defineIP_RAWOUTPUT0x2 /* raw ip header exists */
+#defineIP_SENDONES 0x4 /* send all-ones broadcast */
#defineIP_ROUTETOIFSO_DONTROUTE/* bypass routing tables */
#defineIP_ALLOWBROADCAST SO_BROADCAST/* can send broadcast packets
*/
diff -uN src/sys/netinet/in_pcb.h.orig src/sys/netinet/in_pcb.h
--- /usr/src/sys/netinet/in_pcb.h.orig Tue Aug 19 23:00:47 2003
+++ /usr/src/sys/netinet/in_pcb.h Wed Aug 20 12:07:48 2003
@@ -142,6 +142,7 @@
#defineINP_IPV60x2
#define INP_IPV6PROTO 0x4 /* opened under IPv6 protocol */
#define INP_TIMEWAIT 0x8 /* .. probably doesn't go here */
+#defineINP_ONESBCAST 0x10/* send all-ones broadcast */
u_char inp_ip_ttl; /* time to live proto */
u_char inp_ip_p; /* protocol proto */
diff -uN src/sys/netinet/ip_output.c.orig src/sys/netinet/ip_output.c
--- /usr/src/sys/netinet/ip_output.c.orig Tue Aug 19 23:01:37 2003
+++ /usr/src/sys/netinet/ip_output.cWed Aug 20 12:07:48 2003
@@ -469,6 +469,8 @@
error = EMSGSIZE;
goto bad;
}
+ if (flags & IP_SENDONES)
+ ip->ip_dst.s_addr = INADDR_BROADCAST;
m->m_flags |= M_BCAST;
} else {
m->m_flags &= ~M_BCAST;
@@ -1427,6 +1429,7 @@
case IP_RECVTTL:
case IP_RECVIF:
case IP_FAITH:
+ case IP_ONESBCAST:
error = sooptcopyin(sopt, &optval, sizeof optval,
sizeof optval);
if (error)
@@ -1469,6 +1472,10 @@
case IP_FAITH:
OPTSET(INP_FAITH);
break;
+
+ case IP_ONESBCAST:
+ OPTSET(INP_ONESBCAST);
+ break;
}
break;
#undef OPTSET
@@ -1562,6 +1569,7 @@
case IP_RECVIF:
case IP_PORTRANGE:
case IP_FAITH:
+ case IP_ONESBCAST:
switch (sopt->sopt_name) {
case IP_TOS:
@@ -1605,6 +1613,10 @@
case IP_FAITH:
optval = OPTBIT(INP_FAITH);
+ break;
+
+ case IP_ONESBCAST:
+ optval = OPTBIT(INP_ONESBCAST);
break;
}
er
CFR: fastforwarding locking
http://www.freebsd.org/~sam/fastforward.patch These lock the fast forwarding hash table with a lock per hash bucket. There is one known issue with these changes: a LOR with the bridge code caused by holding a lock across the call to forward the packet. Also, some statistics are not consistently updated. Beware of overlap with routing table locking changes. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFR: fast ipsec locking
http://www.freebsd.org/~sam/fastipsec.patch These changes add locking and cleanup some of the infrastructure; e.g. to do better accounting of dynamically allocated data structures. Basic operation is well-tested but I haven't done extensive testing of the re-keying (e.g. with racoon). There is one known performance bottleneck: the lock in the ipsecrequest structure is held for every outbound packet to guard against modification to the data structure. This looks to be fixable by redoing the SADB but won't happen for a while. Note that with these changes much of fast ipsec runs Giant-free because the crypto code is already Giant-free. I did some performance measurements a while back with this code and a Giant-free em driver and got netperf results over a h/w-accelerated 3DES+SHA1 tunnel that was about the same as -stable. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFG: domain locking
http://www.freebsd.org/~sam/domain.patch These add locking to the list of domains. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFG: raw socket locking
http://www.freebsd.org/~sam/rawsock.patch This locks the raw socket protocol control blocks using equivalent techniques to those used for udp, etc. There is one code restructuring done to simplify this work; equivalent to the one I added for udp. Note this change also removes the rip_olddiverterror sysctl. It was marked as "to be removed". I'll probably leave it alone and/or remove it in a separate pass. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFR: routing table locking
http://www.freebsd.org/~sam/rtentry.patch This is an extensive set of changes to lock routing table entries. There are some issues with these changes that will need to be resolved before committing the work. In particular the per-entry mutex is stored in the rtentry structure and this struct is visible to user applications like route(8). This must be fixed. For now I've #ifdef'd the mutex to be included only in the kernel. We'll either need to use an indirect reference to a mutex or, more likely, introduce an externalized version of struct rtentry to decouple kernel operation from user applications. It may be possible to jigger the code to make the lock in the entry be a leaf lock in which case we could use a mutex pool and a pointer to a mutex but I'm leaning more to decoupling the kernel from user apps as this has general benefits. These changes have been in use on 4 of my machines for several weeks. IPv6 has only been lightly tested. In general I consider the code very lightly tested so don't be surprised if you encounter issues. Also, because of the wide visibility of the routing table in the system I may have missed some uses that need locking. There are a couple of LOR issues to be resolved. In particular I recall there is one with the ARP cache. Another issue is that these changes do not include multicast routing. That code has been changing recently so I left it alone. I'm not well setup to test multicast routing so if someone with an existing setup is interested in tacking this please let me know. Note there is one API change buried in these diffs. I dropped the last parameter to rtredirect that allowed callers to receive a reference to the associated entry. This was not used in the system and introduced issues for locking. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFR: bridge locking
http://www.freebsd.org/~sam/bridge.patch This patch adds locking and also overhauls the bridge code some to do things like replace explicit numbers with #defines and cleanup the debugging code. I also restructured the forwarding code to avoid grabbing the ifnet lock if possible and optimized the common case of bridging two interfaces. There are a couple of LOR issues to be resolved before it can be committed. In particular the output path has a LOR that can deadlock. I'm making it available for review now in case folks have other comments. Beware that buried in these changes are a renaming of the bridge MIB variables to be under a net.link.ether.bridge. node. Those changes will not be carried over into the committed code unless folks are interested (since it'll break lots of rc scripts). Note that drivers that operate Giant-free with bridging need to release their "driver lock" before passing packets up. Otherwise the up call can result in an immediate return through the start method and deadlock (unless the lock is marked to allow recursion, which should be eliminated if at all possible). I've made these modifications for the em, wi, and sis drivers but have not committed them. The fxp driver already does this and the ath driver has a totally different locking strategy where this doesn't occur. Short term dropping the lock around the up call will work but is suboptimal. Long term we may want to revise the locking strategy for drivers to eliminate this issue. This will likely be revisited when I get to more performance tuning (unless someone else does it--hint hint). One other minor change: I moved the printf "BRIDGE 020214 loaded" under bootverbose. Can anyone tell me what 020214 means? This code has been in "production use" on my interior firewall (a soekris box) for a week. This box runs with the sis driver Giant-free. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CFR: ipfw locking
http://www.freebsd.org/~sam/ipfw.patch These changes add locking. There are two locks: one for static rules and one for dynamic rules. The associated dummynet changes are not included as I haven't tested them yet. The locking scheme may need to be revised to use something like sx locks; this will be revisited in a later pass. I've been running with these changes for a week on my interior firewall, but they are very lightly tested and need a good review and more testing. I don't plan to commit them until they get more of each. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dhclient withmultiple ip's
I am attempting to have dhclient grab two ip's from comcast. I know I have to set up the dhclient.conf with the pseudo section, but I am lost as what to do with the dhclient-script. It has to be different as to not drop the main interface ip configuration, but everything I do seems to just assign the same ip to the iface twice. Does it have to alias the second ip? Are there any suggestions you can give me? FreeBSD 4.7-RELEASE-p13 #22 isc-dhcp3-3.0.1.r11 Thank you for any help you can give, Don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
If memory serves me right, Sam Leffler wrote: > One other minor change: I moved the printf "BRIDGE 020214 loaded" under > bootverbose. Can anyone tell me what 020214 means? I recently started using bridge(4) functionality and was wondering about this too. Based on the output of "cvs annotate" and "cvs log", I concluded that it was a datestamp used by Luigi to keep track of which version he was working with (on HEAD, this line was last touched in revision 1.45, which was committed on 15 February 2002). Bruce. pgp0.pgp Description: PGP signature
Re: CFR: bridge locking
Sam Leffler wrote: http://www.freebsd.org/~sam/bridge.patch This patch adds locking and also overhauls the bridge code some to do things like replace explicit numbers with #defines and cleanup the debugging code. This is only mildly related, but maybe someone feels like looking at this in addition to your locking changes... I have a PR about the bridge code sitting at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632; the latest patch is at http://www.isi.edu/larse/software/bridge.patch It does two things: 1. Disables bridging for IPv6. This is probably too aggressive, since bridging is only problematic for link-local packets, but it makes a routed IPv6 configuration coexist with a bridged IPv4 one. A much better fix would be an overhaul of the bridge code so that each bridge has a single link-local address, instead of one per physical interface. (Similar to how it should/must only have one IPv4 address, but link-locals are auto-assigned.) Essentially, make a bridge set its own pseudo interface. 2. It forwards a copy of bridged packets to bpfs attached to interfaces in the bridge set that have no carrier. This makes dhcpd work on an interface of a bridge set that is unplugged. Again, a much better fix would be to have bridge sets show up as pseudo interfaces that dhcpd's bpf can then listen on. I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code that implements the pseudo-device approach? Lars PS: I needed both these changes for our Soekris-based "rent-a-subnet" box: http://www.isi.edu/tethernet/ -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: CFR: bridge locking
Lars Eggert wrote: Sam Leffler wrote: http://www.freebsd.org/~sam/bridge.patch This patch adds locking and also overhauls the bridge code some to do things like replace explicit numbers with #defines and cleanup the debugging code. This is only mildly related, but maybe someone feels like looking at this in addition to your locking changes... I have a PR about the bridge code sitting at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632; the latest patch is at http://www.isi.edu/larse/software/bridge.patch It does two things: 1. Disables bridging for IPv6. This is probably too aggressive, since bridging is only problematic for link-local packets, but it makes a routed IPv6 configuration coexist with a bridged IPv4 one. A much better fix would be an overhaul of the bridge code so that each bridge has a single link-local address, instead of one per physical interface. (Similar to how it should/must only have one IPv4 address, but link-locals are auto-assigned.) Essentially, make a bridge set its own pseudo interface. 2. It forwards a copy of bridged packets to bpfs attached to interfaces in the bridge set that have no carrier. This makes dhcpd work on an interface of a bridge set that is unplugged. Again, a much better fix would be to have bridge sets show up as pseudo interfaces that dhcpd's bpf can then listen on. If you get bridge to send/receive packets to/from vlan interfaces attached to them, I'll be forever grateful. I've been trying to configure a setup where a firewall is connected to redundant switches, but no solution I found could handle the vlan attachments. :-( -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Many pages make a thick book. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
On Wed, 20 Aug 2003, Lars Eggert wrote: > I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code > that implements the pseudo-device approach? I had an older set of patches (4.x?) that implemented a bridgeX interface that saw all of the packets bridged by the bridge. However, it was just a pseudo-interface for the purposes of BPF -- it didn't carry a link local address, etc. I never tested for interop with IPv6. You can find a very old version of this at www.watson.org/~robert/freebsd/bridge.patch. It required some cleanup of the interactions between the bridge code and IPFW code that have probably since happened in the main tree as well, so the chances of this applying or working are effectively 0. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
On Wed, 20 Aug 2003, Robert Watson wrote: > > On Wed, 20 Aug 2003, Lars Eggert wrote: > > > I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code > > that implements the pseudo-device approach? FreeBSD has both. If you use netgraph bridging then you are using a more "link level device" like approach. > > I had an older set of patches (4.x?) that implemented a bridgeX interface > that saw all of the packets bridged by the bridge. However, it was just a > pseudo-interface for the purposes of BPF -- it didn't carry a link local > address, etc. I never tested for interop with IPv6. You can find a very > old version of this at www.watson.org/~robert/freebsd/bridge.patch. It > required some cleanup of the interactions between the bridge code and IPFW > code that have probably since happened in the main tree as well, so the > chances of this applying or working are effectively 0. :-) > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
Julian Elischer wrote: On Wed, 20 Aug 2003, Robert Watson wrote: On Wed, 20 Aug 2003, Lars Eggert wrote: I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code that implements the pseudo-device approach? FreeBSD has both. If you use netgraph bridging then you are using a more "link level device" like approach. Nope. Neither netgraph nor bridge(4) produce a pseudo-interface. Unfortunately. It would have solved the problem I was discussing with you (alas, I found a y2k thread, in which Archie and you were also present, about that very same problem). Netgraph's ng_iface is not enough, because it's much more limitted. I had an older set of patches (4.x?) that implemented a bridgeX interface that saw all of the packets bridged by the bridge. However, it was just a pseudo-interface for the purposes of BPF -- it didn't carry a link local address, etc. I never tested for interop with IPv6. You can find a very old version of this at www.watson.org/~robert/freebsd/bridge.patch. It required some cleanup of the interactions between the bridge code and IPFW code that have probably since happened in the main tree as well, so the chances of this applying or working are effectively 0. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The penalty for laughing in a courtroom is six months in jail; if it were not for this penalty, the jury would never hear the evidence. -- H. L. Mencken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
On Wed, Aug 20, 2003 at 10:23:42AM -0700, Bruce A. Mah wrote: > If memory serves me right, Sam Leffler wrote: > > > One other minor change: I moved the printf "BRIDGE 020214 loaded" under > > bootverbose. Can anyone tell me what 020214 means? yes, it is a timestamp -- just to get an idea on when the code was last touched. cheers luigi > I recently started using bridge(4) functionality and was wondering > about this too. Based on the output of "cvs annotate" and "cvs log", > I concluded that it was a datestamp used by Luigi to keep track of > which version he was working with (on HEAD, this line was last touched > in revision 1.45, which was committed on 15 February 2002). > > Bruce. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
On Wed, 20 Aug 2003, Daniel C. Sobral wrote: > Julian Elischer wrote: > > > > On Wed, 20 Aug 2003, Robert Watson wrote: > > > > > >>On Wed, 20 Aug 2003, Lars Eggert wrote: > >> > >> > >>>I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code > >>>that implements the pseudo-device approach? > > > > > > FreeBSD has both. > > If you use netgraph bridging then you are using a more > > "link level device" like approach. > > Nope. Neither netgraph nor bridge(4) produce a pseudo-interface. > Unfortunately. It would have solved the problem I was discussing with > you (alas, I found a y2k thread, in which Archie and you were also > present, about that very same problem). > > Netgraph's ng_iface is not enough, because it's much more limitted. netgraph's eiface node may do better.. > > > > > > > > >>I had an older set of patches (4.x?) that implemented a bridgeX interface > >>that saw all of the packets bridged by the bridge. However, it was just a > >>pseudo-interface for the purposes of BPF -- it didn't carry a link local > >>address, etc. I never tested for interop with IPv6. You can find a very > >>old version of this at www.watson.org/~robert/freebsd/bridge.patch. It > >>required some cleanup of the interactions between the bridge code and IPFW > >>code that have probably since happened in the main tree as well, so the > >>chances of this applying or working are effectively 0. :-) > >> > >>Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > >>[EMAIL PROTECTED] Network Associates Laboratories > >> > >>___ > >>[EMAIL PROTECTED] mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-net > >>To unsubscribe, send any mail to "[EMAIL PROTECTED]" > >> > > > > > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > -- > Daniel C. Sobral (8-DCS) > Gerencia de Operacoes > Divisao de Comunicacao de Dados > Coordenacao de Seguranca > VIVO Centro Oeste Norte > Fones: 55-61-313-7654/Cel: 55-61-9618-0904 > E-mail: [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Outros: > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > The penalty for laughing in a courtroom is six months in jail; if it > were not for this penalty, the jury would never hear the evidence. > -- H. L. Mencken > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: bridge locking
On Wed, 20 Aug 2003, Lars Eggert wrote:
I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code
that implements the pseudo-device approach?
Julian Elischer wrote:
FreeBSD has both.
If you use netgraph bridging then you are using a more
"link level device" like approach.
On Wed, 20 Aug 2003, Daniel C. Sobral wrote:
Nope. Neither netgraph nor bridge(4) produce a pseudo-interface.
Unfortunately. It would have solved the problem I was discussing with
you (alas, I found a y2k thread, in which Archie and you were also
present, about that very same problem).
Netgraph's ng_iface is not enough, because it's much more limitted.
Julian Elischer wrote:
netgraph's eiface node may do better..
ENODOCS. :-)
I can barely configure this stuff with the existing docs. Without, I
won't even know what hooks there are for it! :-)
--
Daniel C. Sobral (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Outros:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
( /\__/\ )
\(^ @___..___@ ^)/
/\ (\/\/\/\/) /\
/ \(/\/\/\/\)/ \
-("")
\ _ /
( /( )\ )
_) (_V) (V_) (_
(V)(V)(V) (V)(V)(V)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: TCP socket shutdown race condition
>Well, I guess the spl() fix is probably going to be the quickest here
>then, please send it to me once you've pounded on it, Ed.
So my spl() fix seems to eliminate the problem for me but while I'm looking
at this stuff I want to make sure there aren't any related cases left in.
My current patch is at the end of this message.
One potential problem is a crfree() interrupting code that's incrementing a
ucred reference. For example, uipc_socket.c:socreate():
so->so_cred = p->p_ucred;
crhold(so->so_cred);
However, I don't think a crfree() interrupting between these should cause a
problem. The refcount would always be at least 2 to begin with, so the
ucred wouldn't be free()d.
Another possible problem is a crfree() interrupting a crfree() for the same
ucred. This would result in a double free, leading to who knows what
corruption. I did try the test against a kernel with invariants on, but
nothing happened; presumably the timing changed enough that the race
condition wouldn't occur.
I protected the if (--cr->cr_ref == 0) in crfree() with splhigh() but left
the actuall free() out of splhigh.
The cr->cr_ref++ in crhold() assembles to an incl (%eax) which will be
atomic on a single processor. However I don't think anything guarantees gcc
will emit that code for that source instruction, so I put a splhigh around
it too. Probably atomic_add_int would be better -- I'll try that out too.
Our stress test is running against the patch below, and I'll report any
findings. If you have any comments on this, please let me know.
Index: kern_prot.c
===
RCS file: /cvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.53.2.9
diff -c -3 -r1.53.2.9 kern_prot.c
*** kern_prot.c 9 Mar 2002 05:20:26 - 1.53.2.9
--- kern_prot.c 20 Aug 2003 22:12:29 -
***
*** 997,1003
--- 997,1005
crhold(cr)
struct ucred *cr;
{
+ int s = splhigh();
cr->cr_ref++;
+ splx(s);
}
/*
***
*** 1008,1017
--- 1010,1021
crfree(cr)
struct ucred *cr;
{
+ int s = splhigh();
if (cr->cr_ref == 0)
panic("Freeing already free credential! %p", cr);
if (--cr->cr_ref == 0) {
+ splx(s);
/*
* Some callers of crget(), such as nfs_statfs(),
* allocate a temporary credential, but don't
***
*** 1020,1026
--- 1024,1032
if (cr->cr_uidinfo != NULL)
uifree(cr->cr_uidinfo);
FREE((caddr_t)cr, M_CRED);
+ return;
}
+ splx(s);
}
/*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
