Date: Tue, 21 May 2002 10:39:13 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Jeffrey Hsu <hsu@FreeBSD.org> Cc: smp@freebsd.org Subject: RE: socket locks Message-ID: <XFMail.20020521103913.jhb@FreeBSD.org> In-Reply-To: <0GWF00DL3Q1GXZ@mta6.snfc21.pbi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21-May-2002 Jeffrey Hsu wrote: > > 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. Agreed, the value you read with the lock held above becomes invalid/stale as soon as you drop the lock, so the lock really isn't doing much good. It is, however, obfuscating the code and will probably have to be backed out when the code is more fully locked. Changes like this don't make reading/writing so_options safe. It is not enough just to lock the reads and writes, you need to lock the results of actions taken on those values as well to ensure that multiple actions taken on an object all perform them on a consistent snapshot of that object. > 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. Can the various folks working on the network stack possibly "sit down" and write up a description of the overall locking strategy for the stack including the required lock orders, etc.? That would be a big help in coordinating things better. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.20020521103913.jhb>