On Wed, May 4, 2011 at 2:49 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Tue, May 03, 2011 at 01:57:44PM -0700, akpm@xxxxxxxxxxxxxxxxxxxx wrote: >> Â Â Â struct backing_dev_info *old = inode->i_data.backing_dev_info; >> >> - Â Â if (dst == old) >> + Â Â if (dst == old) Â Â Â Â Â Â Â Â /* deadlock avoidance */ > > That's not an overly useful comment. ÂIt should be a proper block coment > documentation how that we could ever end up with the same bdi as > destination and source. I didn't put in a comment myself because it seemed obvious that we'd want to avoid calling something named bdi_lock_two(a, b) when a and b are the same; and I was expecting it to be obvious to you that actually we could get here with a and b the same. But apparently not. default_backing_dev_info? > > Which is something I wanted to ask Hugh anyway - do you have traces explaining > how this happens for you? Let's take out the patch and jot down the dmesg, omitting ? stale lines and function offsets from the backtrace. Something that may prove relevant: this is openSUSE 11.4, which cannot boot my kernels unless I have CONFIG_DEVTMPFS=y; and I've set CONFIG_DEVTMPFS_MOUNT=y too. No initramfs. ... VFS: Mounted root (ext2 filesystem) readonly on device 8:1. devtmpfs: mounted Freeing unused kernel memory: 352k freed udev[162]: starting version 166 BUG: spinlock recursion on CPU#0, blkid/299 lock: 78690c30, .magic: dead4ead, .owner: blkid/299, .owner_cpu: 0 Pid: 299, comm: blkid Not tainted 2.6.39-rc5-mm1 #4 Call Trace: spin_bug do_raw_spin_lock _raw_spin_lock_nested bdi_lock_two bdev_inode_switch_bdi __blkdev_get blkdev_get blkdev_open __dentry_open nameidata_to_filp do_last path_openat do_filp_open do_sys_open sys_open sysenter_do_call And indeed that "lock: 78690c30" falls inside my default_backing_dev_info at 78690ae4. Hugh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
