Date: Tue, 28 May 2002 14:55:45 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket.c Message-ID: <XFMail.20020528145545.jhb@FreeBSD.org> In-Reply-To: <200205251910.g4PJAFn2088378@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25-May-2002 Garrett Wollman wrote: > <<On Tue, 21 May 2002 18:33:03 -0400 (EDT), John Baldwin <jhb@FreeBSD.org> said: > >> Then put the XXX over the gencount not the bzero so it actually makes sense. > > It's the bzero that causes the race. The comment is in the right > place, and makes perfect sense if you've paid any attention to > non-blocking synchronization. We allocate a new socket, with _NO_ other references to it from anyone else. How in the world do we end up with a race when we do the bzero? Who are we racing with? The only thing I can see in soalloc() that needs locking work is that so_gencnt and numopensockets need a lock. However, for the socket structure we just got back from malloc() that doesn't have any external references yet aside from the one local variable in soalloc(), how can any other thread even get to the socket to wreak havoc? > The purpose is to make it possible to copy out a list of thousands of > sockets reliably (mostly) without blocking the network stack, so that > activity doesn't grind to a halt whenever someone runs `netstat' on a > machine with 10,000 sockets outstanding. I fail to see why doing a bzero() on a private variable can block the network stack. > -GAWollman -- 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 cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020528145545.jhb>