From: Dave Chinner <david@fromorbit.com>
To: Dave Jones <davej@redhat.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com
Subject: Re: 3.7 XFS lockdep trace
Date: Wed, 12 Dec 2012 09:31:09 +1100 [thread overview]
Message-ID: <20121211223109.GD16353@dastard> (raw)
In-Reply-To: <20121211154207.GA12771@redhat.com>
On Tue, Dec 11, 2012 at 10:42:07AM -0500, Dave Jones wrote:
> This says rc8+, but it's just missing the Makefile change, so it's still there in 3.7
> Curious that firefox was the process mentioned here, as ~/.mozilla isn't on xfs.
> My only xfs partition is /data holding a kernel source tree & .ccache
The fs freeze lockdep annotations have caused some .... interesting
lockdep reports.....
> [30557.776326] 3 locks on stack by firefox/17386:
> [30557.776571] #0: blocked: (&mm->mmap_sem){++++++}, instance: ffff8800a823c308, at: [<ffffffff816ac2b3>] __do_page_fault+0x103/0x4f0
> [30557.777276] #1: blocked: (shrinker_rwsem){++++..}, instance: ffffffff81c49de0, at: [<ffffffff81169ccc>] shrink_slab+0x3c/0x510
> [30557.777962] #2: blocked: (&type->s_umount_key#42){.+.+.+}, instance: ffff8800c4ed5730, at: [<ffffffff811c24c4>] grab_super_passive+0x44/0x90
There's no filesystem specific locks here, and it indicates that
the shrinkers are involved, so firefox can indeed touch the XFS
filesystem directly this way...
> [30557.789160] RECLAIM_FS-ON-W at:
> [30557.789362] [<ffffffff810c8042>] mark_held_locks+0xb2/0x130
> [30557.789792] [<ffffffff810c8795>] lockdep_trace_alloc+0x75/0xd0
> [30557.790241] [<ffffffff811af81a>] kmem_cache_alloc_node_trace+0x3a/0x2e0
> [30557.790740] [<ffffffff81192242>] vm_map_ram+0x2a2/0x7f0
> [30557.791161] [<ffffffffa052a4c3>] _xfs_buf_map_pages+0x73/0x130 [xfs]
> [30557.791646] [<ffffffffa052baeb>] xfs_buf_get_map+0x15b/0x270 [xfs]
> [30557.792114] [<ffffffffa05ada19>] xfs_trans_get_buf_map+0x1d9/0x3b0 [xfs]
> [30557.792615] [<ffffffffa0589f04>] xfs_ialloc_inode_init+0xe4/0x1f0 [xfs]
Oh, that's already fixed in the 3.8- queue.
$ gl -n 1 7c4cebe
commit 7c4cebe8e02dd0b0e655605442bbe9268db9ed4f
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 23 14:24:23 2012 +1100
xfs: inode allocation should use unmapped buffers.
Inode buffers do not need to be mapped as inodes are read or written
directly from/to the pages underlying the buffer. This fixes a
regression introduced by commit 611c994 ("xfs: make XBF_MAPPED the
default behaviour").
....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2012-12-11 22:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-11 15:42 3.7 XFS lockdep trace Dave Jones
2012-12-11 22:31 ` Dave Chinner [this message]
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=20121211223109.GD16353@dastard \
--to=david@fromorbit.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).