[PATCH 06/18] xfs: fix buffer lookup race on allocation failure

Mark Tinguely tinguely at sgi.com
Fri Apr 13 13:32:27 CDT 2012


On 04/13/12 07:10, Dave Chinner wrote:
> From: Dave Chinner<dchinner at redhat.com>
>
> When memory allocation fails to add the page array or tht epages to
> a buffer during xfs_buf_get(), the buffer is left in the cache in a
> partially initialised state. There is enough state left for the next
> lookup on that buffer to find the buffer, and for the buffer to then
> be used without finishing the initialisation.  As a result, when an
> attempt to do IO on the buffer occurs, it fails with EIO because
> there are no pages attached to the buffer.
>
> We cannot remove the buffer from the cache immediately and free it,
> because there may already be a racing lookup that is blocked on the
> buffer lock. Hence the moment we unlock the buffer to then free it,
> the other user is woken and we have a use-after-free situation.
>
> To avoid this race condition altogether, allocate the pages for the
> buffer before we insert it into the cache.  This then means that we
> don't have an allocation  failure case to deal after the buffer is
> already present in the cache, and hence avoid the problem
> altogether.  In most cases we won't have racing inserts for the same
> buffer, and so won't increase the memory pressure allocation before
> insertion may entail.
>
> Signed-off-by: Dave Chinner<dchinner at redhat.com>
> ---



Much simpler idea than v1. Looks good.

Reviewed-by: Mark Tinguely <tinguely at sgi.com>



More information about the xfs mailing list