Re: Issue with old relayfs - sanity check on apparent bug?
Mathieu Desnoyers <[email protected]> Fri, 1 Feb 2008 10:42:43 -0500
| Newsgroups | gmane.linux.kernel.tracing |
|---|---|
| Message-ID | <20080201154243.GA15442@Krystal> |
* 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. 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