Date: Mon, 11 Sep 2006 14:28:01 -0400 From: John Baldwin <jhb@freebsd.org> To: Max Laier <max@love2party.net> Cc: cvs-src@freebsd.org, Martin Blapp <mbr@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern tty.c Message-ID: <200609111428.01836.jhb@freebsd.org> In-Reply-To: <200609111829.58796.max@love2party.net> References: <200609101651.k8AGpuqm069774@repoman.freebsd.org> <200609111048.19397.jhb@freebsd.org> <200609111829.58796.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 11 September 2006 12:29, Max Laier wrote: > On Monday 11 September 2006 16:48, John Baldwin wrote: > > On Sunday 10 September 2006 12:51, Martin Blapp wrote: > > > mbr 2006-09-10 16:51:56 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/kern tty.c > > > Log: > > > Fix locking race in ttymodem(). The locking of the proctree happens > > > too late and opens a small race window before tp->t_session->s_leader > > > is accessed. In case tp->t_session has just been set to NULL > > > elsewhere, we get a panic(). > > > > > > This fix is a bandaid until someone else fixes the whole locking in > > > the tty subsystem. Definitly more work needs to be done. > > > > > > MFC after: 1 week > > > Reviewed by: mlaier > > > PR: kern/103101 > > > > Did you ever try putting a 'mtx_assert(&Giant, MA_OWNED);' in place to > > see if Giant is held there? Until the tty system is locked, the proper > > fix is to put Giant back on top of it, not abuse the wrong lock. > > Abusing the wrong lock is only going to narrow the race, not fix it. > > Unless, of course, the offending call path (the one entering the tty code > w/o Giant) holds the "wrong lock", which - in this case - is likely as a > change of t_session means something was fiddling with the proctree. That doesn't wash if in this code path _neither_ lock was held prior to this commit. > Martin was trying to get you and others involved with this beforehand. > This commit is - as indicated in the commit message - a bandaid that > fixes the apparent problem. In Martin's installation this problem > manifests in panic()ing every other hour - I don't think that's a system > state we want to ship as FreeBSD 6.2. This is why we decided to commit > the bandaid now, after Martin's other requests for help and input timed > out. Seems like the plan worked and people start looking at this, now ;) I've told Martin numerous times that t_session is not locked by the proctree lock and thus by default it is covered by Giant. I think much of the session stuff still belongs under Giant in fact. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609111428.01836.jhb>