xfs: don't rely on ->total in xfs_alloc_space_available
authorChristoph Hellwig <hch@lst.de>
Thu, 2 Feb 2017 07:55:56 +0000 (08:55 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 4 Feb 2017 08:47:11 +0000 (09:47 +0100)
commite9b77651910722cd74a3936f230366503089bc80
tree65aafa21750e4901a8bc3d65ec4182de9e3a1357
parent6b81365b1e5795578c4aad59a37c15e958cdcdfe
xfs: don't rely on ->total in xfs_alloc_space_available

commit 12ef830198b0d71668eb9b59f9ba69d32951a48a upstream.

->total is a bit of an odd parameter passed down to the low-level
allocator all the way from the high-level callers.  It's supposed to
contain the maximum number of blocks to be allocated for the whole
transaction [1].

But in xfs_iomap_write_allocate we only convert existing delayed
allocations and thus only have a minimal block reservation for the
current transaction, so xfs_alloc_space_available can't use it for
the allocation decisions.  Use the maximum of args->total and the
calculated block requirement to make a decision.  We probably should
get rid of args->total eventually and instead apply ->minleft more
broadly, but that will require some extensive changes all over.

[1] which creates lots of confusion as most callers don't decrement it
once doing a first allocation.  But that's for a separate series.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/xfs/libxfs/xfs_alloc.c