linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Mike Galbraith <efault@gmx.de>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	Hans de Goede <hdegoede@redhat.com>, Li Jun <jun.li@nxp.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 3/3] xhci: Don't create stream debugfs files with spinlock held.
Date: Thu, 29 Oct 2020 18:43:48 +0100	[thread overview]
Message-ID: <20201029174348.omqiwjqy64tebg5z@linutronix.de> (raw)
In-Reply-To: <29cf8ca3-0fe7-da51-c8ae-ad5c67af4dde@linux.intel.com>

On 2020-10-29 15:08:06 [+0200], Mathias Nyman wrote:
> 2. Lockdep issue #2, adding entries to radix tree during (stream) ring expansion with interrupts disabled and xhci->lock held.
>    Cause: unknown, probably a patch since we started using radix trees for finding streams
>    Fix: unknown.
>    Comment: Discovered by Mike when testing fix for issue#1. I suspect it can be reproduced on 5.9 but is 
>    probably really hard as it involves ring expansion.

So lockdep complains with this:
      CPU0                    CPU1
      ----                    ----
 lock(lock#2);
                              local_irq_disable();
                              lock(&xhci->lock);
                              lock(lock#2);
 <Interrupt>
   lock(&xhci->lock);

(https://lore.kernel.org/linux-usb/1cbb8b7defb1db1d4747995c11ebebb3dd9a66ec.camel@gmx.de/)

lockdep does not like that preload is used with disabled interrupts (in
non-interrupt context) and acquires lock#2 (the local_lock) which could
lead to a dead-lock as described above.
The flaw in the logic above is that lock#2 on CPU0 != CPU1.

We could make lockdep happy and remove what it observes on CPU1 by doing
this:

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 138ba4528dd3a..2cb8874c1c51f 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -197,12 +197,15 @@ static int xhci_insert_segment_mapping(struct radix_tree_root *trb_address_map,
 	if (radix_tree_lookup(trb_address_map, key))
 		return 0;
 
-	ret = radix_tree_maybe_preload(mem_flags);
-	if (ret)
-		return ret;
-	ret = radix_tree_insert(trb_address_map,
-			key, ring);
-	radix_tree_preload_end();
+	if (gfpflags_allow_blocking(mem_flags)) {
+		ret = radix_tree_maybe_preload(mem_flags);
+		if (ret)
+			return ret;
+	}
+	ret = radix_tree_insert(trb_address_map, key, ring);
+
+	if (gfpflags_allow_blocking(mem_flags))
+		radix_tree_preload_end();
 	return ret;
 }
 

There is no pre-load in GFP_ATOMIC case but it still acquires the
local_lock.
We might be able to drop radix_tree_maybe_preload(). I saw GFP_KERNEL
only during enumeration from xhci_alloc_streams(). Later, while
transfers were pending it came always from the scsi stack with disabled
interrupts and xhci->lock acquired.

> -Mathias

Sebastian

  parent reply	other threads:[~2020-10-29 17:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 20:31 [PATCH 0/3] xhci fixes for usb-linus Mathias Nyman
2020-10-28 20:31 ` [PATCH 1/3] xhci: Fix sizeof() mismatch Mathias Nyman
2020-10-28 20:31 ` [PATCH 2/3] usb: xhci: Workaround for S3 issue on AMD SNPS 3.0 xHC Mathias Nyman
2020-10-28 20:31 ` [PATCH 3/3] xhci: Don't create stream debugfs files with spinlock held Mathias Nyman
2020-10-29  6:03   ` Mike Galbraith
2020-10-29  9:41     ` Mathias Nyman
2020-10-29  9:42       ` Sebastian Andrzej Siewior
2020-10-29 10:23         ` Mike Galbraith
2020-10-29 10:37           ` Sebastian Andrzej Siewior
2020-10-29 11:11       ` Mike Galbraith
2020-10-29 11:22         ` Mathias Nyman
2020-10-29 11:38           ` Sebastian Andrzej Siewior
2020-10-29 12:44             ` Jun Li
2020-10-29 13:08             ` Mathias Nyman
2020-10-29 15:10               ` Sebastian Andrzej Siewior
2020-10-29 16:26               ` David Laight
2020-10-29 17:43               ` Sebastian Andrzej Siewior [this message]
2020-10-30  8:01   ` Jun Li

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=20201029174348.omqiwjqy64tebg5z@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=efault@gmx.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=jun.li@nxp.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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).