linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Brian Norris <computersforpeace@gmail.com>,
	Jiri Slaby <jslaby@suse.cz>
Subject: [PATCH 3.12 05/38] mtd: blkdevs: fix potential deadlock + lockdep warnings
Date: Tue, 13 Dec 2016 20:52:31 +0100	[thread overview]
Message-ID: <727cf4032ef3da19c28dd0fb11f792ea4203d842.1481658746.git.jslaby@suse.cz> (raw)
In-Reply-To: <15034b96ec06ee859b67c6cd4e3be569a4ef286b.1481658746.git.jslaby@suse.cz>
In-Reply-To: <cover.1481658746.git.jslaby@suse.cz>

From: Brian Norris <computersforpeace@gmail.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream.

Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.

The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.

 -> blktrans_open()
    ->  mutex_lock(&dev->lock);
    ->  mutex_lock(&mtd_table_mutex);

 -> del_mtd_device()
    ->  mutex_lock(&mtd_table_mutex);
    ->  blktrans_notify_remove() -> del_mtd_blktrans_dev()
       ->  mutex_lock(&dev->lock);

This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:

        if (mutex_trylock(&mtd_table_mutex)) {
                mutex_unlock(&mtd_table_mutex);
                BUG();
        }

So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.

Snippets of the lockdep output follow:

  # modprobe -r m25p80
  [   53.419251]
  [   53.420838] ======================================================
  [   53.427300] [ INFO: possible circular locking dependency detected ]
  [   53.433865] 4.3.0-rc6 #96 Not tainted
  [   53.437686] -------------------------------------------------------
  [   53.444220] modprobe/372 is trying to acquire lock:
  [   53.449320]  (&new->lock){+.+...}, at: [<c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
  [   53.457271]
  [   53.457271] but task is already holding lock:
  [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [<c0439994>] del_mtd_device+0x18/0x100
  [   53.471321]
  [   53.471321] which lock already depends on the new lock.
  [   53.471321]
  [   53.479856]
  [   53.479856] the existing dependency chain (in reverse order) is:
  [   53.487660]
  -> #1 (mtd_table_mutex){+.+.+.}:
  [   53.492331]        [<c043fc5c>] blktrans_open+0x34/0x1a4
  [   53.497879]        [<c01afce0>] __blkdev_get+0xc4/0x3b0
  [   53.503364]        [<c01b0bb8>] blkdev_get+0x108/0x320
  [   53.508743]        [<c01713c0>] do_dentry_open+0x218/0x314
  [   53.514496]        [<c0180454>] path_openat+0x4c0/0xf9c
  [   53.519959]        [<c0182044>] do_filp_open+0x5c/0xc0
  [   53.525336]        [<c0172758>] do_sys_open+0xfc/0x1cc
  [   53.530716]        [<c000f740>] ret_fast_syscall+0x0/0x1c
  [   53.536375]
  -> #0 (&new->lock){+.+...}:
  [   53.540587]        [<c063f124>] mutex_lock_nested+0x38/0x3cc
  [   53.546504]        [<c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
  [   53.552606]        [<c043f164>] blktrans_notify_remove+0x7c/0x84
  [   53.558891]        [<c04399f0>] del_mtd_device+0x74/0x100
  [   53.564544]        [<c043c670>] del_mtd_partitions+0x80/0xc8
  [   53.570451]        [<c0439aa0>] mtd_device_unregister+0x24/0x48
  [   53.576637]        [<c046ce6c>] spi_drv_remove+0x1c/0x34
  [   53.582207]        [<c03de0f0>] __device_release_driver+0x88/0x114
  [   53.588663]        [<c03de19c>] device_release_driver+0x20/0x2c
  [   53.594843]        [<c03dd9e8>] bus_remove_device+0xd8/0x108
  [   53.600748]        [<c03dacc0>] device_del+0x10c/0x210
  [   53.606127]        [<c03dadd0>] device_unregister+0xc/0x20
  [   53.611849]        [<c046d878>] __unregister+0x10/0x20
  [   53.617211]        [<c03da868>] device_for_each_child+0x50/0x7c
  [   53.623387]        [<c046eae8>] spi_unregister_master+0x58/0x8c
  [   53.629578]        [<c03e12f0>] release_nodes+0x15c/0x1c8
  [   53.635223]        [<c03de0f8>] __device_release_driver+0x90/0x114
  [   53.641689]        [<c03de900>] driver_detach+0xb4/0xb8
  [   53.647147]        [<c03ddc78>] bus_remove_driver+0x4c/0xa0
  [   53.652970]        [<c00cab50>] SyS_delete_module+0x11c/0x1e4
  [   53.658976]        [<c000f740>] ret_fast_syscall+0x0/0x1c
  [   53.664621]
  [   53.664621] other info that might help us debug this:
  [   53.664621]
  [   53.672979]  Possible unsafe locking scenario:
  [   53.672979]
  [   53.679169]        CPU0                    CPU1
  [   53.683900]        ----                    ----
  [   53.688633]   lock(mtd_table_mutex);
  [   53.692383]                                lock(&new->lock);
  [   53.698306]                                lock(mtd_table_mutex);
  [   53.704658]   lock(&new->lock);
  [   53.707946]
  [   53.707946]  *** DEADLOCK ***

Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount")
Reported-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/mtd/mtd_blkdevs.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 32d5e40c6863..48b63e849067 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -198,8 +198,8 @@ static int blktrans_open(struct block_device *bdev, fmode_t mode)
 	if (!dev)
 		return -ERESTARTSYS; /* FIXME: busy loop! -arnd*/
 
-	mutex_lock(&dev->lock);
 	mutex_lock(&mtd_table_mutex);
+	mutex_lock(&dev->lock);
 
 	if (dev->open)
 		goto unlock;
@@ -223,8 +223,8 @@ static int blktrans_open(struct block_device *bdev, fmode_t mode)
 
 unlock:
 	dev->open++;
-	mutex_unlock(&mtd_table_mutex);
 	mutex_unlock(&dev->lock);
+	mutex_unlock(&mtd_table_mutex);
 	blktrans_dev_put(dev);
 	return ret;
 
@@ -234,8 +234,8 @@ error_release:
 error_put:
 	module_put(dev->tr->owner);
 	kref_put(&dev->ref, blktrans_dev_release);
-	mutex_unlock(&mtd_table_mutex);
 	mutex_unlock(&dev->lock);
+	mutex_unlock(&mtd_table_mutex);
 	blktrans_dev_put(dev);
 	return ret;
 }
@@ -247,8 +247,8 @@ static void blktrans_release(struct gendisk *disk, fmode_t mode)
 	if (!dev)
 		return;
 
-	mutex_lock(&dev->lock);
 	mutex_lock(&mtd_table_mutex);
+	mutex_lock(&dev->lock);
 
 	if (--dev->open)
 		goto unlock;
@@ -262,8 +262,8 @@ static void blktrans_release(struct gendisk *disk, fmode_t mode)
 		__put_mtd_device(dev->mtd);
 	}
 unlock:
-	mutex_unlock(&mtd_table_mutex);
 	mutex_unlock(&dev->lock);
+	mutex_unlock(&mtd_table_mutex);
 	blktrans_dev_put(dev);
 }
 
-- 
2.11.0

  parent reply	other threads:[~2016-12-13 20:05 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161213195251epcas5p33cd25dd883c71a35fd9cdec0b8e8254a@epcas5p3.samsung.com>
2016-12-13 19:52 ` [PATCH 3.12 00/38] 3.12.69-stable review Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 01/38] x86/idle: Restore trace_cpu_idle to mwait_idle() calls Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 02/38] PCI: Fix devfn for VPD access through function 0 Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 03/38] PCI: Use function 0 VPD for identical functions, regular VPD for others Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 04/38] i2c: at91: fix write transfers by clearing pending interrupt first Jiri Slaby
2016-12-13 19:52   ` Jiri Slaby [this message]
2016-12-13 19:52   ` [PATCH 3.12 06/38] kernel/panic.c: turn off locks debug before releasing console lock Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 07/38] tty: audit: Fix audit source Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 08/38] Revert "drivers/net: Disable UFO through virtio" Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 09/38] KVM: x86: drop error recovery in em_jmp_far and em_ret_far Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 10/38] usb: chipidea: move the lock initialization to core file Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 11/38] USB: serial: cp210x: add ID for the Zone DPMX Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 12/38] USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 13/38] Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 14/38] scsi: mpt3sas: Fix secure erase premature termination Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 15/38] tile: avoid using clocksource_cyc2ns with absolute cycle count Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 16/38] cfg80211: limit scan results cache size Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 17/38] apparmor: fix change_hat not finding hat after policy replacement Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 18/38] mpi: Fix NULL ptr dereference in mpi_powm() [ver #3] Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 19/38] drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 20/38] x86/traps: Ignore high word of regs->cs in early_fixup_exception() Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 21/38] rcu: Fix soft lockup for rcu_nocb_kthread Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 22/38] PCI: Export pcie_find_root_port Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 23/38] mwifiex: printk() overflow with 32-byte SSIDs Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 24/38] pwm: Fix device reference leak Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 25/38] ipv6: Set skb->protocol properly for local output Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 26/38] ipv4: " Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 27/38] ALSA: pcm : Call kill_fasync() in stream lock Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 28/38] ip6_tunnel: disable caching when the traffic class is inherited Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 29/38] net: sky2: Fix shutdown crash Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 30/38] l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind() Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 31/38] net/sched: pedit: make sure that offset is valid Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 32/38] net/dccp: fix use-after-free in dccp_invalid_packet Jiri Slaby
2016-12-13 19:52   ` [PATCH 3.12 33/38] packet: fix race condition in packet_set_ring Jiri Slaby
2016-12-13 19:53   ` [PATCH 3.12 34/38] net: avoid signed overflows for SO_{SND|RCV}BUFFORCE Jiri Slaby
2016-12-13 19:53   ` [PATCH 3.12 35/38] net: ping: check minimum size on ICMP header length Jiri Slaby
2016-12-13 19:53   ` [PATCH 3.12 36/38] sparc32: Fix inverted invalid_frame_pointer checks on sigreturns Jiri Slaby
2016-12-13 19:53   ` [PATCH 3.12 37/38] sparc64: Fix find_node warning if numa node cannot be found Jiri Slaby
2016-12-13 19:53   ` [PATCH 3.12 38/38] sparc64: fix compile warning section mismatch in find_node() Jiri Slaby
2016-12-14  0:51   ` [PATCH 3.12 00/38] 3.12.69-stable review Shuah Khan
2016-12-17  9:10     ` Jiri Slaby
2016-12-14  3:42   ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=727cf4032ef3da19c28dd0fb11f792ea4203d842.1481658746.git.jslaby@suse.cz \
    --to=jslaby@suse.cz \
    --cc=computersforpeace@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).