Date: Fri, 12 Jul 2002 08:35:23 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Jeffrey Hsu <hsu@FreeBSD.org> Cc: Don Lewis <dl-freebsd@catspoiler.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet udp_usrreq.c Message-ID: <Pine.NEB.3.96L.1020712083351.91914B-100000@fledge.watson.org> In-Reply-To: <0GZ40040URTBIG@mta5.snfc21.pbi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Jul 2002, Jeffrey Hsu wrote: > > Now that I look at it, I think TCP has the opposite problem. I don't > > see either inp or tcbinfo being locked in tcp_close() before it > > calls in_pcbdetach(). > > They're locked higher up in the call graph by the functions that call > tcp_close(). If assumptions are made about locks being grabbed higher in the call graph, it's almost always a good idea to drop in locking assertions. They may already be there in the IP code (I haven't checked), but this is a general suggestion. When I was booting and testing jhb_proc on my SMP box, the assertions about both held (and unheld) locks were invaluable for fixing bugs. They count as documentation and active enforcement of the locking protocol, and have a much cleaner failure mode than gradual data corruption in kernel data structures. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories 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?Pine.NEB.3.96L.1020712083351.91914B-100000>