xfs
[Top] [All Lists]

Re: xfstest 179 ASSERT

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfstest 179 ASSERT
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Thu, 01 Nov 2012 08:08:59 -0500
Cc: xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20121101014910.GO29378@dastard>
References: <50916CBA.7050602@xxxxxxx> <20121101014910.GO29378@dastard>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 10/31/12 20:49, Dave Chinner wrote:
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.


I have been spending too much time in earlier versions of XFS.

Last night, I had a good laugh at my mistake when I realized the perag
was not in an array...duh me, this is the radix tree of the perag
structures. I could not do a crash "kmem" command, that would have
given me a clue.

I *think* Ben is also seeing this assert on his 32 bit test machine.
Thanks for the advice, I will do some investigation this weekend.

--Mark.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: xfstest 179 ASSERT, Mark Tinguely <=