From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) (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 6D78B357A48 for ; Tue, 23 Dec 2025 10:06:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484391; cv=none; b=X5eH8j4JEA/MUsjv36c/jAYWn5vKqwi7m9K8u4MxZ9IfwEBNPZOhqpl85b6NIA3m52m2Vc9UP9+7gCF0g3uzsUnVwkNXJ5+RJUPDEWlYYyZZdog8tXjEl8qWOgRAhV9kfEERoNa7HXh1N+IrhzbHHCbovyaSUgtEzzEBhJI/wRQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766484391; c=relaxed/simple; bh=5Fkn+5VzU1zCfX7VhROqZyNQ7AQdJvWc0ebzXz0ZRSs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ORWNHlc+x5fLqra7KNpeu6mWg8HqyXQrqYZiCSZaZ+Cnbl0mt4WdcuPDvhV4euOaU36Di073gcjFOuIvbwEBY/R2G6CJGLHuqitOVm1sW4kuQ7N3Jl0hlwplkBQe2Gc9sViweLSF1PMVvJmBsXJL1zBssIz42eb2qaNhWhDtDvg= 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=faiMMrQl; arc=none smtp.client-ip=209.85.208.49 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="faiMMrQl" Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-6418b55f86dso6497787a12.1 for ; Tue, 23 Dec 2025 02:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766484386; x=1767089186; 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=RRWnjSr0jciI1Z5HoAfkG1mju3Morov9W5gQzuml8Uw=; b=faiMMrQld1T60IJN0TGcyH9Giy49bUZtWs2jBfL0/G3xQ7C1Jm8UDNp5J5A4KjtAtm g27nRL8BrnKzF+dBm1IZ4XWKGz6bko4tC2/QVnsGsa5q/H2cYQRiuevPmsOlhzO7Qj45 54iT89Ha19ekh6ODNmUFM0W0/RWQFxpKzKvi6jsZ08bLNIIpLdgl/RvQK9tqr+xHjYHE tf1pHorecdKomp6cIGtsrAxzFNzx+BwWmVqt/12Oj5AM1PWpHKTzJz0ttICKe9BC2jnT K0tgmDjBuM6RcHv2tw2aLhTg0EjFy7x9tVQ1lZK35fXT0VPAc/3r+qUX/XPezREf+ldh 2LxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766484386; x=1767089186; 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=RRWnjSr0jciI1Z5HoAfkG1mju3Morov9W5gQzuml8Uw=; b=VFn9EYjhsjS4Q3QMu8yHAePp9f8EVN3rfTih0VYVPVjGAlBnkgdCDZJE3liIUxQC9C wIly+8I7xZ6Xb3bdcIwYidhi+KBJwA8vwE3BU+0hqNnR6CuH0Nr0sXzs5M8DLcf11EM3 qSyb96pcgAWENHXCT0pizmwW9xoUuLPJ/jpw/s3apHFKukvXS5dC8NOcJ7p6kNGwmIow +dqs6hrzZyOS9no2mKuAPsOf01QA9GlukbKcfMucGAwHVmf/2jdikI6ug6oVxcV0JY6K vpDAJm51LRKIRIxgeDOoNX0VWVPS7ORwBKLpL9kul0h+kr9caAgJWMHMh/vAZ4TMRU5F nZAw== X-Forwarded-Encrypted: i=1; AJvYcCVOBsBZg/uJhITZMUAY1uE6uRqX1+gte91Az7XDIiylqUWTBC8oZ1ohwaaGMO6yB79daWi3JZjMRS9MB8c=@vger.kernel.org X-Gm-Message-State: AOJu0YzMZ87xYRpn6KTNJfaRGACs1UOGk5y6oxpwD9Jh9MDkPCrGYE/A tqJp199fdg8jingHWxyagObyLHO+aYTVTq0CZLdNcCSIUNc45Eix1A4JUgee8w== X-Gm-Gg: AY/fxX47mU9f8V0ZzbL5cHVS0Ul6tXuR0tZR8YFwEr9VSmW1Ok2YtUPPV0rsmmj6QP6 xM4htAjGUyZLXmFfKkZm3DemukTR4OOOKKM3mW8LtEXvlEURw6R/eLTTeV63Abb+/3P0g3RqLHw RcI/jW4vpbuMJ93lH9H9kDC/rXv9BqDLXEBAFzfRSXkdkyawLBsJjeiBbNy5moR+0Ciyeg6HfCI rGQXTAIG+AcW0wa2ALs285Ut1/Pti3YDGNFi2Ol+c57iEyvgMZeKrM2JQwDp4A8LFaRtXtFjSz8 1JEuG3fHU7dRsBkkFgq+DfMPYuPG3mY4cW+74fhm0ORzSWWSO+3tG5dH+Wn3UV6kIZVdKmXzoQf noMOuIkvOiyJHOReh/MnZRVmBAuZEvcVrlkJL7XRkzl/Gq/Atltjpj/T/LUIZ1U+WaxI39ZGLGJ DqXV7LjLcPEkTObreQloJCKJo= X-Google-Smtp-Source: AGHT+IFu5veOu4SBeNEymO0Qtwjb4692B+3YWX9WqbFNp2m+8exlv+EKlDBSKlCxA2o28x/YCpJO2A== X-Received: by 2002:a17:907:7e85:b0:b73:4006:1875 with SMTP id a640c23a62f3a-b803719ef9amr1225976066b.38.1766484385871; Tue, 23 Dec 2025 02:06:25 -0800 (PST) Received: from foxbook (bfd193.neoplus.adsl.tpnet.pl. [83.28.41.193]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b8037de10dfsm1330374766b.36.2025.12.23.02.06.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 23 Dec 2025 02:06:25 -0800 (PST) Date: Tue, 23 Dec 2025 11:06:21 +0100 From: Michal Pecio To: Alan Stern Cc: =?UTF-8?B?6IOh6L+e5Yuk?= , Greg Kroah-Hartman , Lee Jones , Mathias Nyman , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] usb: xhci: check Null pointer in segment alloc Message-ID: <20251223110621.2b53f63d.michal.pecio@gmail.com> In-Reply-To: References: <20251220141510.1bc1ef19.michal.pecio@gmail.com> <20251222064252.GA1196800@google.com> <2025122253-stopper-tweed-6e68@gregkh> <20251222085543.4d7430d5.michal.pecio@gmail.com> <20251222174934.4c9b62d2.michal.pecio@gmail.com> <38822950-6d69-4ad6-be28-fb8f328c8ae5@rowland.harvard.edu> <20251222220349.2d6c1a43.michal.pecio@gmail.com> 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=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 22 Dec 2025 22:24:35 -0500, Alan Stern wrote: > > I see that devices recursively call bus_resume() before resuming, > > Are you talking about hcd_bus_resume()? (There is no function named > bus_resume() in usbcore.) That's the routine in charge of resuming > root hubs. The PM core ensures that all of a device's ancestors are > at full power before the device is resumed, so it would (indirectly) > call this routine if an entire USB bus was suspended when a resume > was requested for one of the devices on that bus. Yes, I mean this function and the bus_resume() method of the HCD, which the function calls. > I can't see it being an autoresume in that situation, though. An > autoresume is one that was requested by the device itself -- a wakeup > request -- and that can't happen if the HC is suspended. Indeed, the crashing call stack looks like some driver manually resuming a USB device. [ 4021.987702][ T332] usb_hcd_alloc_bandwidth+0x384/0x3e4 [ 4021.987711][ T332] usb_set_interface+0x144/0x510 [ 4021.987716][ T332] usb_reset_and_verify_device+0x248/0x5fc [ 4021.987723][ T332] usb_port_resume+0x580/0x700 [ 4021.987730][ T332] usb_generic_driver_resume+0x24/0x5c [ 4021.987735][ T332] usb_resume_both+0x104/0x32c [ 4021.987740][ T332] usb_runtime_resume+0x18/0x28 [ 4021.987746][ T332] __rpm_callback+0x94/0x3d4 [ 4021.987754][ T332] rpm_resume+0x3f8/0x5fc [ 4021.987762][ T332] rpm_resume+0x1fc/0x5fc [ 4021.987769][ T332] __pm_runtime_resume+0x4c/0x90 [ 4021.987777][ T332] usb_autopm_get_interface+0x20/0x4c [ 4021.987783][ T332] snd_usb_autoresume+0x68/0x124 [ 4021.987792][ T332] suspend_resume_store+0x2a0/0x2b4 [dwc3_msm a4b7997a2e35cfe1a4a429762003b34dd4e85076] Before we got here, we should have attempted an hcd_bus_resume(). If xhci_hcd tracked its HW_ACCESSIBLE state better, that would have failed and hopefully aborted device resume before it crashed. > > this fails with -ESHUTDOWN if the flag is unset, which seems to > > prevent device resume from progressing further and crashing. Is > > this what is meant to happen in such case? > > I'm not sure what code in what routine you're talking about. > However, it's obvious that if the host controller's registers can't > be accessed then no downstream device resume is going to work. If HW_ACCESSIBLE isn't set then xhci_bus_resume() returns -ESHUTDOWN. It always returns zero otherwise. So in the light of your explanation, the fact that xhci_resume() sets HW_ACCESSIBLE before actually completing resume and thus allows root hub resume to pretend to work, is obviously a bug. > > So I guess it's not happening because xhci_resume() sets this flag > > right away and then it may drop the lock and start deallocating > > memory to reset everything. So we can "successfully" complete > > bus_resume() and allow USB devices to resume while HC resume is > > still in progress. > > The root-hub resume (i.e., the ->bus_resume() callback) does not > occur until after the HC's own resume handler returns. If PM core is supposed to prevent it then this is getting weird. If not, then I'm not sure what else can prevent it. > Is it possible that the HC's resume handler decided that the HC was > dead, and so started deallocating stuff, but failed to call > usb_hc_died()? (But note that resume_common() in hcd-pci.c calls > usb_hc_died() automatically on the HCD's behalf when a resume fails.) Hopefully not. xhci->segment_pool is only modified by xhci_mem_cleanup() and by xhci_mem_init() if allocation fails. And those functions are only called at probe time, during HC resume and by hc_driver->stop(). I'm out of ideas without more logs. The xhci HW_ACCESSIBLE bug should be fixed, but I'm not sure about correct ordering of setting this bit wrt some calls done by xhci_resume(), so no patch from me. Regards, Michal