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