Re: [BUG] XFS crash using Realtime Preemption patch

From: Nathaniel W. Filardo
Date: Tue Dec 21 2004 - 17:22:12 EST

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?

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

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.


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;
} else {

calls mrunlock() inlined - see abov
on ip->i_lock and/or ip->i_iolock, based on flags

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

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)

ASSERT's that lock is already taken

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

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
Please read the FAQ at