Issue with old relayfs - sanity check on apparent bug?

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.

Thanks,
  -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================