diff options
author | Hugh Dickins <hughd@google.com> | 2015-08-17 17:34:27 -0700 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2015-08-21 02:33:07 -0400 |
commit | 6f179af88f60b32c2855e7f3e16ea8e336a7043f (patch) | |
tree | 7cf9a4aedd37c273a4318924080fdd154e601f66 /fs | |
parent | 061f98e959ea025a5d87c3e089d59ec2ec5f5d6d (diff) | |
download | op-kernel-dev-6f179af88f60b32c2855e7f3e16ea8e336a7043f.zip op-kernel-dev-6f179af88f60b32c2855e7f3e16ea8e336a7043f.tar.gz |
mm: fix potential data race in SyS_swapon
While running KernelThreadSanitizer (ktsan) on upstream kernel with
trinity, we got a few reports from SyS_swapon, here is one of them:
Read of size 8 by thread T307 (K7621):
[< inlined >] SyS_swapon+0x3c0/0x1850 SYSC_swapon mm/swapfile.c:2395
[<ffffffff812242c0>] SyS_swapon+0x3c0/0x1850 mm/swapfile.c:2345
[<ffffffff81e97c8a>] ia32_do_call+0x1b/0x25
Looks like the swap_lock should be taken when iterating through the
swap_info array on lines 2392 - 2401: q->swap_file may be reset to
NULL by another thread before it is dereferenced for f_mapping.
But why is that iteration needed at all? Doesn't the claim_swapfile()
which follows do all that is needed to check for a duplicate entry -
FMODE_EXCL on a bdev, testing IS_SWAPFILE under i_mutex on a regfile?
Well, not quite: bd_may_claim() allows the same "holder" to claim the
bdev again, so we do need to use a different holder than "sys_swapon";
and we should not replace appropriate -EBUSY by inappropriate -EINVAL.
Index i was reused in a cpu loop further down: renamed cpu there.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions