Date: Mon, 20 May 2002 17:15:42 -0700 From: Jeffrey Hsu <hsu@FreeBSD.org> To: smp@freebsd.org Subject: socket locks Message-ID: <0GWF00DL3Q1GXZ@mta6.snfc21.pbi.net>
next in thread | raw e-mail | index | archive | help
> tanimura 2002/05/19 22:41:09 PDT
> Modified files:
> (too many files)
> Log:
> Lock down a socket, milestone 1.
>
> Reviewed by: alfred
This patch mechanically adds a lot of locks around uses of socket fields.
For example, in tcp_output.c:
@@ -889,8 +897,11 @@ send:
#ifdef IPSEC
ipsec_setsocket(m, so);
#endif /*IPSEC*/
+ SOCK_LOCK(so);
+ soopts = (so->so_options & SO_DONTROUTE);
+ SOCK_UNLOCK(so);
error = ip_output(m, tp->t_inpcb->inp_options, &tp->t_inpcb->inp_route,
- (so->so_options & SO_DONTROUTE), 0);
+ soopts, 0);
}
Locking and immediately unlocking accesses to a socket field doesn't
accomplish anything. We want to lock the socket at the beginning of an
operation and release it at the end. This leads to way fewer locks inserted
into the networking code.
Furthermore, these mechanical bottom-up socket locks don't respect
lock ordering with respect to the top-down inpcb locks. Fortunately,
cvs update only resulted in a few conflicts with the inpcb locking code
and I can just turn off the socket lock macros in my tree.
We should coordiante better on working to lock up the networking code so
we're not working at cross-purposes.
Jeffrey
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?0GWF00DL3Q1GXZ>