From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (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 7836C25A2A4 for ; Thu, 30 Apr 2026 05:44:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777527889; cv=none; b=ELFb4e+Ye+Zz9MFLrri4hedPapyizyHjR5883aO4DaScFkgzYDKehEnAneFCKVy0uNSA950ITHsXGPlvn/0RBk9d6znx/+8Tx/s4nWDv5EdtigNUHOdImI6OjqFaLXsThBhi59Hplhzmgp7aPI16S9ouj3afK2l7UbYuxHJSXks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777527889; c=relaxed/simple; bh=+zOn1HuPz/QRR2c3ttXpLREXaufzwdHeGeeYYsO4oyo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RGk/d1TsPrcMDOlf7apYFbgvpRnhQhp9H/Gs8GER8/8/TmztQ9UeGkwr46o8+hdJabCjYe5R4qv82A4QJ+8IuK4YxqxgIjv2b4lKVw6QtuEECC/xJ3mW+zf3CxRyfDd2pZD2ue6CXRzcNg6YvMY55J43aCmYV2dc4nWdZXLF6i8= 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=jCe3yhRQ; arc=none smtp.client-ip=209.85.208.182 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="jCe3yhRQ" Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-38dfb789d7fso4393481fa.2 for ; Wed, 29 Apr 2026 22:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777527886; x=1778132686; 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=0GzixCwTpQHWHlB65KJEzMOkrrN2puCUVkU1mM/Uivk=; b=jCe3yhRQ9CsLj+T3i0B9yvXKExLa+xO/Y/2rXEgWBKHf3BFuU124JrVO1R7fxe8MiM aOlOYGWQAdRgyKP17rh5ZkY/e47NbePCvv4gUX9uR3bn6uqaWtCxzxJuqRYVxw8tYqk5 nc5YYgHgpfVgWrnAU6AzrHWw1zp3iSW6HBsNe/y3uDDZ+IfGkkuQb0N8YZBwNFTOuEy8 xO1hRttodc2V2PlLibOOcM2U+0+sXhyieLF4z/fAREu/W0BjmsecRbHq0sTm0T2XhQ6F 7YfRHamZygfATL0//VBYVaj9Mp88sAV7vTbXlplmZXcGxBrhXvmFKsmnibQ7wos/VnKZ L7Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777527886; x=1778132686; 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=0GzixCwTpQHWHlB65KJEzMOkrrN2puCUVkU1mM/Uivk=; b=O7UWkm3fMeNyUHdzjiTHghF3hXpC3fq/u93d98bFZFHFI47Pmdha9NmG8EHGe/OLLD tXL7WlEQ4GWf9U3+jgYH+AX6wTEfzNMSXMJgjlfXj5BzbW8cCCyAwYWL/cMzhG2woX2e I6lK0ifb76Ctkf0PrTYhGjK0dgtWSorfNnIlQJMHWRTHI+IDkV5dIXmv7UMVXeWIep1k cdgnSjz8lAqdeihZPWzF9WGgyHehmoBOwmI4IgbgswA6NxMK3xtB0o1S3DYy/h8VFqet loNVTCMDFbyfl3Yi9fUGX98U9ohtwASRG4zs5dQeYeVe3wMMJ/6ba5So+2/hwAuayh+R iiGA== X-Forwarded-Encrypted: i=1; AFNElJ/nKdxfFGTdvi1GdoIEz50owhYdnfSTRSu44UqXe+i+sU9bB8SPzurrKTZ3hfUNCnQ9ilDyrsa8eU+7V1A=@vger.kernel.org X-Gm-Message-State: AOJu0YxKCw0J1Xv3Bj9BmO6D1SRTZAPjjRl6gK6YNbkOIGglA+MBWiGU 0C4WF/2KbgLXjb4k/H/525FbJDHNhvAW8l/b/c8y2y1qz3/ssLqqe+PI X-Gm-Gg: AeBDiev09XHloizOn1v4NBYdad5QcCX6d0wsPvWppunlUJ5GgS0zzDAu722BXfBaIfb wMWcY6DfAXA+lV2QNxnLDCGK655xwS15gOgM+w7stVSNOhJ1CkPbgFIahYqxylMtbgVBAdhWVjb z46Or9K8zUlmn6vO9tlRngggmIE4NJZhJzzRUVwIptd0HzGjZD4uTK6eNWMC+qhXvXowh/OY644 WeAPmz30SqDBgRlQh/fjh+AOPpKOcDCh0xgXAGOflsR9KqY6EOt9QesBLIw/jR9ft59/kRd0+IA PQpP66RtfpgVlKzJnMmpRHpFqmz248gUQ/fVgP7z6Fh6k/c/SaQoqDjQwO1HVUg4X+YrlRkCgJ3 ktz8ioZGJ1gLqZyHIKyLALIg9Bjsa54pCt3HrxlbiOQ3vD2zR7WRksDrqkU9mVEZodRRfuQOWWQ sVG8ir++H4GRk4PVX2p4nzqX3zGm+aYvOVqdzLZhLaxWw= X-Received: by 2002:a2e:8a87:0:b0:38a:2776:1484 with SMTP id 38308e7fff4ca-3934e30721cmr5154621fa.28.1777527885318; Wed, 29 Apr 2026 22:44:45 -0700 (PDT) Received: from foxbook (bfh75.neoplus.adsl.tpnet.pl. [83.28.45.75]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3934f7ad0a6sm2732741fa.1.2026.04.29.22.44.44 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 29 Apr 2026 22:44:44 -0700 (PDT) Date: Thu, 30 Apr 2026 07:44:41 +0200 From: Michal Pecio To: Birger Koblitz Cc: Andrew Lunn , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-usb@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Chih Kai Hsu Subject: Re: [PATCH net-next 3/4] r8152: Add irq mitigation for RTL8157/9 Message-ID: <20260430074441.203192de.michal.pecio@gmail.com> In-Reply-To: <4446ad8c-0f5f-4f5a-8166-557ce9cc91b7@birger-koblitz.de> References: <20260428-rtl8159_net_next-v1-0-52d03927b46f@birger-koblitz.de> <20260428-rtl8159_net_next-v1-3-52d03927b46f@birger-koblitz.de> <06a42ba1-b714-45b1-be30-4a793752e495@lunn.ch> <9feb0bc1-b817-46f8-9092-e2beff30ec9d@birger-koblitz.de> <20260429200214.3e8dee67.michal.pecio@gmail.com> <4446ad8c-0f5f-4f5a-8166-557ce9cc91b7@birger-koblitz.de> 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 Thu, 30 Apr 2026 05:36:06 +0200, Birger Koblitz wrote: > Thanks Michal, for your explanations! > On 29/04/2026 8:02 pm, Michal Pecio wrote: > >>> What does interrupt mitigation do? > >>> > >>> Is this a different name for interrupt coalescence, where the MAC > >>> delays interrupts for a period of time so more packets are in the > >>> receive ring when it does interrupt, so reducing the number of > >>> interrupts, and bigger bursts of packets are processed at once? > >>> > >> > >> I do not understand what the mechanism behind this is, there is no > >> more documentation in the original driver. I experimented with this > >> for some time and the effect that I see is that it prevents > >> interrupts after shutdown. > > > > What do you mean by "after shutdown", driver unbind? You shouldn't be > > seeing URB completions then if the disconnect() method unlinks them. > > And if it doesn't, completions may be using driver data after free. > > > > Or maybe you have pending URBs while calling set_configuration() or > > set_interface(), which is dodgy too but at least not asking for panic. > > > > Other cause of ESHUTDOWN might be serious host controller failure, but > > you would likely get other log noise with that, at least with xhci. > > > > What shows up if you repro with this enabled? > > echo 'module usbcore +p' >/proc/dynamic_debug/control > > > > With shutdown, I meant shutting down the driver: the error happens when > unloading the driver using rmmod, e.g. when testing different driver > versions. Sorry, I remembered wrong. That UAF problem only applies to control URBs on endpoint 0. All other URBs are removed by USB core *before* rtl8152_disconnect() is called. So it doesn't need to unlink them and it cannot predict when the URBs will be nuked by core. > What I see when turning on debugging is this: > [373042.499758] r8152 2-1:1.0 enx88c9b3b53125: carrier on > [373104.440114] usbcore: deregistering interface driver r8152 > [373104.440141] xhci_hcd 0000:0c:00.0: shutdown urb 000000005501f8cc > ep1in-bulk > [373104.440146] xhci_hcd 0000:0c:00.0: shutdown urb 0000000066ae4a92 > ep1in-bulk > [373104.440148] xhci_hcd 0000:0c:00.0: shutdown urb 00000000e9728025 > ep1in-bulk > [373104.440151] xhci_hcd 0000:0c:00.0: shutdown urb 00000000fa874ca0 > ep1in-bulk > [373104.440153] xhci_hcd 0000:0c:00.0: shutdown urb 000000006006ed5d > ep1in-bulk > [373104.440156] xhci_hcd 0000:0c:00.0: shutdown urb 00000000a5bee1e7 > ep1in-bulk > [373104.440158] xhci_hcd 0000:0c:00.0: shutdown urb 00000000bc3a3ab0 > ep1in-bulk > [373104.440160] xhci_hcd 0000:0c:00.0: shutdown urb 0000000080a63692 > ep1in-bulk > [373104.440163] xhci_hcd 0000:0c:00.0: shutdown urb 0000000025af4e6e > ep1in-bulk > [373104.440165] xhci_hcd 0000:0c:00.0: shutdown urb 0000000056d7e76e > ep1in-bulk > [373104.440472] xhci_hcd 0000:0c:00.0: shutdown urb 00000000d8814536 > ep3in-intr And that's what happens in the log above, for the reason below: [ +0,000015] usb_hcd_flush_endpoint.cold+0xa/0x23 [usbcore] [ +0,000050] usb_disable_endpoint+0x52/0xa0 [usbcore] [ +0,000048] usb_disable_interface.cold+0x3f/0x4e [usbcore] [ +0,000038] usb_unbind_interface+0x138/0x2f0 [usbcore] [ +0,000048] device_release_driver_internal+0x194/0x200 > [373104.440790] r8152 2-1:1.0 enx88c9b3b53125: Stop submitting intr, > status -108 So this message is harmless. I'm also seeing it with RTL8153 if the interface is up at the time of rmmod. > In the past I have also seen the following, but am not able to reproduce it: > [371283.534041] r8152-cfgselector 2-1: USB disconnect, device number 25 > [371283.534470] r8152 2-1:1.0 enx00e04c680023: Stop submitting intr, > status -108 Apparently the disconnect message is logged before calling rtl8152_disconnect(), so that's probably harmless too. I'm not sure how tweaking some HW registers prevents it. Maybe it causes the HW to complete the URB (but why?) at the right moment so that it isn't pending during usb_disable_endpoint(), IDK, weird. Regards, Michal