summaryrefslogtreecommitdiffstats
path: root/crypto/aead.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2011-12-01 11:24:20 +0000
committerBen Myers <bpm@sgi.com>2011-12-02 16:24:02 -0600
commita99ebf43f49f4499ab0e2a8a9132ad6ed6ba2409 (patch)
tree6dba4c8cacee04e8b507f77fd547bab7a23063ac /crypto/aead.c
parent4c393a6059f8442a70512a48ce4639b882b6f6ad (diff)
downloadop-kernel-dev-a99ebf43f49f4499ab0e2a8a9132ad6ed6ba2409.zip
op-kernel-dev-a99ebf43f49f4499ab0e2a8a9132ad6ed6ba2409.tar.gz
xfs: fix allocation length overflow in xfs_bmapi_write()
When testing the new xfstests --large-fs option that does very large file preallocations, this assert was tripped deep in xfs_alloc_vextent(): XFS: Assertion failed: args->minlen <= args->maxlen, file: fs/xfs/xfs_alloc.c, line: 2239 The allocation was trying to allocate a zero length extent because the lower 32 bits of the allocation length was zero. The remaining length of the allocation to be done was an exact multiple of 2^32 - the first case I saw was at 496TB remaining to be allocated. This turns out to be an overflow when converting the allocation length (a 64 bit quantity) into the extent length to allocate (a 32 bit quantity), and it requires the length to be allocated an exact multiple of 2^32 blocks to trip the assert. Fix it by limiting the extent lenth to allocate to MAXEXTLEN. Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Ben Myers <bpm@sgi.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'crypto/aead.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud