From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (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 2DEDD2931C3 for ; Fri, 21 Aug 2026 16:03:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787328241; cv=none; b=OiB7Q3phPK6tFpbnC+wRNsHpYJYzUrH1Y0f5VCf1UlcR2X/5JjZ0kcBaBcdhuaoEm/VMJR5Ryhk/6kS9SSgy0AjjNm5uRWzj8BWeCAANP7xaD2FNKaHOoAN/o5Lr19kJAhqXWNqlMFk7NPnrNTRHBDZCEQzh8yQG56oDEcRnG4w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787328241; c=relaxed/simple; bh=dVjXaCbpv34VpouvyO/RjpGwp7IuWIhgtoJPQQB92E8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WNtVZ81W5fztXo6zQb/btOMY+wLceYDIVoHzxIcWtsjAFSSMSAqNZ+/UvoKYuarJHHxH6ogdzSVnmR5lagttRPk+8nk65tSsK8UD5D5G6iB/7yiUPyX5IhBnfmvcv+T8FNNTfknKYj1mUTbAbqLjbCZKILD+4hiRcWDHaECeZpA= 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=A6jpQtVy; arc=none smtp.client-ip=209.85.218.42 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="A6jpQtVy" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c15ca7a7ca9so140444066b.0 for ; Fri, 21 Aug 2026 09:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787328238; x=1787933038; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=D0OTJRC2+2m5UgK2WX3qJ3+Vk6ajv1PtJWvl3y3MXZQ=; b=A6jpQtVynGKWCQuHXp5+XKZ41iZ5CnjmrD7Mf5NVA8nfxkEg8zNKC/09NyKRPjqe/d iErhIVscDAHJGyRDvovKoNann0XDd6MUNwM1DIIXNhhpfhG/QPD4a4OQ/QCnDMEOG7Hu pgajWApcUjB6msCEKssezD9gBpop6eow0zb/rCnbyAR79qcidQF4i7w3FSkN+NoWJIqj Bs5JB8BwYoK8GIZl7TffGIzcBz7mcXiP9byxab9mPGJzHzjfYscs/aKNygqJpntguu7I wfy+Uus7m8SHpeC2PIhnDK9wImBZ57m8Jujxb3lKfTYKV5tSAgODTJTEimHuNfkMB3So V67g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787328238; x=1787933038; h=content-transfer-encoding:content-type: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 :content-type; bh=D0OTJRC2+2m5UgK2WX3qJ3+Vk6ajv1PtJWvl3y3MXZQ=; b=W2ij5V3rX0xympN2e2MLJOBKGX7DQwsUw1xPwN7m2jdhFthUQCMsJqnzkZlQ17RVWa 0zqE0PSZfk9RI+TXEgTfwb/BwR7fr5VJu+JZwNM+xjL/1v1LR5/8gQjFxLRjKffBy4U0 WxkyRJzeYRorrbzbeVFfB87WHx13ZAZxnLiTdHv5B+KtsjTOlqhHOr8dTjKXvITQQ4Po rvBF+zKO8o5O0HFFHDCu4G0WwubW3Hog3RYKQhK9BrVv6pslr6TdseZR6WQiRHMovyMQ 8GiMvxcFVzAYvPIT6IXlO/g3TBZEvsLzJbVXcejJAuwfqUk5pICj+151x5vzh3d8nLDi hAAg== X-Forwarded-Encrypted: i=1; AHgh+Rpiv59p7icFTQ6AufxuYzp2luHUoTwmKsy8+3zn/hXC/qG7WeVvhY2rPSjm8+CrGfy/PQkkEvS08B7s/Bs=@vger.kernel.org X-Gm-Message-State: AFuF++lML33oHxbI6OL0obrRDp4k2SUqQRDJYs85hGQ62wOhcZXooul6 Ey+3BgWdzvogDudThBbEjzFi1NCKdWV9sLuaL2yIMzrrdBIuZNdwwOnx X-Gm-Gg: AR+sD13jPLa9dU7gYpewXKbHaMzjmpl5HhqDyebOavYVJ6aeP436853eGJ2PA9ZFtKw F1XOfTGerU/e+j5fQSkqv/820JS2RqntYOPFdzVE1tQ/8FLCISDnsudZxwhlpwJCJfE2goSct4E bdUGaQcked3kfLdvcz6SECOtu2lqUGRc+WaAD/ZkgJeZU7LAQPURaz7M+rd9PU6SPQbMeAsqcNQ mhDTNNTXvH9W3ce7lMxFL8N/fl8Y9MWnjXb73FBi+37QRvMH47HK8h3+8+FcASiDAp8IYJCzP7M WACBV2KwxnY9irP7Wy2erFdVB656ejlP72Pey0PzF9qwC3IVoO4HM7DIN+s9QO8C6YvALVxFtGM jAMSgV10si6eXKKPbscNgDNXiLBKgnKoVc9WB/wmQgVypF8xT77mUNz483V5HXrOST5sO2oC3D5 YJOyYnrOiSO0KwZhJvTEB2KEdTX4Z91aQjiWKQNZZ+zlDDgQH/GvnGENkbHDLdY8UbUOg= X-Received: by 2002:a17:907:3e03:b0:c20:1c9d:8d4b with SMTP id a640c23a62f3a-c246a30c350mr811080666b.2.1787328238214; Fri, 21 Aug 2026 09:03:58 -0700 (PDT) Received: from foxbook (bfg7.neoplus.adsl.tpnet.pl. [83.28.44.7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24589e224dsm547071166b.2.2026.08.21.09.03.56 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 21 Aug 2026 09:03:57 -0700 (PDT) Date: Fri, 21 Aug 2026 18:03:50 +0200 From: Michal Pecio To: Alan Stern 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: <20260821180350.3648f011.michal.pecio@gmail.com> In-Reply-To: <327f6412-5d07-4bee-a51c-06f1ce5823e6@rowland.harvard.edu> References: <20260821114706.34b095b1.michal.pecio@gmail.com> <327f6412-5d07-4bee-a51c-06f1ce5823e6@rowland.harvard.edu> 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 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? Maybe the documented API guarantee just isn't feasible? 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. Regards, Michal