cvs commit: src/sys/kern tty.c

[John Baldwin]

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