xfs: fix buffer lookup race on allocation failure
authorDave Chinner <dchinner@redhat.com>
Mon, 23 Apr 2012 05:58:45 +0000 (15:58 +1000)
committerBen Myers <bpm@sgi.com>
Mon, 14 May 2012 21:20:41 +0000 (16:20 -0500)
commitfe2429b0966a7ec42b5fe3bf96f0f10de0a3b536
treec19792c758706dd75773319c0c2506878243586c
parentaff3a9edb7080f69f07fe76a8bd089b3dfa4cb5d
xfs: fix buffer lookup race on allocation failure

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@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
fs/xfs/xfs_buf.c