From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D04836CE1C for ; Thu, 11 Jun 2026 07:45:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781163933; cv=none; b=dHdlb9TEErFBNY58lFuhBjNG3BYIVrv7Zu/mij/77ZAnTLUGHSFGNZrSnTLvP1tnBWc0pPi20asmY7oPqYuUI0Hx70BPQNDC5Amm+JHl3yRilS1GseBsxkM2YCHSZhLZLqn/xCngkbQI5vjNFcBMfqNUYY9PoTQAOEVpQQ67CH8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781163933; c=relaxed/simple; bh=EeqvxCYnw6GV7y+HJKrDtOgUluAvuQPzKioN0/kgh24=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mNpvgghy4km/lhRVFWfGmf2xyzs2kBk4M0r5G17/n8mnIA8DfsG/zU7S5HDZOFV7kViZiCrYrijx+1zOEBxhpaI4sw1/W7Cg6Y+JH2d+EXviHYjBsKi1oIkyzMjEm9g9CAj4ismtAj8GDMdK+99YfK3PFYzwtAdy62iNIFns6LM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ckvZ1c1A; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ckvZ1c1A" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-490aaeabdb4so50256085e9.1 for ; Thu, 11 Jun 2026 00:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781163931; x=1781768731; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=m+pdU/2xYGtVNlhmNXrvLedL4csiDA0+5sDvudpgSF0=; b=ckvZ1c1A/CVvgsefnx4wGERA7IZ/1WOg3JsTguKdD+GWwmJpoU3F/3s8Wrg6jDn1ts YTLJP+zeawOmv7wLW250iIuON/WvRcUG7m9z4iC4roBT8apy0C43ECRVkv+bk204Wc4q qBCuU10aWgb7iRcZYik7uzgIMkVPKup6IeOtb2tC3ks795iFjDIjfgQ+iESf3UqmZBID 9ib7xhgPxtUoHimejQABiRiXiZ2PMfHxA+AviaamI3Oo8W2QJcVbhjlUYfGBULNS2hXD sXHuVNl8eVCw7/flywh62/1QPRg/VFCDktPQmMt8BmozBuLT/CsPE4nYTnXAKK0GVQoe byrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781163931; x=1781768731; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=m+pdU/2xYGtVNlhmNXrvLedL4csiDA0+5sDvudpgSF0=; b=nXH9UQzIZMIM7QpeuWnWjXChNOEUoD9NLw5ioMM3/svXS8AuJwRx43Rr4Xc2Wc1aLu 4yvYlBiF5yVy2kUwJO/w2uw083BOyuYNW3YfdXnGHRg1WPz89yZzTKmM+xoKDVFhHXsC 8bzHv1ZXDO9ScJQpsEd2MphASrqAvCOK2tYpBd/KJKNZLi58cqUZRl2KQ7bNk3YLrZYw x3XpucN4Rd/PFqYhtkOfQZI0puGY0jJxB2OtUK8Nykey7obuFEs8p37uMi6zQzhUAS40 6vptUxGO5KerdAXix/x9sOjIoKbKXNCcFe746m6BkR4QjGzwUShyaCdITZAbp5LTHYsr tW0Q== X-Forwarded-Encrypted: i=1; AFNElJ+h2eKmBT7+FSJBDWkvmiGrBAu1PP4/hBEava1lq8zIvRQsWnxIprb8okaTHmEfm94KmRhTItUawgzQviI=@vger.kernel.org X-Gm-Message-State: AOJu0YzYPLeHRGFAXX0iNBBOzBp9e0eMXnHWG8zh/wBXgCiJb5rZl/qh ZJ5DPJjEulMWyNJ1S9poHU0+4BXTBvi/1TV0qu0Mru9+7SDI4AB5NCkR X-Gm-Gg: Acq92OGHRMbKFZLBQ4ZhtgDaZ2tCu8wg1xv8UAuPX3/dwFagslnTh1Jx10knFtwt7zr yOS+3VUWKSPUFCO0cumK5tGWRJClsPPhDnUs1rcW8lEQQ8jIcZPWcAvX4ySMRcacehUnwRXI2uP T8ttoqOPBY9/4UHjSxW4iq6WOJH5v/chpuMTaRWN4F1Yk3LDxWHAjD7PLC8Kw0QyIRi0KRnpqys VeA/wjUxC7X2KNGTblnDCUbhfXyXVCb0OJp4JSAafWkHBVBzyKrD3Epg0p5eaLaaFOpfhdW2HfH lKrKB7sB/l6GrRFNnVRLCthCxH4phKBb34UZu4rzwAewsNqnQhglL3qgIOk11ZgXmqqUvei5wP6 KhlCyjNeKt/ksXCGplyZ0PGrA1uItbM5xo9qwxOr8NAaIGLYr/binF3Q8WPQqAqGdClihPd/x+f YG7LLUvhP9i3kSbPi+eDbdLez4Sl/36A7OoVNCZmQYNpzLiJ81e7FXgQ== X-Received: by 2002:a5d:59af:0:b0:43d:dd:8ca4 with SMTP id ffacd0b85a97d-460675a1335mr2346442f8f.14.1781163930612; Thu, 11 Jun 2026 00:45:30 -0700 (PDT) Received: from foxbook (bgt94.neoplus.adsl.tpnet.pl. [83.28.83.94]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46028a6dcbdsm66097973f8f.7.2026.06.11.00.45.29 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 11 Jun 2026 00:45:30 -0700 (PDT) Date: Thu, 11 Jun 2026 09:45:26 +0200 From: Michal Pecio To: =?UTF-8?B?6IOh6L+e5Yuk?= Cc: Mathias Nyman , Greg Kroah-Hartman , "sarah.a.sharp@linux.intel.com" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] usb: xhci: Fix sleep in atomic context in xhci_free_streams() Message-ID: <20260611094526.2f5ddbba.michal.pecio@gmail.com> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 11 Jun 2026 06:44:14 +0000, =E8=83=A1=E8=BF=9E=E5=8B=A4 wrote: > When a USB device with active stream endpoints is disconnected, > xhci_free_streams() is called from the hub_event workqueue to > free the stream resources while holding xhci->lock with irqs > disabled.=20 Pedantry: it (currently) holds the lock while freeing, but it isn't called with the lock held, nor for the explicit purpose of freeing things with the lock held. Not sure how to parse this sentence? > It calls xhci_free_stream_info(), which invokes > xhci_free_stream_ctx(), which in turn calls dma_free_coherent() > for large stream context arrays. >=20 > dma_free_coherent() can sleep (e.g. via vunmap), triggering > a BUG when called from atomic context. >=20 > Call trace: > dma_free_attrs+0x174/0x220 > xhci_free_stream_info+0xd0/0x11c > xhci_free_streams+0x278/0x37c > usb_free_streams+0x98/0xc0 > usb_unbind_interface+0x1b8/0x2f8 > device_release_driver_internal+0x1d4/0x2cc > device_release_driver+0x18/0x28 > bus_remove_device+0x160/0x1a4 > device_del+0x1ec/0x350 > usb_disable_device+0x98/0x214 > usb_disconnect+0xf0/0x35c > hub_event+0xab4/0x19ec > process_one_work+0x278/0x63c >=20 > Fix this by saving the stream_info pointers and clearing the > ep references under the lock, then calling xhci_free_stream_info() > outside the lock where sleeping is allowed. I wonder if this copy is necessary or if it would suffice to start with calling xhci_free_stream_info() unlocked (EP_GETTING_NO_STREAMS should ensure that nobody submits new URBs and hopefully core won't attempt to re-enable streams concurrently) and then grab the lock only to update vdev->eps stream_info and ep_state fields. Regards, Michal