Re: OOPS REPORT: Will someone _please_ look at this? (was Re: BUG & OOPS REPORT: /proc/scsi/ entries not properly cleaned up)

From: Douglas Gilbert (
Date: Tue Oct 10 2000 - 22:16:08 EST

Matthew Dharm wrote:
> Yet more followup with myself.... I can reproduce this problem on
> 2.4.0-test10-pre1 every time. I'm using the ide-scsi and usb-storage
> modules to trigger the bug -- loading and then unloading either one causes
> /proc/scsi to not be cleaned up properly.
> As yet, nobody has indicated to me that they are looking into this problem.
> I've taken a few experimental pokes at it, and it seems that the SCSI layer
> is, in fact, calling the procfs function to remove the entries. At least,
> I think it is -- I'm not sure if it's the right entry.
> Will someone _please_ look at this? I consider this a critical item for
> 2.4.0, and I hope others do too.

Well I looked at it on the weekend and didn't see anything.
Unfortunately I don't have any USB devices or IDE cdroms
in the right place to replicate your configuration.

I guess the problem revolves around calling
remove_proc_entry() with the appropriate
arguments bottom up for the subtree you wish to
delete from procfs.

One way that I have noticed that you can see
that remove_proc_entry() is working is to
place the cwd in a procfs directory belonging
to driver you are about to rmmod. [For example:
'cd /proc/scsi/sg ; rmmod sg']. When the rmmod
is done the kernel spits out a message like:
   remove_proc_entry: scsi/sg busy, count=1

When I back out of that directory the kernel outputs:
   de_put: deferred delete of sg

Hope this helps.

Doug Gilbert

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:16 EST