xfs: fix off-by-one in inode alloc block reservation calculation
authorBrian Foster <bfoster@redhat.com>
Wed, 26 Aug 2020 21:08:27 +0000 (14:08 -0700)
committerDarrick J. Wong <darrick.wong@oracle.com>
Wed, 26 Aug 2020 21:13:21 +0000 (14:13 -0700)
commit657f101930bc6c5b41bd7d6c22565c4302a80d33
treee32ceef6dbf82cdc80a9543c2c349e9c36db4d14
parent9c516e0e4554e8f26ab73d46cbc789d7d8db664d
xfs: fix off-by-one in inode alloc block reservation calculation

The inode chunk allocation transaction reserves inobt_maxlevels-1
blocks to accommodate a full split of the inode btree. A full split
requires an allocation for every existing level and a new root
block, which means inobt_maxlevels is the worst case block
requirement for a transaction that inserts to the inobt. This can
lead to a transaction block reservation overrun when tmpfile
creation allocates an inode chunk and expands the inobt to its
maximum depth. This problem has been observed in conjunction with
overlayfs, which makes frequent use of tmpfiles internally.

The existing reservation code goes back as far as the Linux git repo
history (v2.6.12). It was likely never observed as a problem because
the traditional file/directory creation transactions also include
worst case block reservation for directory modifications, which most
likely is able to make up for a single block deficiency in the inode
allocation portion of the calculation. tmpfile support is relatively
more recent (v3.15), less heavily used, and only includes the inode
allocation block reservation as tmpfiles aren't linked into the
directory tree on creation.

Fix up the inode alloc block reservation macro and a couple of the
block allocator minleft parameters that enforce an allocation to
leave enough free blocks in the AG for a full inobt split.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
fs/xfs/libxfs/xfs_ialloc.c
fs/xfs/libxfs/xfs_trans_space.h