Re: [BUG] XFS crash using Realtime Preemption patch

[Nathaniel W. Filardo]

On Tue, 21 Dec 2004, Ingo Molnar wrote:

> * Nathaniel W. Filardo <nwf@xxxxxxxxxxxxxx> wrote:
>
> > Hello all.
> >
> > Using 2.6.10-rc3-mm1-V0.7.33-04 and TCFQ ver 17, I get the following
> > crash while trying to sync the portage tree, though the system seems
> > stable under interactive load (read: an rm command went OK prior to
> > this crash).
> >
> > Machine is a 933MHz transmeta laptop with IDE disk.
> >
> > Any more information you need?
> > --nwf;
> >
> > kernel BUG at kernel/rt.c:1210!
>
> Seems like an XFS bug at first sight. The BUG() means that an up_write()
> was done while a down_read() was active for the lock. Does XFS really do
> this? Initialization/destruction bugs can possibly cause such messages
> too.

> From what I can make of the XFS code, it looks fine.  Somebody's either 
being horribly rude to memory (stomp) or there's some other issue... 
sadly, the machine is a laptop and thus nigh on impossible to get any real 
debugging out of.

I don't *think* it's memory issues as it's pretty reproducable and is 
exactly the same every time I've tried.

Open to suggestions.

--nwf;

> Here's the call sequence:
>
> > EIP is at up_write+0x8c/0xa0
> >  [<c01d2d5c>] xfs_iunlock+0x7c/0xa0 (32)

fs/xfs/linux-2.6/mrlock.h: mrunlock( mrlock_t *mrp )
	Switches behavior based on mr_writer flag as to whether to
	up_read or up_write.  Since we're taking the up_write branch,
	we should look for where a down_read was called.  This can
	come through via a mraccessf or mrtryaccess.

	  if (mrp->mr_writer) {
	    mrp->mr_writer = 0;
	    up_write(&mrp->mr_lock);
	  } else {
	    up_read(&mrp->mr_lock);
	  }

fs/xfs/xfs_iget.c
	calls mrunlock() inlined - see abov
		on ip->i_lock and/or ip->i_iolock, based on flags

> >  [<c01d728c>] xfs_iflush+0x1cc/0x440 (12)

fs/xfs/xfs_inode.c
	ASSERT's that ip->i_lock is already taken, so we're probably
	chasing after that one.

> >  [<c01d85a0>] xfs_inode_item_push+0x10/0x20 (60)

fs/xfs/xfs_inode_item.c
	ASSERT's that lock is already taken

> >  [<c01ebd0a>] xfs_trans_push_ail+0x1aa/0x1e0 (8)

fs/xfs/xfs_trans_ail.c
	through IOP_TRYLOCK (maps to xfs_inode_item_trylock)
	through xfs_ilock_nowait (SHARED)
	locks both ip->i_lock and ip->i_iolock through mrtryaccess()
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/