lkml.org 
[lkml]   [2007]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject2.6.22-rc1: loop.c
    On Sat, May 12, 2007 at 08:20:35PM -0700, Linus Torvalds wrote:
    > Ok, the merge window has closed, and 2.6.22-rc1 is out there.

    1. Should loop.c create max_loop or 8 devices for compatability?
    I'm asking because quite a few people after upgrade will try
    to find out where the hell is right place to create device
    nodes like loop0 in distro of choice.

    Offending line in my setup is

    /portage /usr/portage auto loop,noatime 0 0


    2. After (so far) manual invocations of mknod and mount -a, lockdep spit
    the following:

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.22-rc1 #1
    -------------------------------------------------------
    mount/6168 is trying to acquire lock:
    (block_subsys_lock){--..}, at: [<c0290b1d>] kobj_map+0x94/0xf3

    but task is already holding lock:
    (loop_devices_mutex){--..}, at: [<c0292364>] loop_lock+0xd/0x13

    which lock already depends on the new lock.


    the existing dependency chain (in reverse order) is:

    -> #1 (loop_devices_mutex){--..}:
    [<c012566f>] add_lock_to_list+0x68/0x8d
    [<c0126cbb>] debug_check_no_locks_freed+0x10a/0x127
    [<c0127963>] __lock_acquire+0x993/0xafa
    [<c0292364>] loop_lock+0xd/0x13
    [<c0127e74>] lock_acquire+0x54/0x6b
    [<c0292364>] loop_lock+0xd/0x13
    [<c034c7fc>] __mutex_lock_slowpath+0xd9/0x254
    [<c0292364>] loop_lock+0xd/0x13
    [<c034c96f>] __mutex_lock_slowpath+0x24c/0x254
    [<c02909ff>] kobj_lookup+0x34/0xbe
    [<c0292364>] loop_lock+0xd/0x13
    [<c0290a49>] kobj_lookup+0x7e/0xbe
    [<c0293355>] loop_probe+0x0/0x12e
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c0232a1e>] get_gendisk+0x11/0x1c
    [<c01677d8>] do_open+0x2e/0x261
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c034de80>] _spin_unlock+0x28/0x42
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c0167bc7>] blkdev_open+0x27/0x4f
    [<c0147c0e>] __dentry_open+0x9a/0x142
    [<c0147d2c>] nameidata_to_filp+0x24/0x33
    [<c0147d72>] do_filp_open+0x37/0x3e
    [<c0147ae3>] get_unused_fd+0x1e/0xaf
    [<c034de80>] _spin_unlock+0x28/0x42
    [<c0147b6a>] get_unused_fd+0xa5/0xaf
    [<c0147db5>] do_sys_open+0x3c/0x6f
    [<c0147e23>] sys_open+0x1c/0x20
    [<c01025c6>] sysenter_past_esp+0x5f/0x99
    [<ffffffff>] 0xffffffff

    -> #0 (block_subsys_lock){--..}:
    [<c012784f>] __lock_acquire+0x87f/0xafa
    [<c034df55>] _spin_unlock_irqrestore+0x37/0x5d
    [<c0127e74>] lock_acquire+0x54/0x6b
    [<c0290b1d>] kobj_map+0x94/0xf3
    [<c034c7fc>] __mutex_lock_slowpath+0xd9/0x254
    [<c0290b1d>] kobj_map+0x94/0xf3
    [<c0126b8e>] trace_hardirqs_on+0x118/0x13b
    [<c0126cbb>] debug_check_no_locks_freed+0x10a/0x127
    [<c0290b1d>] kobj_map+0x94/0xf3
    [<c0232a84>] blk_register_region+0x2f/0x34
    [<c0232224>] exact_match+0x0/0x4
    [<c0232954>] exact_lock+0x0/0x13
    [<c0232ab8>] add_disk+0x2f/0x41
    [<c0232224>] exact_match+0x0/0x4
    [<c0232954>] exact_lock+0x0/0x13
    [<c029342c>] loop_probe+0xd7/0x12e
    [<c0290a64>] kobj_lookup+0x99/0xbe
    [<c0293355>] loop_probe+0x0/0x12e
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c0232a1e>] get_gendisk+0x11/0x1c
    [<c01677d8>] do_open+0x2e/0x261
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c034de80>] _spin_unlock+0x28/0x42
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c0167bc7>] blkdev_open+0x27/0x4f
    [<c0147c0e>] __dentry_open+0x9a/0x142
    [<c0147d2c>] nameidata_to_filp+0x24/0x33
    [<c0147d72>] do_filp_open+0x37/0x3e
    [<c0147ae3>] get_unused_fd+0x1e/0xaf
    [<c034de80>] _spin_unlock+0x28/0x42
    [<c0147b6a>] get_unused_fd+0xa5/0xaf
    [<c0147db5>] do_sys_open+0x3c/0x6f
    [<c0147e23>] sys_open+0x1c/0x20
    [<c01025c6>] sysenter_past_esp+0x5f/0x99
    [<ffffffff>] 0xffffffff

    other info that might help us debug this:

    1 lock held by mount/6168:
    #0: (loop_devices_mutex){--..}, at: [<c0292364>] loop_lock+0xd/0x13

    stack backtrace:
    [<c0126134>] print_circular_bug_tail+0x5e/0x66
    [<c012784f>] __lock_acquire+0x87f/0xafa
    [<c034df55>] _spin_unlock_irqrestore+0x37/0x5d
    [<c0127e74>] lock_acquire+0x54/0x6b
    [<c0290b1d>] kobj_map+0x94/0xf3
    [<c034c7fc>] __mutex_lock_slowpath+0xd9/0x254
    [<c0290b1d>] kobj_map+0x94/0xf3
    [<c0126b8e>] trace_hardirqs_on+0x118/0x13b
    [<c0126cbb>] debug_check_no_locks_freed+0x10a/0x127
    [<c0290b1d>] kobj_map+0x94/0xf3
    [<c0232a84>] blk_register_region+0x2f/0x34
    [<c0232224>] exact_match+0x0/0x4
    [<c0232954>] exact_lock+0x0/0x13
    [<c0232ab8>] add_disk+0x2f/0x41
    [<c0232224>] exact_match+0x0/0x4
    [<c0232954>] exact_lock+0x0/0x13
    [<c029342c>] loop_probe+0xd7/0x12e
    [<c0290a64>] kobj_lookup+0x99/0xbe
    [<c0293355>] loop_probe+0x0/0x12e
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c0232a1e>] get_gendisk+0x11/0x1c
    [<c01677d8>] do_open+0x2e/0x261
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c034de80>] _spin_unlock+0x28/0x42
    [<c0167ba0>] blkdev_open+0x0/0x4f
    [<c0167bc7>] blkdev_open+0x27/0x4f
    [<c0147c0e>] __dentry_open+0x9a/0x142
    [<c0147d2c>] nameidata_to_filp+0x24/0x33
    [<c0147d72>] do_filp_open+0x37/0x3e
    [<c0147ae3>] get_unused_fd+0x1e/0xaf
    [<c034de80>] _spin_unlock+0x28/0x42
    [<c0147b6a>] get_unused_fd+0xa5/0xaf
    [<c0147db5>] do_sys_open+0x3c/0x6f
    [<c0147e23>] sys_open+0x1c/0x20
    [<c01025c6>] sysenter_past_esp+0x5f/0x99
    =======================
    EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-13 22:53    [W:0.261 / U:0.996 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site