xfs
[Top] [All Lists]

TAKE/TEST - fix Alpha "rm -Rf" deadlock bug

To: linux-xfs@xxxxxxxxxxx
Subject: TAKE/TEST - fix Alpha "rm -Rf" deadlock bug
From: Kelledin <kelledin+XFS@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 1 May 2003 21:14:35 -0500
In-reply-to: <20030429202146.LSXJ15122.imf31bis.bellsouth.net@tiger2>
References: <20030429202146.LSXJ15122.imf31bis.bellsouth.net@tiger2>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: KMail/1.5.1
After some testing and hammering the XFS 2003-04-07 patchset on 
my decrepit EV56 box, I got the best break I've had all week.  

The breakdown:

The XFS driver appears to make an assumption about sizeof(long) 
in fs/xfs/xfs_vfsops.c.  Apparently it's trying to clamp the max 
inode count to a signed 32-bit range based on that sizeof() 
assumption.  The assumption obviously doesn't hold for Alpha 
(and probably other 64-bit architectures as well).

(The only reason I stumbled on this at all is because it tripped 
a gcc warning that it doesn't trip on i386.  Long live -Wall!)

The obvious solution is to use the C99 types for integers with 
rigidly-defined sizes.  In this case, I believe the appropriate 
type is __int32_t, and the attached patch makes an adjustment 
for that.  I've been testing this fix for the last few hours, 
and the previous deadlock hasn't occurred once so far out of six 
testcase runs (without the fix, the deadlock would occur every 
one or two runs).

The attached patch is against the 2003-04-07 tree.  It also 
applies against current CVS (2003-05-01), albeit with a 
significant offset.

-- 
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"

Attachment: linux-2.4.20-xfs-alpha-deadlock.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>