xfs
[Top] [All Lists]

Re: [PATCH 1/2] xfs: fix xfs_mark_inode_dirty during umount

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 1/2] xfs: fix xfs_mark_inode_dirty during umount
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 1 Sep 2011 08:51:13 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110830072721.GA24364@xxxxxxxxxxxxx>
References: <20110827055731.GA24159@xxxxxxxxxxxxx> <20110827055744.GA28351@xxxxxxxxxxxxx> <20110830062416.GN3162@dastard> <20110830063949.GA19262@xxxxxxxxxxxxx> <20110830072013.GS3162@dastard> <20110830072721.GA24364@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Aug 30, 2011 at 03:27:21AM -0400, Christoph Hellwig wrote:
> On Tue, Aug 30, 2011 at 05:20:13PM +1000, Dave Chinner wrote:
> > Now that may have been true on Irix/MIPS which had strong memory
> > ordering so only compiler barriers were necessary.
> > 
> > However, normally when we talk about ordered memory semantics in
> > Linux, we cannot assume strong ordering - if we have ordering
> > requirements, we have to guarantee ordering by explicit use of
> > memory barriers, right?
> 
> Probably.  But I'm not worried about that so much, it's just timestamps
> we're talking about as the size already has the ilock unlock as full
> barrier, and we're going to kill this code soon anyway.

Fair enough.

Consider it:

Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>

-- 
Dave Chinner
david@xxxxxxxxxxxxx

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