linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:


             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).