xfs
[Top] [All Lists]

Re: ASSERT trip in XFS

To: Steve Lord <lord@xxxxxxx>
Subject: Re: ASSERT trip in XFS
From: Andi Kleen <ak@xxxxxxx>
Date: Mon, 22 Jan 2001 23:14:30 +0100
Cc: Andi Kleen <ak@xxxxxxx>, Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <200101222208.f0MM85M18074@xxxxxxxxxxxxxxxxxxxx>; from lord@xxxxxxx on Mon, Jan 22, 2001 at 04:08:05PM -0600
References: <ak@xxxxxxx> <200101222208.f0MM85M18074@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Mon, Jan 22, 2001 at 04:08:05PM -0600, Steve Lord wrote:
> > On Mon, Jan 22, 2001 at 02:50:16PM -0600, Steve Lord wrote:
> > > Daniel, can you try this patch, I do not have a sure fire way of
> > > triggering this problem on my hardware. The problem appears to be
> > > related to locking differences between Irix and Linux (again), the
> > > strategy call in Irix is called with the buffer locked for the
> > > duration, which means no one can change the underlying extents.
> > > In the Linux case we have one page locked, and anything else in
> > > the system can truncate the file out underneath us - we end up
> > > allocating a new extent from scratch rather than turning a delalloc
> > > into a real extent, this causes the extent to trip.
> > 
> > If you can get the linux inode semaphore it'll stop the truncates.
> 
> And deadlock when this code is callout out of a system call which already
> has the inode lock....
> 
> I think this one is nasty!

When the inode lock is already held there are no truncates to race. 

When it is not gotten by all calling paths I guess you can just change the 
callers to aquire it first. 

-Andi


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