Messages in this thread |  | | Date | Tue, 10 Oct 2000 23:16:08 -0400 | From | Douglas Gilbert <> | Subject | Re: 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.
Matt, 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |