From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 75F4C3890E9 for ; Thu, 16 Apr 2026 13:25:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776345946; cv=none; b=Gphw1ATGUmMpkgHw1phWZnJmCScSiw+FuXl6XryB5t1TH4oLlbwirb65R866AzKGJAX7keSCgUvB8rLMZlCytJmo20qy9yeZylUHnqTyhluDuy1ni6LavoGlqJHsin5Qcym0lBqN6oRc7fnJDX/erUEB/PvX7+hDEyWUl1fep74= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776345946; c=relaxed/simple; bh=Ks9Lh9sXM3NHLG5RlrbfioY0KnQFqSIq3pvt4kyDJFM=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=CQlLuSBpqQjAUBW8NbBmAvZeaY4pyvYluQmltUv50FH233gNEZ9kPQh4EbQq2UG+3ji+K5L7THcHHFON211jiAvpVBKEj0iQmF7VsSPNH/wZmxN2O5llq4drqvnauKJu3B0G+19fP+IlRxzsWlsfaj6nZyAFQjQW8eXOTS5HdLg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=LOeiFbrU; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=JG/2nIrq; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="LOeiFbrU"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="JG/2nIrq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776345944; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wXZK7Wy94J2sz6DnNYsgQgumJpWskcv2kpLOs6mdi4E=; b=LOeiFbrUEyHdRUb0XxW6ebIifgb8CZ3gI4BlI/HVdn013UO3BgNQ2LTFl4SvA6ws7Fl2kn 4IHfbsRwxz31tN2zE5tamM/ideQ04QLghiMrk4iC6Vd/1BeDjCAR+d1MXc7Vhc4cFR1gnX 2S0jelQXo+QCznVoCU5V1V+15FqfRQQ= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-228-JZdlRltaNVe6ZSQiUG14vw-1; Thu, 16 Apr 2026 09:25:41 -0400 X-MC-Unique: JZdlRltaNVe6ZSQiUG14vw-1 X-Mimecast-MFC-AGG-ID: JZdlRltaNVe6ZSQiUG14vw_1776345941 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-43d1fec59c9so392113f8f.0 for ; Thu, 16 Apr 2026 06:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776345940; x=1776950740; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=wXZK7Wy94J2sz6DnNYsgQgumJpWskcv2kpLOs6mdi4E=; b=JG/2nIrqnoi73i9b0nBfUFrXYEY9hJc4jcapcD3ydUJVBn5e6h49qhhZStwaxU8IqT Ro4I87XtcQKuzOyPTzs8PuBzuqPMlkqZXRA6eIskMYzGWdVQFu3xhPxMsYjrLQPm6tGN 1WmMOaoBJ3B58GzNKijS+Xwuf3gmgtva+aDPNyVyGgb2q4ya/rg6diqRRxCi2vRXfT1h GLhRDOUX8LOsT6LHztYIphhmNrOzRUdzoKdZeEUmOeeUSJ9FdTlqHhHcQ9l23nmrTIfL VpxE2MmBu5FebCyiVqoTYu6pQjfto2N3degLvHqERq0i/YLXMb1t7AuJmuuNOcOspE6X FIsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776345940; x=1776950740; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wXZK7Wy94J2sz6DnNYsgQgumJpWskcv2kpLOs6mdi4E=; b=mDzQkWVcZR8erMbWOl/UDV7gYyxecche+PI6gF7xhekcm/RJStm+KTmWlrwQY5gRT9 EYzyXmry0HKoAxWdtyVV+QCdvruC6aEQNDIPZrLzuvxXeaGQU5VbEs4p/Z4gsHwN3vWK oiH3vWkRc1pTpaFYD6Dh7yZr/vUi4Z4QQmMCVCgG9hjoe9lyRofp2bz2Ajcodkw33deB qdQAOAYOc6Bb2LcAfaLBwQdYch1ZOH8w5tiBahJxVE5Pe9uh6P7At4SAmPTz8Y68ayp8 jqPPuwr3bPIyPZ4ag+gCbKZ2KPzAdujf19r5LpXh8YGuS1tdW38M7+nhm5vcZncUTuAZ Lf+g== X-Forwarded-Encrypted: i=1; AFNElJ8OmRNdGs3jDw9Prsej53hQc0XKWReJF0+84IaQzogcFoHNSS1euCRrUfdz9Ktdn5e7rEEOzb9Vqg1bTlI=@vger.kernel.org X-Gm-Message-State: AOJu0YyI+zFZW5UIQDHCKxniRFOWIOqAcQt7BY/zuaQBaRhb00dFIdU2 UelYGx03H/UkLPcgwv0JWQEIMCijskjdEgsrOXDoCFFjCZ43K40TfGwblmDroEjxT6yO8lZKmbs Zck56eQ6XzznunCJuP/ZovLF2p542cBqNBH0j7t44l3k/0916EUM1WzxYrwUZVmlwSA== X-Gm-Gg: AeBDiesNy0cxlmxOw6XPC9luhznCcmLWc/IzMxkJuB9eLfPCQLXPIa/jdLwvfAzdthI BjdQHQKMSEDbn0AuSi+rowe3av6AHaW19zU5Y0JfKSHgpLGESdjf+9vDw9EPx/Jk67IgWpKQ47e 8W7dEKI+cpR9VwkPji6eIkRDacxC2ymS4JCJiawkMwXjvnnO3qocHg9oXQJbkwBOCzwurkpFQsg +pV/YzCywX9mhFBL0cjCw9lM1N3vYjIW6Zqdou9aWuQt6QRYlowe3nVsDvDSH5WRkZPiVGgVtej ZsnKivc+p5YeisS6HH8Xg7e2bixzKA+Gmvk0/28u+zroIZtYZtYeZ6kFQkhmGr6szMyaR/QhynI VJlhGzfIfjb+G/zFhzu+gB2kAdWEif9GGtNGDEkJ6X+weu3BE8WXj9JH7K2hBKApSZHM= X-Received: by 2002:a05:6000:1889:b0:43d:2d34:8963 with SMTP id ffacd0b85a97d-43fdbb4cd6emr3233672f8f.17.1776345940515; Thu, 16 Apr 2026 06:25:40 -0700 (PDT) X-Received: by 2002:a05:6000:1889:b0:43d:2d34:8963 with SMTP id ffacd0b85a97d-43fdbb4cd6emr3233578f8f.17.1776345939959; Thu, 16 Apr 2026 06:25:39 -0700 (PDT) Received: from [192.168.88.32] ([150.228.93.122]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43ead3d5fd6sm14487794f8f.24.2026.04.16.06.25.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2026 06:25:39 -0700 (PDT) Message-ID: <9ff2df3e-08cf-4f61-8a58-cac0a6980b2d@redhat.com> Date: Thu, 16 Apr 2026 15:25:37 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue To: chia-yu.chang@nokia-bell-labs.com, linux-hardening@vger.kernel.org, kees@kernel.org, gustavoars@kernel.org, jhs@mojatatu.com, jiri@resnulli.us, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, horms@kernel.org, ij@kernel.org, ncardwell@google.com, koen.de_schepper@nokia-bell-labs.com, g.white@cablelabs.com, ingemar.s.johansson@ericsson.com, mirja.kuehlewind@ericsson.com, cheshire@apple.com, rs.ietf@gmx.at, Jason_Livingood@comcast.com, vidhi_goel@apple.com References: <20260413163711.56191-1-chia-yu.chang@nokia-bell-labs.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: <20260413163711.56191-1-chia-yu.chang@nokia-bell-labs.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/13/26 6:37 PM, chia-yu.chang@nokia-bell-labs.com wrote: > From: Chia-Yu Chang > > Fix dualpi2_change() to correctly enforce updated limit and memlimit values > after a configuration change of the dualpi2 qdisc. > > Before this patch, dualpi2_change() always attempted to dequeue packets via > the root qdisc (C-queue) when reducing backlog or memory usage, and > unconditionally assumed that a valid skb will be returned. When traffic > classification results in packets being queued in the L-queue while the > C-queue is empty, this leads to a NULL skb dereference during limit or > memlimit enforcement. > > This is fixed by first dequeuing from the C-queue path if it is non-empty. > Once the C-queue is empty, packets are dequeued directly from the L-queue. > Return values from qdisc_dequeue_internal() are checked for both queues. When > dequeuing from the L-queue, the parent qdisc qlen and backlog counters are > updated explicitly to keep overall qdisc statistics consistent. > > Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2 qdisc") > Signed-off-by: Chia-Yu Chang > --- > net/sched/sch_dualpi2.c | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > > diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c > index 6d7e6389758d..56d4422970b6 100644 > --- a/net/sched/sch_dualpi2.c > +++ b/net/sched/sch_dualpi2.c > @@ -872,11 +872,25 @@ static int dualpi2_change(struct Qdisc *sch, struct nlattr *opt, > old_backlog = sch->qstats.backlog; > while (qdisc_qlen(sch) > sch->limit || > q->memory_used > q->memory_limit) { > - struct sk_buff *skb = qdisc_dequeue_internal(sch, true); > - > - q->memory_used -= skb->truesize; > - qdisc_qstats_backlog_dec(sch, skb); > - rtnl_qdisc_drop(skb, sch); > + int c_len = qdisc_qlen(sch) - qdisc_qlen(q->l_queue); > + struct sk_buff *skb = NULL; > + > + if (c_len) { > + skb = qdisc_dequeue_internal(sch, true); > + if (!skb) > + break; > + q->memory_used -= skb->truesize; > + rtnl_qdisc_drop(skb, sch); > + } else if (qdisc_qlen(q->l_queue)) { > + skb = qdisc_dequeue_internal(q->l_queue, true); > + if (!skb) > + break; > + q->memory_used -= skb->truesize; > + rtnl_qdisc_drop(skb, q->l_queue); > + /* Keep the overall qdisc stats consistent */ > + --sch->q.qlen; > + qdisc_qstats_backlog_dec(sch, skb); Sashiko says: --- The drop counter is incremented for the L-queue via rtnl_qdisc_drop(), but it appears the drop counter for the parent qdisc (sch) is not updated. Will this cause user-facing statistics for the overall dualpi2 qdisc to underreport drops? ---