Patch "libnvdimm: band aid btt vs clear poison locking" has been added to the 4.10-stable tree

This is a note to let you know that I've just added the patch titled

libnvdimm: band aid btt vs clear poison locking

to the 4.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
libnvdimm-band-aid-btt-vs-clear-poison-locking.patch
and it can be found in the queue-4.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Dan Williams <[email protected]>
Date: Fri, 7 Apr 2017 12:25:52 -0700
Subject: libnvdimm: band aid btt vs clear poison locking

From: Dan Williams <[email protected]>

commit 4aa5615e080a9855e607accc75b07ab79b252dde upstream.

The following warning results from holding a lane spinlock, preempt_disable(), or the btt map spinlock and then trying to take the reconfig_mutex to walk the poison list and potentially add new entries.

 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
 in_atomic(): 1, irqs_disabled(): 0, pid: 17159, name: dd
 [..]
 Call Trace:
  dump_stack+0x85/0xc8
  ___might_sleep+0x184/0x250
  __might_sleep+0x4a/0x90
  __mutex_lock+0x58/0x9b0
  ? nvdimm_bus_lock+0x21/0x30 [libnvdimm]
  ? __nvdimm_bus_badblocks_clear+0x2f/0x60 [libnvdimm]
  ? acpi_nfit_forget_poison+0x79/0x80 [nfit]
  ? _raw_spin_unlock+0x27/0x40
  mutex_lock_nested+0x1b/0x20
  nvdimm_bus_lock+0x21/0x30 [libnvdimm]
  nvdimm_forget_poison+0x25/0x50 [libnvdimm]
  nvdimm_clear_poison+0x106/0x140 [libnvdimm]
  nsio_rw_bytes+0x164/0x270 [libnvdimm]
  btt_write_pg+0x1de/0x3e0 [nd_btt]
  ? blk_queue_enter+0x30/0x290
  btt_make_request+0x11a/0x310 [nd_btt]
  ? blk_queue_enter+0xb7/0x290
  ? blk_queue_enter+0x30/0x290
  generic_make_request+0x118/0x3b0

As a minimal fix, disable error clearing when the BTT is enabled for the namespace. For the final fix a larger rework of the poison list locking is needed.

Note that this is not a problem in the blk case since that path never calls nvdimm_clear_poison().

---
 drivers/nvdimm/claim.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

@@ -243,7 +243,15 @@ static int nsio_rw_bytes(struct nd_names
 	}
 
 	if (unlikely(is_bad_pmem(&nsio->bb, sector, sz_align))) {
-		if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)) {
+		/*
+		 * FIXME: nsio_rw_bytes() may be called from atomic
+		 * context in the btt case and nvdimm_clear_poison()
+		 * takes a sleeping lock. Until the locking can be
+		 * reworked this capability requires that the namespace
+		 * is not claimed by btt.
+		 */
+		if (IS_ALIGNED(offset, 512) && IS_ALIGNED(size, 512)
+				&& (!ndns->claim || !is_nd_btt(ndns->claim))) {
 			long cleared;
 
 			cleared = nvdimm_clear_poison(&ndns->dev, offset, size);

Patches currently in stable-queue which might be from [email protected] are

queue-4.10/libnvdimm-band-aid-btt-vs-clear-poison-locking.patch queue-4.10/acpi-nfit-libnvdimm-fix-interleave-set-cookie-calculation-64-bit-comparison.patch queue-4.10/libnvdimm-fix-blk-free-space-accounting.patch queue-4.10/x86-pmem-fix-broken-__copy_user_nocache-cache-bypass-assumptions.patch queue-4.10/libnvdimm-fix-reconfig_mutex-mmap_sem-and-jbd2_handle-lockdep-splat.patch