Re: Issue with old relayfs - sanity check on apparent bug?

Mathieu Desnoyers <[email protected]> Fri, 1 Feb 2008 10:51:49 -0500
Newsgroups gmane.linux.kernel.tracing
Message-ID <20080201155149.GA16451@Krystal>
* Mathieu Desnoyers ([email protected]) wrote:
> * Tim Bird ([email protected]) wrote:
> > Hi all,
> > 
> > I'm working on an old version of LTT (original, not NG)
> > and getting Oopses when I stop a trace, but only sometimes.
> > 
> > This is on a 2.6.11 kernel, and in fs/relayfs/relay.c I see the
> > following, which looks pretty bogus:
> > 
> > >         INIT_WORK(&rchan->work, remove_rchan_file, rchan);
> > >         schedule_delayed_work(&rchan->work, 1);
> > > 
> > >         clear_readers(rchan);
> > >         kfree(rchan);
> > 
> > remove_rchan_file() takes rchan as a parameter, and proceeds
> > to deallocate things, using contents of the rchan structure.
> > 
> > However, rchan is freed by the time remove_rchan_file()
> > is called by the workqueue code.  Often, it still has
> > valid stuff in it, but sometimes not.
> > 
> > Anyone remember anything about this?
> > 
> > I double-checked this by modifying the code to allocate
> > another rchan right after the kfree and poison it b
> > memset'ing it to all zeros, and I can produce an Oops every time.
> > 
> > I'm going to work on a fix, but I thought I'd check with
> > the list to see if anyone had seen or remembers anything like
> > this and could confirm that the above is a problem.
> > 
> > This code was obsolete by 2.6.16 (and probably before then),
> > but I'm stuck working on 2.6.11 at the moment.
> > 
> > And feedback would be appreciated.
> > 
> 
> Hrm, those details are really far away.. but looking at the code, moving
> the clear_readers() call and kfree(chan) to the end of
> remove_rchan_file() should probably fix your problem.
> 

Hrm, this approach is buggy too : kfree(chan) will also kfree the
rchan->work, which contains a worker list entry what is probably being
used to get the next work. You'll have to dig further, sorry.

> Mathieu
> 
> > Thanks,
> >   -- Tim
> > 
> > =============================
> > Tim Bird
> > Architecture Group Chair, CE Linux Forum
> > Senior Staff Engineer, Sony Corporation of America
> > =============================
> > 
> > _______________________________________________
> > Ltt-dev mailing list
> > [email protected]
> > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> > 
> 
> -- 
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> _______________________________________________
> Ltt-dev mailing list
> [email protected]
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68