[lkml]   [2000]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: OOPS REPORT: Will someone _please_ look at this? (was Re: BUG & OOPS REPORT: /proc/scsi/ entries not properly cleaned up)
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

 \ /
  Last update: 2005-03-22 12:39    [W:0.039 / U:1.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site