xfs
[Top] [All Lists]

Re: [PATCH 4/4] xfs: fix the logspace waiting algorithm

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 4/4] xfs: fix the logspace waiting algorithm
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 2 Dec 2011 06:51:41 -0500
Cc: xfs@xxxxxxxxxxx, Dave Chinner <dchinner@xxxxxxxxxx>
In-reply-to: <20111201195128.GZ29840@xxxxxxx>
References: <20111128081732.350228200@xxxxxxxxxxxxxxxxxxxxxx> <20111128081925.981681380@xxxxxxxxxxxxxxxxxxxxxx> <20111130235641.GX29840@xxxxxxx> <20111201072149.GA1319@xxxxxxxxxxxxx> <20111201195128.GZ29840@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Dec 01, 2011 at 01:51:28PM -0600, Ben Myers wrote:
> Process A reads from the grant reserve head at 2641 (and there currently is 
> enough space)
> Process B wakes at either 2646 or 2650, in xlog_reserveq_wait, locks, and 
> reads from the grant reserve head (and currently there is enough space)
> Process B removes itself from the list 
> Process A reads from the reservq list and finds it to be empty
> Process A finds that there was enough space at 2646
> Process B returns from xlog_reserveq_wait, unlocks, grants space at 2656, 
> returns
> Process A grants log space at 2656, and returns
> 
> AFAICS there is nothing that prevents these guys from granting the same
> space when you approach free_bytes >= need_bytes concurrently. 
> 
> This lockless stuff is always a mind job for me.  I'll take another look at
> some of the other aspects of the patch.  Even if it doesn't resolve my
> question about the lockless issue, it seems to resolve Chandra's race.

Indeed, I think we have this race.  Then again I I think we had
exactly the same one before, too.  The only way to fix it would be
to do a sort of double cmpxchg that only moves the grant head forward
if it's still in available space vs the tails lsn.

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