All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sesterhenn <snakebyte@gmx.de>
To: xfs@oss.sgi.com
Subject: Locking Question
Date: Fri, 12 Sep 2008 11:45:59 +0200	[thread overview]
Message-ID: <20080912094559.GB17721@alice> (raw)

hi,

I have seen a lockdep warning about freeing a held lock in XFS when mounting a corrupted xfs image:

[ 3107.196539] XFS mounting filesystem loop0
[ 3107.213927] 
[ 3107.213936] =========================
[ 3107.214027] [ BUG: held lock freed! ]
[ 3107.214027] -------------------------
[ 3107.214027] mount/18967 is freeing memory cf724000-cf7241e7, with a lock still held there!
[ 3107.214027]  (&(&ip->i_lock)->mr_lock){----}, at: [<c039b4c5>] xfs_ilock+0x4f/0x67
[ 3107.214027] 2 locks held by mount/18967:
[ 3107.214027]  #0:  (&type->s_umount_key#21){----}, at: [<c0183201>] sget+0x1fe/0x336
[ 3107.214027]  #1:  (&(&ip->i_lock)->mr_lock){----}, at: [<c039b4c5>] xfs_ilock+0x4f/0x67
[ 3107.214027] 
[ 3107.214027] stack backtrace:
[ 3107.214027] Pid: 18967, comm: mount Not tainted 2.6.27-rc5-00361-g82a28c7 #86
[ 3107.214027]  [<c013dfbb>] debug_check_no_locks_freed+0xd6/0x115
[ 3107.214027]  [<c017ec0b>] kmem_cache_free+0x4a/0xbd
[ 3107.214027]  [<c039d42d>] ? xfs_idestroy+0x92/0x98
[ 3107.214027]  [<c039d42d>] xfs_idestroy+0x92/0x98
[ 3107.214027]  [<c039ba9c>] xfs_iget_core+0x2eb/0x48e
[ 3107.214027]  [<c039bca7>] xfs_iget+0x68/0xe1
[ 3107.214027]  [<c03ac73f>] xfs_mountfs+0x3e0/0x5d1
[ 3107.214027]  [<c013dee3>] ? trace_hardirqs_on+0xb/0xd
[ 3107.214027]  [<c013bae2>] ? lockdep_init_map+0x74/0x34a
[ 3107.214027]  [<c013bae2>] ? lockdep_init_map+0x74/0x34a
[ 3107.214027]  [<c01296dd>] ? init_timer+0x17/0x1a
[ 3107.214027]  [<c03c03c4>] xfs_fs_fill_super+0x1f3/0x393
[ 3107.214027]  [<c0183bc4>] get_sb_bdev+0xcd/0x10b
[ 3107.214027]  [<c016afe6>] ? kstrdup+0x2a/0x4c
[ 3107.214027]  [<c03be4ef>] xfs_fs_get_sb+0x13/0x15
[ 3107.214027]  [<c03c01d1>] ? xfs_fs_fill_super+0x0/0x393
[ 3107.214027]  [<c01837e7>] vfs_kern_mount+0x3b/0x76
[ 3107.214027]  [<c0183866>] do_kern_mount+0x32/0xba
[ 3107.214027]  [<c0196350>] do_new_mount+0x46/0x74
[ 3107.214027]  [<c01964f3>] do_mount+0x175/0x193
[ 3107.214027]  [<c013de9d>] ? trace_hardirqs_on_caller+0xf4/0x12f
[ 3107.214027]  [<c0166606>] ? __get_free_pages+0x1e/0x24
[ 3107.214027]  [<c07295d3>] ? lock_kernel+0x19/0x8c
[ 3107.214027]  [<c0196562>] ? sys_mount+0x51/0x9b
[ 3107.214027]  [<c0196575>] sys_mount+0x64/0x9b
[ 3107.214027]  [<c01038bd>] sysenter_do_call+0x12/0x31
[ 3107.214027]  =======================
[ 3107.220438] XFS: failed to read root inode

As far as I can see xfs_iget.c:xfs_iget_core() has several places
that seem problematic.

After line 228:

    228         if (lock_flags)
    229                 xfs_ilock(ip, lock_flags);
    230 
    231         if ((ip->i_d.di_mode == 0) && !(flags & XFS_IGET_CREATE)) {
    232                 xfs_idestroy(ip);
    233                 xfs_put_perag(mp, pag);
    234                 return ENOENT;
    235         }

we might take the lock for ip and then call xfs_idestroy() which frees the lock,
as far as I can tell there should be an additional 

if (lock_flags)
	xfs_iunlock(ip, lock_flags)

inside the if to release the lock before we free the memory.

Some lines later we have a similar issue:

    243         if (radix_tree_preload(GFP_KERNEL)) {
    244                 xfs_idestroy(ip);
    245                 delay(1);
    246                 goto again;
    247         }

The lock is still taken and we call xfs_idestroy().

Some lines later, usually the BUG_ON triggers first, but there is a config option somewhere to remove
them to save some space, so we should also unlock ip as far as I can tell.

    255         if (unlikely(error)) {
    256                 BUG_ON(error != -EEXIST);
    257                 write_unlock(&pag->pag_ici_lock);
    258                 radix_tree_preload_end();
    259                 xfs_idestroy(ip);
    260                 XFS_STATS_INC(xs_ig_dup);
    261                 goto again;
    262         }


Since I am not familar with the XFS code at all it would be nice if someone can
confirm that this is correct or tell me to take another look at this :-)

Thanks, Eric

             reply	other threads:[~2008-09-12  9:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-12  9:45 Eric Sesterhenn [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-02-06  0:22 locking question Rick Lindsley

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=20080912094559.GB17721@alice \
    --to=snakebyte@gmx.de \
    --cc=xfs@oss.sgi.com \
    /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.