All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Gabor Gombas <gombasg@sztaki.hu>
Cc: htejun@gmail.com, bluez-devel@lists.sf.net, linux-kernel@vger.kernel.org
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs
Date: Sat, 5 Jan 2008 07:50:39 +0000	[thread overview]
Message-ID: <20080105075039.GF27894@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20080102151642.GA7273@boogie.lpds.sztaki.hu>

On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
> Heh, it seems talking about a bug makes it trigger:
> 
> Jan  2 16:05:45 twister kernel: Unable to handle kernel NULL pointer dereference at 00000000000000b8 RIP: 
> Jan  2 16:05:45 twister kernel:  [<ffffffff804720a5>] mutex_lock+0x10/0x1d
 
> So the patch referenced above does not help. But I've found a very easy
> way to trigger the bug:
> 
> - do a "cat /dev/zero > /dev/rfcomm0"
> - switch the phone off
> - switch the phone on, and the kernel oopses

sysfs_get_dentry(),
                mutex_lock(&parent->d_inode->i_mutex);
hitting parent->d_inode either NULL or very close to it, depending on your
.config; most likely NULL, if offset of i_mutex is 0xb8 in your build.
That's plausible - 0xb8 is what you'd get on UP build without spinlock
debugging, lockdep, etc.

Assuming that this is what we get, everything looks explainable - we
have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
gets evicted.  We don't have any exclusion, so while we are playing
silly buggers with lookups in sysfs_get_dentry() we have parent become
negative; the rest is obvious...

AFAICS, the locking here is quite broken and frankly, sysfs_get_dentry()
and the way it plays with fs/namei.c are ucking fugly.

Could you stick
	if (!parent->d_inode)
		printk(KERN_WARNING "sysfs locking blows: %s",
			parent->d_name.name);
right before
                mutex_lock(&parent->d_inode->i_mutex);
                dentry = lookup_one_noperm(cur->s_name, parent);
                mutex_unlock(&parent->d_inode->i_mutex);
in sysfs_get_dentry() (fs/sysfs/dir.c) and verify that it does, indeed,
trigger?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Gabor Gombas <gombasg@sztaki.hu>
Cc: Dave Young <hidave.darkstar@gmail.com>,
	linux-kernel@vger.kernel.org, bluez-devel@lists.sourceforge.net,
	htejun@gmail.com
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs
Date: Sat, 5 Jan 2008 07:50:39 +0000	[thread overview]
Message-ID: <20080105075039.GF27894@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20080102151642.GA7273@boogie.lpds.sztaki.hu>

On Wed, Jan 02, 2008 at 04:16:42PM +0100, Gabor Gombas wrote:
> Heh, it seems talking about a bug makes it trigger:
> 
> Jan  2 16:05:45 twister kernel: Unable to handle kernel NULL pointer dereference at 00000000000000b8 RIP: 
> Jan  2 16:05:45 twister kernel:  [<ffffffff804720a5>] mutex_lock+0x10/0x1d
 
> So the patch referenced above does not help. But I've found a very easy
> way to trigger the bug:
> 
> - do a "cat /dev/zero > /dev/rfcomm0"
> - switch the phone off
> - switch the phone on, and the kernel oopses

sysfs_get_dentry(),
                mutex_lock(&parent->d_inode->i_mutex);
hitting parent->d_inode either NULL or very close to it, depending on your
.config; most likely NULL, if offset of i_mutex is 0xb8 in your build.
That's plausible - 0xb8 is what you'd get on UP build without spinlock
debugging, lockdep, etc.

Assuming that this is what we get, everything looks explainable - we
have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
gets evicted.  We don't have any exclusion, so while we are playing
silly buggers with lookups in sysfs_get_dentry() we have parent become
negative; the rest is obvious...

AFAICS, the locking here is quite broken and frankly, sysfs_get_dentry()
and the way it plays with fs/namei.c are ucking fugly.

Could you stick
	if (!parent->d_inode)
		printk(KERN_WARNING "sysfs locking blows: %s",
			parent->d_name.name);
right before
                mutex_lock(&parent->d_inode->i_mutex);
                dentry = lookup_one_noperm(cur->s_name, parent);
                mutex_unlock(&parent->d_inode->i_mutex);
in sysfs_get_dentry() (fs/sysfs/dir.c) and verify that it does, indeed,
trigger?

  parent reply	other threads:[~2008-01-05  7:50 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-28 17:32 [Bluez-devel] Oops involving RFCOMM and sysfs Gabor Gombas
2007-12-28 17:32 ` Gabor Gombas
2007-12-29  8:07 ` [Bluez-devel] " Dave Young
2007-12-29  8:07   ` Dave Young
2008-01-02 14:48   ` Gabor Gombas
2008-01-02 14:48     ` Gabor Gombas
2008-01-02 15:16   ` Gabor Gombas
2008-01-03 13:16     ` Gabor Gombas
2008-01-04  1:05       ` Dave Young
2008-01-04  1:05         ` Dave Young
2008-01-07  8:07         ` Tejun Heo
2008-01-07  8:07           ` Tejun Heo
2008-01-07 14:10         ` Gabor Gombas
2008-01-07 14:10           ` Gabor Gombas
2008-01-05  7:50     ` Al Viro [this message]
2008-01-05  7:50       ` Al Viro
2008-01-05 14:30       ` Tejun Heo
2008-01-05 14:30         ` Tejun Heo
2008-01-05 19:45         ` Al Viro
2008-01-05 19:45           ` Al Viro
2008-01-06  2:07           ` Tejun Heo
2008-01-06  2:07             ` Tejun Heo
2008-01-06  2:18             ` Al Viro
2008-01-06  2:18               ` Al Viro
2008-01-06  2:54               ` Tejun Heo
2008-01-06  2:54                 ` Tejun Heo
2008-01-06  3:35                 ` Al Viro
2008-01-06  3:35                   ` Al Viro
2008-01-06  3:54                   ` Tejun Heo
2008-01-07  2:37             ` Tejun Heo
2008-01-07  2:37               ` Tejun Heo
2008-01-07  8:21               ` Eric W. Biederman
2008-01-07  8:21                 ` Eric W. Biederman
2008-01-07  9:17                 ` Tejun Heo
2008-01-07  9:17                   ` Tejun Heo
2008-01-07  9:18                   ` Tejun Heo
2008-01-07  9:18                     ` Tejun Heo
2008-01-07  9:22                     ` Al Viro
2008-01-07  9:22                       ` Al Viro
2008-01-07 10:33                       ` Eric W. Biederman
2008-01-07 10:33                         ` Eric W. Biederman
2008-01-07 14:13       ` Gabor Gombas
2008-01-07 14:13         ` Gabor Gombas
2008-01-07 15:24         ` Tejun Heo
2008-01-07 15:24           ` Tejun Heo
2008-01-07 21:00           ` Gabor Gombas
2008-01-07 21:00             ` Gabor Gombas
2008-01-08  9:42             ` Tejun Heo
2008-01-08 13:32               ` Gabor Gombas
2008-01-08 13:32                 ` Gabor Gombas
2008-01-09  9:16                 ` Tejun Heo
2008-01-09  9:16                   ` Tejun Heo
2008-01-09 15:57                   ` Cornelia Huck
2008-01-10  1:11                   ` Dave Young
2008-01-10  1:11                     ` Dave Young
2008-01-11 23:09                     ` Gabor Gombas
2008-01-11 23:09                       ` Gabor Gombas
2008-01-14  7:05                       ` Dave Young
2008-01-14 12:52                         ` Cornelia Huck
2008-01-15  1:57                           ` Dave Young
2008-01-16  1:02                             ` Dave Young
2008-01-16 23:06                               ` Gabor Gombas
2008-01-17  7:24                                 ` Dave Young
2008-01-17  8:15                                   ` Dave Young
2008-01-17 11:42                                     ` Cornelia Huck
2008-01-18  3:37                                       ` Dave Young
2008-01-18  9:19                                         ` Cornelia Huck
2008-01-18 10:23                                           ` Cornelia Huck
2008-01-18 10:34                                             ` Dave Young
2008-01-18 11:26                                               ` Cornelia Huck
2008-01-21  3:15                                                 ` Dave Young
2008-01-21 15:09                                                   ` [Patch] Driver core: Cleanup get_device_parent() in device_add() and device_move() Cornelia Huck
2008-01-10 10:15                   ` [Bluez-devel] Oops involving RFCOMM and sysfs Gabor Gombas
2008-01-10 10:15                     ` Gabor Gombas

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=20080105075039.GF27894@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=bluez-devel@lists.sf.net \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=gombasg@sztaki.hu \
    --cc=htejun@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.