xfs
[Top] [All Lists]

ADD 799238 - RAM disk driver breaks locking hierarchy

To: nb@xxxxxxx
Subject: ADD 799238 - RAM disk driver breaks locking hierarchy
From: pv@xxxxxxxxxxxxxxxxxxxxxx (lord@xxxxxxx)
Date: Thu, 17 Aug 2000 07:45:05 -0700 (PDT)
Cc: linux-xfs@xxxxxxxxxxx
Reply-to: sgi.bugs.xfs@xxxxxxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
 Submitter : dxm                       Status : open                        
 Assigned Engineer : nb                Priority : 2                         
*Modified Date : 08/17/00             *Modified User : lord                 
*Modified User Domain : sgi.com       *Description :
OK, so this one is repeatable now, and it looks like an
interraction between the ramdisk driver and XFS.

        2 way SMP 1400 with 1Gb memory, 
        SCSI disk. 
        t-o-t kernel, kio _not_ enabled.
        
setup:

        mkfs -t xfs -f /dev/sdc5

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: steve lord <lord@xxxxxxx>
Date: Aug 17 2000 07:45:04AM
[pvnews version: 1.71]
==========================

XFS is not really part of the problem here, it is just triggering lots of
I/O.


There appears to be a deadlock between the lru_list_lock and the
io_request_lock.

On the one hand the lru_list_lock does not disable interrupts, so in I/O
can complete whilst it is held. I/O completion functions tend to grab the
io_request_lock.

On the other hand there are queue request functions (rd_request from the
ram disk driver is the example we hit) which end up grabbing the lru_list_lock.
In this case rd_request calls getblk. Since the unplug_device layer holds the
io_request_lock around the request_fn call we have a deadlock.

So either doing anything which touches the lru_list_lock in a request function
is a BUG, or the lru_list_lock should hold off interrupts, or some more complex
fix is needed.

I am not sure if the ram disk driver is an isolated case or one of many 
possible
culprits.

Steve

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