All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: xfstest 179 ASSERT
Date: Thu, 1 Nov 2012 12:49:10 +1100	[thread overview]
Message-ID: <20121101014910.GO29378@dastard> (raw)
In-Reply-To: <50916CBA.7050602@sgi.com>

On Wed, Oct 31, 2012 at 01:23:54PM -0500, Mark Tinguely wrote:
> OSS sources with the xfs: fix buffer shudown reference count mismatch
> patch and xfstest 179.
> 
> xfstest 179 started to have various asserts starting with the "move the
> workers" series, but mostly the b_hold count is zero assert.
> 
> Now that the b_hold count is fixed, the asert is:
> 
> XFS: Assertion failed: atomic_read(&pag->pag_ref) == 0,
> file: /root/xfs/fs/xfs/xfs_mount.c, line: 273

The only way you are going to track this down is through tracing
perag gets and puts, and finding the object that is missing a put.
There are already tracepoints for these and they tell you the caller
function, so that should be sufficient to find what function has a
get without a put...

The other possibility is that there are buffers that have not be
freed properly (or leaked), but IIRC this failure pre-exists
attaching the perag to buffers....

> mount perag information:
>   m_perag_tree = {
>     height = 0x1,
>     gfp_mask = 0x20,
>     rnode = 0xffff8803124bb4b1
>   },
> crash> radix_tree_node ffff8803124bb4b0
> struct radix_tree_node {
>   height = 0x1,
>   count = 0x3,
>   {
>     parent = 0x0,
>     callback_head = {
>       next = 0x0,
>       func = 0xffffffff812384b0 <radix_tree_node_rcu_free>
>     }
>   },
>   slots = {0x0, 0xffff88034fd6f540, 0xffff88034fd6f840,
> 0xffff88034fd6f240, 0x0,
>  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0,
>  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0,
>  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0,
>  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
>   tags = {{0x0}, {0x0}, {0x0}}
> }
> 
> The inodes at 0xffff88034fd6f540, 0xffff88034fd6f840, 0xffff88034fd6f240
> don't look valid.

Those aren't inodes based on the addresses - they are all in the
same page, so the size is at most 0x300 bytes (768 bytes). An XFS
inode is larger than this, but a radix tree node is smaller (560
bytes and fits 7 to a page on my x86_64 machines), so I'm not sure
what you have there. how big does /proc/slabinfo tell you a radix
tree node is?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-11-01  1:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31 18:23 xfstest 179 ASSERT Mark Tinguely
2012-11-01  1:49 ` Dave Chinner [this message]
2012-11-01 13:08   ` Mark Tinguely

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=20121101014910.GO29378@dastard \
    --to=david@fromorbit.com \
    --cc=tinguely@sgi.com \
    --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.