From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from r3-11.sinamail.sina.com.cn (r3-11.sinamail.sina.com.cn [202.108.3.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F09F13DAAB7 for ; Fri, 14 Aug 2026 03:27:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.108.3.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786678038; cv=none; b=dopoAfltCELY4g4aTTuDrIJ6CxkjqYw+QCIQ/83kPFS+HVoZyUhJBB6OQTo4t0qFAgtcnxwt5yq9r7hXRIJgPUs8vGodtvjdM7gKWKaWyOcb1atRg5B7XRC18t22x/uXd2rGa7cQm8Gm1aCe1s+arpBdm0jEhJ0rd+x+Y5JtXpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786678038; c=relaxed/simple; bh=GdbuusNsMQFdAEysKf53MIhq4ecB836kQpCfIOzTts0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pWCPrp60RlZ5d5Ithbspz6GRiS7UgCBF/ga1CY7u1du2Ieq+iv7nN4MVf0/BrXOc1bgs7jfjPrMT8oAp98ZV5JTAg0GdHzdgpg3flc7i/GVunD6R7CAkxPtHvHpw+t0TTz6NNvuQaEe2BSjrdF9IIasl6kcwDGCimhGqRM9aImQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b=hKnI55xj; arc=none smtp.client-ip=202.108.3.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=sina.com header.i=@sina.com header.b="hKnI55xj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sina.com; s=201208; t=1786678034; bh=/xvS0Kxl7d4riGZXFWBaS3WJvljdRf0SdKdoBQoRvhY=; h=From:Subject:Date:Message-ID; b=hKnI55xjYGdpYb7LJET2QopXjJh90NTy1Llo1aAncBO9qc3+gZTyLAWzp8VuR04Oh Kx0QDVXZa+qUviKKhOze+cGIIoMMZ9D7O9cHExA1/P53UAbuwF3C8mt9lLVSACqZPJ wFiABgqkMAXKzwDJw2cLUgfjyTCgN815iSB9LEOc= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([221.216.154.155]) by sina.com (10.54.253.34) with ESMTP id 6A7E8AE70000170A; Fri, 14 Aug 2026 11:26:34 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 7258436291635 X-SMAIL-UIID: 86C19A9B27264A67818EBF7291DA371A-20260814-112634-1 From: Hillf Danton To: Uladzislau Zhauniarovich Cc: "syzbot" , syzkaller-bugs@googlegroups.com, Eric Dumazet , Vinicius Costa Gomes , linux-kernel@vger.kernel.org, syzbot@lists.linux.dev Subject: Re: [PATCH] net/sched: taprio: enforce minimum software scheduling interval Date: Fri, 14 Aug 2026 11:26:23 +0800 Message-ID: <20260814032624.1082-1-hdanton@sina.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-Transfer-Encoding: 8bit On Thu, 13 Aug 2026 02:15:49 +0000 (UTC) Uladzislau Zhauniarovich wrote: > When configuring taprio with a very small schedule interval (e.g., 129 ns), > the kernel validates the interval against the time it takes to transmit a > minimum-sized Ethernet frame (60 bytes). On high-speed links, this minimum > duration is extremely small (e.g., 48 ns at 10 Gbps). Since the requested > interval is larger than this, the validation passes. Virtual devices like > veth or bonding can defeat this link-speed minimum check because they > report inflated link speeds (e.g., veth reports 10 Gbps, and bonding sums > member speeds). > > However, when hardware offload is not used, taprio falls back to software > scheduling and arms an hrtimer. The hrtimer is programmed to fire at the > configured interval. If this interval is too small, it cannot sustain the > timer service cost of one advance_sched() invocation, which includes lock > acquisition, budget recomputation, and TX softirq processing. As a result, > the timer constantly falls behind, and the CPU is livelocked in hardirq > context endlessly servicing the advance_sched() hrtimer. This starves the > RCU grace-period kthreads, leading to an RCU stall panic: > > rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: > rcu: 1-...!: (1 GPs behind) idle=4854/0/0x1 softirq=136062/136068 fqs=0 > rcu: (detected by 0, t=10506 jiffies, g=161469, q=1866 ncpus=2) > Sending NMI from CPU 0 to CPUs 1: > NMI backtrace for cpu 1 > CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted > Call Trace: > > lock_is_held include/linux/lockdep.h:249 [inline] > enqueue_hrtimer+0x79/0x2c0 kernel/time/hrtimer.c:1107 > __run_hrtimer kernel/time/hrtimer.c:1946 [inline] > __hrtimer_run_queues+0x4ce/0xa10 kernel/time/hrtimer.c:1994 > hrtimer_interrupt+0x448/0x910 kernel/time/hrtimer.c:2113 > local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline] > __sysvec_apic_timer_interrupt+0x102/0x430 arch/x86/kernel/apic/apic.c:1067 > instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1061 > [inline] > sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1061 > > > To fix this, enforce a hard absolute minimum interval of 100 microseconds Better if you specify why interval like 2us is ruled out. > (TAPRIO_MIN_SW_INTERVAL_NS) for software-based scheduling, which provides > enough margin over the timer service cost. Fully offloaded schedules are > unaffected since they do not rely on the CPU's hrtimer. Introduce a helper > taprio_min_interval() to consolidate the minimum interval logic for both > individual schedule entries and the overall cycle_time validation.