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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/