xfs
[Top] [All Lists]

Re: TAKE - Move XFS out of the interrupt disabling game

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: TAKE - Move XFS out of the interrupt disabling game
From: Stephen Lord <lord@xxxxxxx>
Date: 24 May 2002 06:52:35 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20020524103937.A7333@xxxxxxxxxxxxx>
References: <200205231900.g4NJ0Fn06774@xxxxxxxxxxxxxxxxxxxx> <20020524103937.A7333@xxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Fri, 2002-05-24 at 04:39, Christoph Hellwig wrote:
> On Thu, May 23, 2002 at 02:00:15PM -0500, Steve Lord wrote:
> > linux/fs/xfs/linux/xfs_vfs.c - 1.26
> >     - replace mp_mutex_spinlock with mutex_spinlock
> 
> But both mp_mutex_spinlock and mutex_spinlock aren't right here!
> All other vfslock accesses are using linux native, interrupt-disabling
> spinlock functions.  With the old code this was just an inconsistency,
> but now we sometimes disable interrupts, sometimes not.
> 
> This small patch makes it using the same linux primitives the other
> functions use, but I think it should be save to move to the simple
> spinlock functions everywhere:


Thanks, you are correct (again), I flipped all this code over to
just use spin_lock and spin_unlock. I suspect we can do away with
most of this vfs lock code on linux actually, just a matter of thinking
about it hard enough. It is there on Irix to prevent things happening
to the filesystem (like unmount) during certain operations - and to
make those operations exclusive with unmount.

> 
> 
> Apropos mutex_spinlock:  What is the exact use of this locking primitive?
> The name suggests that it is used in IRIX to spin on a mutex_t on
> contention, but that means it's argument is already very different on
> Linux.  Given that fact I wonder why it is still kept for the few user.

I think the naming comes from it being a spinlock based mutual exclusion
primitive, not that it took a mutex. It is spinlock based on Irix too.

Steve



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