Date: Wed, 8 May 2002 09:16:56 -0700 From: Alfred Perlstein <bright@mu.org> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: current@FreeBSD.org, smp@FreeBSD.org Subject: Re: The updated socket patch and axing sotryfree() (Re: Locking down a socket, milestone 1) Message-ID: <20020508161656.GV36741@elvis.mu.org> In-Reply-To: <200205081159.g48Bx63i045654@rina.r.dl.itc.u-tokyo.ac.jp> References: <200204241110.g3OB8u8t006194@bunko> <200205081159.g48Bx63i045654@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
* Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> [020508 04:59] wrote: > > This is reverted. I cleaned up soisconnected() to avoid locking two > sockets at once. > > *_locked() functions and macros no longer exist. The following > functions and macros require a socket lock: > > o soref(), sorele(), sotryfree() > o so[rw]wakeup() > > > I would like to commit this patch in one or two weeks to start working > on a possible race between a user process and a netisr kthread, > prevented by only the Giant lock at the moment. > > When a user process calls sofree() for a listening socket, it attempts > to free the sockets in the connection queues by soabort(). If the > connection of an aborting socket gets dropped by a remote host (eg by > TCP RST), a netisr kthread also attempts to free the socket. Since > the reference count of a socket in a connection queue is zero, this > would resust in doubly freeing a socket. > > To solve that problem, I would like to axe sotryfree(). The PCB of a > socket and a connection queue should hold a reference to the > socket. This should make the reference count of an alive socket always > be >= 1, and ensure that there is only one referer to a socket to be > freed. > > Comments? I'm not sure exactly how this solves the problem, there may need to be a global socket mutex, perhaps putting this sort of operation under that may do what you want. Off the top of my head... I think one way of doing it is storing the hashlist that the socket belongs to (inpcb_hash) inside the sockets. That way after a lookup you will have the lock on the parent structure, a user process will have to follow the same locking paradym, basically look at the head socket, lock the hashlist, then manipulate the incomplete queue. Basically, protect this sort of operation via the hashlist because you pretty much need to anyway. :) Other than that, have you looked at what BSD/os does and what Linux does? Do they get it wrong or have any particular drawbacks? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020508161656.GV36741>