CHROMIUM: Fix mismatched mutex_unlock in swapon()

This change fixes the lockdep splat (when CONFIG_LOCKDEP=y and
CONFIG_DEBUG_MUTEXES=y) that happens when "swapon file" is ran:

 ------------[ cut here ]------------
 WARNING: CPU: 1 PID: 676 at kernel/locking/lockdep.c:3382 lock_release+0x2a1/0x630()
 DEBUG_LOCKS_WARN_ON(depth <= 0)
 CPU: 1 PID: 676 Comm: swapon Not tainted 4.4.70-xfstests-09717-g45af45ae8cb0 #1
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  0000000000000000 ffff88007ac2bce8 ffffffff814b384c ffff88007ac2bd30
  ffffffff819b4eb0 ffff88007ac2bd20 ffffffff81077571 ffff88007b24e760
  ffffffff81187ad3 ffff88007ac2be28 ffffffff81d2a5d8 ffff88007b7b87c0
 Call Trace:
  [<ffffffff814b384c>] dump_stack+0x85/0xc9
  [<ffffffff81077571>] warn_slowpath_common+0x81/0xc0
  [<ffffffff81187ad3>] ? SyS_swapon+0xc73/0xf30
  [<ffffffff8107762c>] warn_slowpath_fmt+0x4c/0x50
  [<ffffffff810415b5>] ? kvm_clock_read+0x25/0x30
  [<ffffffff810c9bf1>] lock_release+0x2a1/0x630
  [<ffffffff810a9fe1>] ? sched_clock_cpu+0x91/0xb0
  [<ffffffff81187164>] ? SyS_swapon+0x304/0xf30
  [<ffffffff816f8073>] __mutex_unlock_slowpath+0x43/0x3c0
  [<ffffffff816f8402>] mutex_unlock+0x12/0x20
  [<ffffffff81187ad3>] SyS_swapon+0xc73/0xf30
  [<ffffffff816ff207>] ? int_ret_from_sys_call+0x52/0x9f
  [<ffffffff81001017>] ? trace_hardirqs_on_thunk+0x17/0x19
  [<ffffffff816ff072>] entry_SYSCALL_64_fastpath+0x12/0x76
 ---[ end trace 04cc26a572ac8e68 ]---

In upstream kernel, claim_swapfile() does and unconditional
mutex_lock(&inode->i_mutex) when inode is a regular file. This mutex is
then unlocked in swapon() function's return path. On ChromiumOS though,
since the mutex_lock() is compiled out or disabled by sysctl, the
corresponding mutex_unlock() generates the splat.
The presence of sysctl_disk_based_swap makes it tricky because the
sysctl value may change (in theory) between claim_swapfile() and
the swapon() exit path.
To fix this, instead of compiling out the upstream code, we add a check
for the sysctl value (which is 0 by default) at the beginning of the
swapon() function  and do a proper mutex lock/unlock in all cases.

TEST=Following steps reproduced the issue:
  $ dd if=/dev/zero of=/swapfile count=1000 bs=4096
  $ mkswap -U <uuid> /swapfile
  $ swapon /swapfile
After the patch, there is no warning.

Change-Id: I81aac1c07bfbad142b699b05a4136251e78b2f71
Commit-Ready: Aditya Kali <>
Tested-by: Aditya Kali <>
Reviewed-by: Guenter Roeck <>
1 file changed