xfs
[Top] [All Lists]

Re: [PATCH v2] xfs: re-enable xfsaild idle mode and fix associated races

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH v2] xfs: re-enable xfsaild idle mode and fix associated races
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Wed, 20 Jun 2012 11:59:58 -0400
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20120620080523.GA26167@xxxxxxxxxxxxx>
References: <1339087793-45731-1-git-send-email-bfoster@xxxxxxxxxx> <20120620080523.GA26167@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
On 06/20/2012 04:05 AM, Christoph Hellwig wrote:
> On Thu, Jun 07, 2012 at 12:49:53PM -0400, Brian Foster wrote:
[snip]
>>      spin_lock(&ailp->xa_lock);
>> +
>> +    /* barrier matches the xa_target update in xfs_ail_push() */
>> +    smp_rmb();
>> +    target = ailp->xa_target;
>> +    ailp->xa_target_prev = target;
>> +
>>      lip = xfs_trans_ail_cursor_first(ailp, &cur, ailp->xa_last_pushed_lsn);
>>      if (!lip) {
>>              /*
>> +
>> +            spin_lock(&ailp->xa_lock);
>> +
>> +            /*
>> +             * Idle if the AIL is empty and we are not racing with a target
>> +             * update. The barrier matches the xa_target update in
>> +             * xfs_ail_push().
>> +             */
>> +            smp_rmb();
> 
> Given that both sides are under xa_lock I can't see any need for
> barriers here.
> 

Actually now that I look at it, it appears xfs_trans_ail_copy_lsn() does
not necessarily acquire the xa_lock...

Brian

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