]> git.proxmox.com Git - mirror_ubuntu-artful-kernel.git/commit
xfs: sync eofblocks scans under iolock are livelock prone
authorBrian Foster <bfoster@redhat.com>
Sat, 28 Jan 2017 07:22:56 +0000 (23:22 -0800)
committerStefan Bader <stefan.bader@canonical.com>
Fri, 21 Apr 2017 08:11:10 +0000 (10:11 +0200)
commit3f9fa4ab51d4f5324fe4239c8a1729e8ecc1dd52
treed90aed74d23fa9cc30177ce52fba45b83990c121
parenta71eaa387bdff26ac0486a990bcaa9429a3e7b80
xfs: sync eofblocks scans under iolock are livelock prone

BugLink: http://bugs.launchpad.net/bugs/1681875
commit c3155097ad89a956579bc305856a1f2878494e52 upstream.

The xfs_eofblocks.eof_scan_owner field is an internal field to
facilitate invoking eofb scans from the kernel while under the iolock.
This is necessary because the eofb scan acquires the iolock of each
inode. Synchronous scans are invoked on certain buffered write failures
while under iolock. In such cases, the scan owner indicates that the
context for the scan already owns the particular iolock and prevents a
double lock deadlock.

eofblocks scans while under iolock are still livelock prone in the event
of multiple parallel scans, however. If multiple buffered writes to
different inodes fail and invoke eofblocks scans at the same time, each
scan avoids a deadlock with its own inode by virtue of the
eof_scan_owner field, but will never be able to acquire the iolock of
the inode from the parallel scan. Because the low free space scans are
invoked with SYNC_WAIT, the scan will not return until it has processed
every tagged inode and thus both scans will spin indefinitely on the
iolock being held across the opposite scan. This problem can be
reproduced reliably by generic/224 on systems with higher cpu counts
(x16).

To avoid this problem, simplify the semantics of eofblocks scans to
never invoke a scan while under iolock. This means that the buffered
write context must drop the iolock before the scan. It must reacquire
the lock before the write retry and also repeat the initial write
checks, as the original state might no longer be valid once the iolock
was dropped.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
fs/xfs/xfs_file.c
fs/xfs/xfs_icache.c
fs/xfs/xfs_icache.h