From: Hugh Dickins Date: Tue, 18 Aug 2015 00:34:27 +0000 (-0700) Subject: mm: fix potential data race in SyS_swapon X-Git-Tag: omap-for-v4.3/fixes-rc1~80^2~3 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=6f179af88f60b32c2855e7f3e16ea8e336a7043f;p=pandora-kernel.git 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 [] SyS_swapon+0x3c0/0x1850 mm/swapfile.c:2345 [] 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 Signed-off-by: Hugh Dickins Signed-off-by: Al Viro --- Reading git-diff-tree failed