[Top] [All Lists]

Re: [PATCH 06/13] xfs: xfs_sync_data is redundant.

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 06/13] xfs: xfs_sync_data is redundant.
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Tue, 02 Oct 2012 17:13:27 -0400
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20121002205124.GS23520@dastard>
References: <1348807485-20165-1-git-send-email-david@xxxxxxxxxxxxx> <1348807485-20165-7-git-send-email-david@xxxxxxxxxxxxx> <5069F9B0.50804@xxxxxxxxxx> <20121002001021.GJ23520@dastard> <506A38D1.6090204@xxxxxxxxxx> <506AE5AD.60509@xxxxxxxxxx> <20121002205124.GS23520@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
On 10/02/2012 04:51 PM, Dave Chinner wrote:
> On Tue, Oct 02, 2012 at 09:01:33AM -0400, Brian Foster wrote:
>> On 10/01/2012 08:44 PM, Brian Foster wrote:
>>> On 10/01/2012 08:10 PM, Dave Chinner wrote:
>> ...
> I don't think we can do an unconditional down_read() there, as the
> caller from xfs_create() already holds an i_mutex (the VFS holds the
> directory inode lock) and I'm pretty sure that s_umount is supposed
> to be outside per-inode locks.
> Given that where we are called we are inside a transaction for the
> create case, and inside mnt_want_write() protection for the buffered
> write case, the likelyhood of s_umount being held for write at
> ENOSPC is going to be non-existent at these call sites. Hence a
> down_read_trylock() will avoid lock ordering issues, but will almost
> always succeed and so be equivalent to down_read()....


> /me modifies and runs 273 and the enospc xfstests group...
> Seems to work just fine, and no warnings. Patch below.

This passes 273 clean (save the xlog_verify_grant_tail message) for me
as well. Thanks.


> Cheers,
> Dave.

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