summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_buf.h
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2012-04-23 15:58:45 +1000
committerBen Myers <bpm@sgi.com>2012-05-14 16:20:41 -0500
commitfe2429b0966a7ec42b5fe3bf96f0f10de0a3b536 (patch)
treec19792c758706dd75773319c0c2506878243586c /fs/xfs/xfs_buf.h
parentaff3a9edb7080f69f07fe76a8bd089b3dfa4cb5d (diff)
downloadlinux-fe2429b0966a7ec42b5fe3bf96f0f10de0a3b536.tar.bz2
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>
Diffstat (limited to 'fs/xfs/xfs_buf.h')
0 files changed, 0 insertions, 0 deletions