From: Dave Jones <davej@redhat.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: VFS deadlock ?
Date: Thu, 21 Mar 2013 17:02:55 -0400 [thread overview]
Message-ID: <20130321210255.GD16406@redhat.com> (raw)
In-Reply-To: <20130321204704.GZ21522@ZenIV.linux.org.uk>
On Thu, Mar 21, 2013 at 08:47:04PM +0000, Al Viro wrote:
> On Thu, Mar 21, 2013 at 04:36:39PM -0400, Dave Jones wrote:
> > at some point during the fuzz run, this happened..
> >
> > Mar 20 15:20:41 kernel: [ 7578.784674] fuse init (API version 7.21)
> > Mar 20 15:20:41 systemd[1]: Mounting FUSE Control File System...
> > Mar 20 15:20:41 systemd[1]: Mounted FUSE Control File System.
> >
> > I guess something wandered into /dev/fuse and did something. Not sure why
> > systemd reacted though...
>
> AFAICS, fuse uses d_materialise_unique() and d_splice_alias(), though, so
> it's not too likely source of that crap; there's no d_instantiate() calls
> at all and the sole d_add() is using an inode that has just been allocated,
> so it won't be creating aliases either...
here we go...
WARNING: at fs/namei.c:2335 lock_rename+0x156/0x160()
Hardware name: GA-MA78GM-S2H
Modules linked in: vmw_vsock_vmci_transport vmw_vmci vsock hidp cmtp kernelcapi bnep caif_socket caif phonet nfnetlink rfcomm l2tp_ppp l2tp_netlink l2tp_core rose pppoe pppox ppp_generic slhc llc2 netrom af_key can_raw af_rxrpc scsi_transport_iscsi ipt_ULOG appletalk irda crc_ccitt decnet can_bcm can rds atm x25 ipx p8023 psnap p8022 llc ax25 nfc af_802154 lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb snd_pcm bluetooth rfkill snd_page_alloc snd_timer microcode serio_raw pcspkr snd edac_core soundcore r8169 mii vhost_net tun macvtap macvlan kvm_amd kvm radeon backlight drm_kms_helper ttm
Pid: 5633, comm: trinity-child3 Not tainted 3.9.0-rc3+ #107
Call Trace:
[<ffffffff810450f5>] warn_slowpath_common+0x75/0xa0
[<ffffffff810451da>] warn_slowpath_null+0x1a/0x20
[<ffffffff811c6df6>] lock_rename+0x156/0x160
[<ffffffff811cd907>] sys_renameat+0x1f7/0x3b0
[<ffffffff810b33a2>] ? get_lock_stats+0x22/0x70
[<ffffffff810b6b95>] ? trace_hardirqs_on_caller+0x115/0x1a0
[<ffffffff810b6b95>] ? trace_hardirqs_on_caller+0x115/0x1a0
[<ffffffff8134a3ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff816cd242>] system_call_fastpath+0x16/0x1b
---[ end trace 421592dfa22abfb0 ]---
p1=irda p2=irda
followed by...
=====================================
[ BUG: bad unlock balance detected! ]
3.9.0-rc3+ #107 Tainted: G W
-------------------------------------
trinity-child3/5633 is trying to release lock (&type->i_mutex_dir_key) at:
[<ffffffff816c104e>] mutex_unlock+0xe/0x10
but there are no more locks to release!
other info that might help us debug this:
1 lock on stack by trinity-child3/5633:
#0: blocked: (sb_writers#4){.+.+.+}, instance: ffff8801292d17d8, at: [<ffffffff811df294>] mnt_want_write+0x24/0x50
stack backtrace:
Pid: 5633, comm: trinity-child3 Tainted: G W 3.9.0-rc3+ #107
Call Trace:
[<ffffffff816c104e>] ? mutex_unlock+0xe/0x10
[<ffffffff810b4e10>] print_unlock_imbalance_bug+0x100/0x110
[<ffffffff810b9417>] lock_release_non_nested+0x257/0x320
[<ffffffff810b3288>] ? trace_hardirqs_off_caller+0x28/0xc0
[<ffffffff816c104e>] ? mutex_unlock+0xe/0x10
[<ffffffff816c104e>] ? mutex_unlock+0xe/0x10
[<ffffffff810b9587>] lock_release+0xa7/0x310
[<ffffffff816c0f4a>] __mutex_unlock_slowpath+0x8a/0x180
[<ffffffff816c104e>] mutex_unlock+0xe/0x10
[<ffffffff811c67f1>] unlock_rename+0x41/0x60
[<ffffffff811cd996>] sys_renameat+0x286/0x3b0
[<ffffffff810b33a2>] ? get_lock_stats+0x22/0x70
[<ffffffff810b6b95>] ? trace_hardirqs_on_caller+0x115/0x1a0
[<ffffffff810b6b95>] ? trace_hardirqs_on_caller+0x115/0x1a0
[<ffffffff8134a3ae>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff816cd242>] system_call_fastpath+0x16/0x1b
next prev parent reply other threads:[~2013-03-21 21:03 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 19:06 VFS deadlock ? Dave Jones
2013-03-21 19:21 ` Al Viro
2013-03-21 20:31 ` Dave Jones
2013-03-21 19:29 ` Al Viro
2013-03-21 20:15 ` Linus Torvalds
2013-03-21 20:26 ` Dave Jones
2013-03-21 20:32 ` Linus Torvalds
2013-03-21 20:36 ` Dave Jones
2013-03-21 20:47 ` Al Viro
2013-03-21 21:02 ` Dave Jones [this message]
2013-03-21 21:18 ` Linus Torvalds
2013-03-21 21:26 ` Al Viro
2013-03-21 21:41 ` Dave Jones
2013-03-21 21:47 ` Linus Torvalds
2013-03-21 21:55 ` Al Viro
2013-03-21 21:57 ` Linus Torvalds
2013-03-21 22:03 ` Al Viro
2013-03-21 21:52 ` Al Viro
2013-03-21 22:12 ` Dave Jones
2013-03-21 22:29 ` Dave Jones
2013-03-21 22:53 ` Linus Torvalds
2013-03-21 23:07 ` Dave Jones
2013-03-21 23:36 ` Al Viro
2013-03-21 23:58 ` Linus Torvalds
2013-03-22 0:01 ` Linus Torvalds
2013-03-22 0:12 ` Al Viro
2013-03-22 0:20 ` Al Viro
2013-03-22 0:22 ` Linus Torvalds
2013-03-22 1:22 ` Al Viro
2013-03-22 1:33 ` Linus Torvalds
2013-03-22 1:40 ` Al Viro
2013-03-22 4:37 ` [CFT] " Al Viro
2013-03-22 4:55 ` Linus Torvalds
2013-03-22 5:18 ` Al Viro
2013-03-22 5:33 ` Linus Torvalds
2013-03-22 6:09 ` Al Viro
2013-03-22 6:22 ` Al Viro
2013-03-22 16:23 ` Dave Jones
2013-03-22 19:43 ` Linus Torvalds
2013-03-22 21:28 ` Al Viro
2013-03-22 22:57 ` Eric W. Biederman
2013-03-22 5:19 ` Linus Torvalds
2013-03-22 0:08 ` Al Viro
2013-03-22 0:15 ` Linus Torvalds
2013-03-22 0:19 ` Linus Torvalds
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=20130321210255.GD16406@redhat.com \
--to=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/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.