xfs
[Top] [All Lists]

Re: Rambling noise #1: generic/230 can trigger kernel debug lock detecto

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Rambling noise #1: generic/230 can trigger kernel debug lock detector
From: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Date: Sat, 11 May 2013 00:48:49 -0400
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=73zaK/UdUcc+bYe3N9aYddkQ9ZYP7EMVOu74BenOni0=; b=w58c5yIwnz8BHi7t1VaQgIs0OBJWJKBwbDPoNA2KgkTEy76Ip+4BkavpXhVbYF9NKq 4NRw8YD+TPSYsXUPvDoZ2nJdafkdMGfap/aw9Pl2b0wwf+UyZttURtqKXJfdjk8Ac2ER sy2mwzLd4GOjZrdy+VxICbRKbFV4xoNNmZi+6iI8PnzqiQ0OhDtyndqWpS4P7jrgQsHz /N65JRN3zbixPdtUVC6M6Zr5H5/+jRcZw6dQAdWe8maCW6mvJSm8mxAhohHFtyNIQfKU MOSkq/YlxwpDSuGEk+MmMz07+PvIVZrnAtv6xXppNw0YG5OnuTgU8j8G7gJQB6GLOC+p BYJg==
In-reply-to: <20130511011732.GC32675@dastard>
References: <518B08D9.1060906@xxxxxxxxx> <20130509031646.GN24635@dastard> <20130509072045.GO24635@dastard> <518C54AA.7070908@xxxxxxxxx> <20130510021942.GP23072@dastard> <CAJzLF9kmBuQ5+-7NbzPqjUxG5yUELxCxjhh=3NiTFD0dNh-UXQ@xxxxxxxxxxxxxx> <20130511011732.GC32675@dastard>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
On 05/10/2013 09:17 PM, Dave Chinner wrote:
On Fri, May 10, 2013 at 03:07:19PM -0400, Michael L. Semon wrote:
On Thu, May 9, 2013 at 10:19 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
On Thu, May 09, 2013 at 10:00:10PM -0400, Michael L. Semon wrote:

Thanks for looking at it.  There are going to be plenty of false
positives out there.  Is there a pecking order of what works best?  As
in...

* IRQ (IRQs-off?) checking: worth reporting...?
* sleep inside atomic sections: fascinating, but almost anything can trigger it
* multiple-CPU deadlock detection: can only speculate on a uniprocessor system
* circular dependency checking: YMMV
* reclaim-fs checking: which I knew how much developers need to
conform to reclaim-fs, or what it is

If there's XFS in the trace, then just post them. We try to fix
false positives (as well as real bugs) so lockdep reporting gets more
accurate and less noisy over time.

Cheers,

Dave.


Feel free to ignore and flame them as well. I'm going to make another attempt to triage my eldest Pentium 4, and there's a high chance that you'll have to reply, "Despite the xfs_* functions, that looks like a DRM issue. Go bug those guys."

Thanks!

Michael

During generic/249 (lucky, first test out)...
======================================================
[ INFO: possible circular locking dependency detected ]
3.9.0+ #2 Not tainted
-------------------------------------------------------
xfs_io/1181 is trying to acquire lock:
(sb_writers#3){.+.+.+}, at: [<c10f01be>] generic_file_splice_write+0x7e/0x1b0

but task is already holding lock:
 (&(&ip->i_iolock)->mr_lock){++++++}, at: [<c11dca9a>] xfs_ilock+0xea/0x190

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&(&ip->i_iolock)->mr_lock){++++++}:
       [<c1061580>] lock_acquire+0x80/0x100
       [<c1047184>] down_write_nested+0x54/0xa0
       [<c11dca9a>] xfs_ilock+0xea/0x190
       [<c1190d2c>] xfs_setattr_size+0x30c/0x4a0
       [<c1190eec>] xfs_vn_setattr+0x2c/0x30
       [<c10dd40c>] notify_change+0x13c/0x360
       [<c10c233a>] do_truncate+0x5a/0xa0
       [<c10cfcce>] do_last.isra.46+0x31e/0xb90
       [<c10d05db>] path_openat.isra.47+0x9b/0x3e0
       [<c10d0951>] do_filp_open+0x31/0x80
       [<c10c35f1>] do_sys_open+0xf1/0x1c0
       [<c10c36e8>] sys_open+0x28/0x30
       [<c140e1df>] sysenter_do_call+0x12/0x36

-> #1 (&sb->s_type->i_mutex_key#6){+.+.+.}:
       [<c1061580>] lock_acquire+0x80/0x100
       [<c140a1d4>] mutex_lock_nested+0x64/0x2b0
       [<c10c2330>] do_truncate+0x50/0xa0
       [<c10cfcce>] do_last.isra.46+0x31e/0xb90
       [<c10d05db>] path_openat.isra.47+0x9b/0x3e0
       [<c10d0951>] do_filp_open+0x31/0x80
       [<c10c35f1>] do_sys_open+0xf1/0x1c0
       [<c10c36e8>] sys_open+0x28/0x30
       [<c140e1df>] sysenter_do_call+0x12/0x36

-> #0 (sb_writers#3){.+.+.+}:
       [<c1060d55>] __lock_acquire+0x1465/0x1690
       [<c1061580>] lock_acquire+0x80/0x100
       [<c10c75ad>] __sb_start_write+0xad/0x1b0
       [<c10f01be>] generic_file_splice_write+0x7e/0x1b0
       [<c1184813>] xfs_file_splice_write+0x83/0x120
       [<c10ee8c5>] do_splice_from+0x65/0x90
       [<c10ee91b>] direct_splice_actor+0x2b/0x40
       [<c10f03d9>] splice_direct_to_actor+0xb9/0x1e0
       [<c10f0562>] do_splice_direct+0x62/0x80
       [<c10c5166>] do_sendfile+0x1b6/0x2d0
       [<c10c538e>] sys_sendfile64+0x4e/0xb0
       [<c140e1df>] sysenter_do_call+0x12/0x36

other info that might help us debug this:

Chain exists of:
  sb_writers#3 --> &sb->s_type->i_mutex_key#6 --> &(&ip->i_iolock)->mr_lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&(&ip->i_iolock)->mr_lock);
                               lock(&sb->s_type->i_mutex_key#6);
                               lock(&(&ip->i_iolock)->mr_lock);
  lock(sb_writers#3);

 *** DEADLOCK ***

1 lock held by xfs_io/1181:
#0: (&(&ip->i_iolock)->mr_lock){++++++}, at: [<c11dca9a>] xfs_ilock+0xea/0x190

stack backtrace:
Pid: 1181, comm: xfs_io Not tainted 3.9.0+ #2
Call Trace:
 [<c1406cc7>] print_circular_bug+0x1b8/0x1c2
 [<c1060d55>] __lock_acquire+0x1465/0x1690
 [<c105e4bb>] ? trace_hardirqs_off+0xb/0x10
 [<c1061580>] lock_acquire+0x80/0x100
 [<c10f01be>] ? generic_file_splice_write+0x7e/0x1b0
 [<c10c75ad>] __sb_start_write+0xad/0x1b0
 [<c10f01be>] ? generic_file_splice_write+0x7e/0x1b0
 [<c10f01be>] ? generic_file_splice_write+0x7e/0x1b0
 [<c10f01be>] generic_file_splice_write+0x7e/0x1b0
 [<c11dca9a>] ? xfs_ilock+0xea/0x190
 [<c1184813>] xfs_file_splice_write+0x83/0x120
 [<c1184790>] ? xfs_file_fsync+0x210/0x210
 [<c10ee8c5>] do_splice_from+0x65/0x90
 [<c10ee91b>] direct_splice_actor+0x2b/0x40
 [<c10f03d9>] splice_direct_to_actor+0xb9/0x1e0
 [<c10ee8f0>] ? do_splice_from+0x90/0x90
 [<c10f0562>] do_splice_direct+0x62/0x80
 [<c10c5166>] do_sendfile+0x1b6/0x2d0
 [<c10b45b4>] ? might_fault+0x94/0xa0
 [<c10c538e>] sys_sendfile64+0x4e/0xb0
 [<c140e1df>] sysenter_do_call+0x12/0x36
XFS (sdb5): Mounting Filesystem
XFS (sdb5): Ending clean mount

<Prev in Thread] Current Thread [Next in Thread>