From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 7C2EB2F747A for ; Sat, 22 Aug 2026 02:38:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787366313; cv=none; b=gArZQK+1sH8uQAxUnUMSw2j1TQLxnpxn4SXKfYSBAOmXmJFPNCLa3sC18iDsb8dJCMxbGGwt0+mK/OqkOd9+gzc66DkOsMRENwoUHYPaX0MxukJJQMDhTqUa2VqL49VFMXDz6WqtwtqMrfJXhIbMdOoTu2CC4mQ7PHYmvmRLPHA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787366313; c=relaxed/simple; bh=iMsjz4Gp3g1m7M6SWtUsr74yDWZUN6anjVASU4yOVOw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H4A/7AVQjSF5N4LTv6G0ozEMyY0kRh6SNLJT5O5Q/pavo4kYB0B9RbCxFNnvFpXq5u9J86Z0iKDyPp3S1WQ/t8Ot5jCjkv6XYkl5Upjo9m/OMup5kRxhGFWIMA53w3KdQuqq0hAP/6UIQx1GIKy1CaVpU52TGYwGpDH8UnfKRmY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=RYKaC1Mg; arc=none smtp.client-ip=209.85.222.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="RYKaC1Mg" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-92edb12cdf2so115165085a.3 for ; Fri, 21 Aug 2026 19:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1787366310; x=1787971110; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=d1MJAMQ0wPBWoJaXmcehdZ4Td5AEjGOctgiLXWnFhiM=; b=RYKaC1MggU2vKbbxbwCW4o2RRTc2VUCIrAhX11eWVx7s/4XN7d+opZBk1CpfIs4oKq SV3hkvbdRIKGy8y6yYpzdF8N9mjnWxatA20SzDapsKxeTK09PRb/8/7lLVHoeiNUS6HG saLzN0UcNdyBbPIyjEHNgtPxhMN27LPodGvn5qpDE0iNc0b7FGLvapk7wm9YBXbB+DGZ K4VN9iuOhRl0d9ZtPj1Nm4SZcwmspP968syX8niBCqzd/ms6b08ZgFo8jzZwsD5lwu/u YJdcawvjhnJrMzyqZdhjsR3dUvw7pSIscXobkkx3ANcffiFysC/1Yf3w7uWeFEDbbNDx 3U0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787366310; x=1787971110; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=d1MJAMQ0wPBWoJaXmcehdZ4Td5AEjGOctgiLXWnFhiM=; b=JFTT4THLbxQA4SYjkE2utKEc3OSXWFvWmtZyublnWXQHoC8LHhyHapXfhOR1xyySid /Vkp2WIO08l3G0yMQAxTPx5XjOevBA164fkEL+Bq1uNPxcqXAwjnY4k8g8ywK93s4dEc 2+ofMBbRThMVDu04tPTLE65ahy4j8Zd6MVlluXuFhqyF6SubtcvHQP/8hWqHODGcvCYu sfHlaqCv/4V9U1pMLGWBMVL+g2VUbj1/na2rslCccPDZ3KZxUf/iQnBQZdSe/5tlfAd5 yWi88i4QmyokzBNzAAe4tqg7XMWL1f2jDmYYrbr5gDuQ9zd1+jRdAk4+k3WU34UT2tHm kYtA== X-Forwarded-Encrypted: i=1; AHgh+Rq9Tmp0akVoTbLotijlsUAPw27RBQJWASQ3/g1OTCTaCL/y86cbJ6hKLJCgGGE8oZSFxydwSZzrH2dFHxw=@vger.kernel.org X-Gm-Message-State: AFuF++ncZb/e/LR4V1qfeBxL91e1LEQI4GR6lfe88FOqsLNxx2qNGWIO cGnJuQqrWxntlXFhD5NNVK1KFfosiB7/P1UirnGBT6AKR/5B+q9fN2z77f9kTQj/dA== X-Gm-Gg: AR+sD13PDk+5YDCHFuwhx4Jc2ekqTe7snE8aqe+t9hhZpKbs9/XeYYaK45VuCGG3lC6 yvyoQoho6X2eGbW451XexBPqL1yWGsv/SdfimUAM/VH2aqtMQrPCeIZ0GL/a1j6cEM2eEFcKH1o P1ohdRl/4qFkEcPjYHWpSf/IKhMSBp1BmLuKeN8yHln3EDBwt3jhXt4sX90ezJPyjIJtEZYE8Ou ZZT+1whF4BFK0PG2fUW+idyPNBEC0lTnv9xUFBGlWJjknCdQnVhVyy9LITmx1vsv564CezO8Nh5 9LR9nPSYSHYAEZrtHwQBqN6AP9Zk8VPylXwoCftxZ9QtbUWoXrbxsrDfVo6YVCs/JwDQTOxr5hF gW8QsiGaJpMzSpslYUjVcf5MNAGWRiEUaVsRzPmWa3ND3Z2mNJTlmw/2HASLeDm/s/Era606/mP zwYjXCaleGxq/uLFqIXiK+OgflvlDJRQmc1caU5k1ti/RkFbKznpgSS7FpwjgLYBjzvrnCYcW/c w== X-Received: by 2002:a05:620a:2591:b0:92e:76a1:96d3 with SMTP id af79cd13be357-93739576a0emr969019385a.34.1787366310149; Fri, 21 Aug 2026 19:38:30 -0700 (PDT) Received: from rowland.harvard.edu ([2601:19b:d01:d210::dfd8]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93749adef4csm43266885a.11.2026.08.21.19.38.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 19:38:29 -0700 (PDT) Date: Fri, 21 Aug 2026 22:38:26 -0400 From: Alan Stern To: Michal Pecio Cc: Mathias Nyman , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] usb: xhci: Fix isochronous scheduling regression Message-ID: References: <20260821114706.34b095b1.michal.pecio@gmail.com> <327f6412-5d07-4bee-a51c-06f1ce5823e6@rowland.harvard.edu> <20260821180350.3648f011.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-Disposition: inline In-Reply-To: <20260821180350.3648f011.michal.pecio@gmail.com> On Fri, Aug 21, 2026 at 06:03:50PM +0200, Michal Pecio wrote: > On Fri, 21 Aug 2026 10:44:07 -0400, Alan Stern wrote: > > Maybe it's time to correct the hcd_periodic_completion_in_progress() > > implementation. > > > > For instance, we could add an atomic giveback_count field to the > > usb_host_endpoint struct. The HCD would increment the field (while > > still holding its private lock) before doing a giveback, and > > __usb_hcd_giveback_urb() would decrement the field after calling the > > completion handler. > > > > What do you think? > > I would go as far as incrementing it on successful usb_submit_urb() and > completely doing away with those list_empty(td_list) checks in HCDs. > > I wrote an xhci-only (less compilation and module reloading) prototype > which relies on hijacking completions of isoc URBs for counting, it > worked, results identical as with the standard solution in a few test > runs with snd-usb-audio. > > Theoretical race condition: it seems we can't prevent new submissions > after completion releases its lock and class driver considers the pipe > idle, but before the counter is decremented to zero. That would be > another case of "scheduling to the past" unexpectedly. > > Seems low probability, but this type of bug hasn't existed so far, we > generally have the opposite problem. > > Or does it exist in non-BH HCDs? It does. It's impossible for a non-BH HCD to reacquire its private lock exactly when the completion handler returns, so somewhere around that time the class driver and the HCD will inevitably have differing opinions about whether the iso queue is empty. > Maybe the documented API guarantee just isn't feasible? I'm not averse to your proposed solution. As for that race, just update the API documentation to take it into account. Seriously -- it's an unavoidable defect and that's all we can do about it. Possible alternative: Make the URB_ISO_ASAP flag take precedence over the "queue is non-empty" condition. > Entirely out of the box alternative: new URB flag. And really, if > only xhci-hcd existed, it wouldn't be hard to even implement explicit > start_frame requests or hints as MOTU wished for, which would make > the whole business of starting synchronized endpoints cleaner. Yes. Something like an URB_USE_START_FRAME flag. It wouldn't help much for starting a single endpoint, but it would allow drivers to synchronize new iso streams with existing ones more easily. (Although there would be a little uncertainty in cases where the schedules for the two streams don't have the same phase.) Alan Stern