From: Wolfram Gloger <wg@malloc.de>
To: linux-kernel@vger.kernel.org, greg@kroah.com
Subject: usbfs race while mounting/umounting
Date: Fri, 11 Oct 2002 10:47:23 +0200 [thread overview]
Message-ID: <E17zvS7-00041g-00@mrvdomng.kundenserver.de> (raw)
[Please CC me on replies, thx]
I use usbfs, but normally have only a single USB device connected, a
generic mouse. When usbfs is unmounted on shutdown, I see "BUG at
inode.c:1034" in between 5% and 50% of all cases, the backtrace being
iput(), free_inode(), usbdevfs_put_super(), kill_super(), __mntput(),
etc.
I believe this to be a long standing problem, I remember seeing this
in 2.2.x as well, more than a year ago. Then I moved the mouse to a
2.4.x system, and I've seen the problem ever since. As a workaround,
I have moved the "umount /proc/bus/usb" after all disk umounts, but I
believe I've now finally tracked down the cause.
drivers/usb/inode.c says that all calls of its inode-list-manipulating
functions must occur with the kernel lock held. usbdevfs_read_super()
does _not_ do this, however, and I strongly suspect that my mouse is
auto-detected (occasionally) exactly while usbfs is being mounted.
The result is that the same inode ends up twice in usbfs's lists,
hence the "BUG in inode.c:1034" when it is iput() twice on shutdown.
The appended patch has fixed the problem for me, although I've only
done a few boot cycles with it.
Regards,
Wolfram.
--- drivers/usb/inode.c.orig Sat Aug 3 02:39:45 2002
+++ drivers/usb/inode.c Fri Oct 11 10:13:13 2002
@@ -628,6 +628,7 @@
s->s_root = d_alloc_root(root_inode);
if (!s->s_root)
goto out_no_root;
+ lock_kernel();
list_add_tail(&s->u.usbdevfs_sb.slist, &superlist);
for (i = 0; i < NRSPECIAL; i++) {
if (!(inode = iget(s, IROOT+1+i)))
@@ -639,13 +640,12 @@
list_add_tail(&inode->u.usbdev_i.slist, &s->u.usbdevfs_sb.ilist);
list_add_tail(&inode->u.usbdev_i.dlist, &special[i].inodes);
}
- down (&usb_bus_list_lock);
for (blist = usb_bus_list.next; blist != &usb_bus_list; blist = blist->next) {
bus = list_entry(blist, struct usb_bus, bus_list);
new_bus_inode(bus, s);
recurse_new_dev_inode(bus->root_hub, s);
}
- up (&usb_bus_list_lock);
+ unlock_kernel();
return s;
out_no_root:
next reply other threads:[~2002-10-11 8:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-11 8:47 Wolfram Gloger [this message]
2002-10-11 12:34 ` usbfs race while mounting/umounting Wolfram Gloger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E17zvS7-00041g-00@mrvdomng.kundenserver.de \
--to=wg@malloc.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).