From: Simon Horman <horms@kernel.org>
To: sam.moelius@trailofbits.com
Cc: Simon Horman <horms@kernel.org>,
jhs@mojatatu.com, jiri@resnulli.us, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/sched: hhf: clear heavy-hitter state on reset
Date: Thu, 11 Jun 2026 12:13:29 +0100 [thread overview]
Message-ID: <20260611111328.544867-2-horms@kernel.org> (raw)
In-Reply-To: <20260609004937.1240807.c0dcec938172.hhf-reset-stale-classifier@trailofbits.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net/sched: hhf: clear heavy-hitter state on reset
This commit clears the heavy-hitter classifier tables when the HHF qdisc
is reset. This prevents packets from being scheduled using flow history
from before the reset operation.
> diff --git a/net/sched/sch_hhf.c b/net/sched/sch_hhf.c
> index 96021f52d835b..1698c1b54dec8 100644
> --- a/net/sched/sch_hhf.c
> +++ b/net/sched/sch_hhf.c
[ ... ]
> @@ -461,12 +461,34 @@ static struct sk_buff *hhf_dequeue(struct Qdisc *sch)
> return skb;
> }
>
> +static void hhf_reset_classifier(struct hhf_sched_data *q)
> +{
> + int i;
> +
> + for (i = 0; i < HH_FLOWS_CNT; i++) {
> + struct hh_flow_state *flow, *next;
> + struct list_head *head = &q->hh_flows[i];
> +
> + list_for_each_entry_safe(flow, next, head, flowchain) {
[Severity: High]
If hhf_init() fails due to a memory allocation error, q->hh_flows will be
NULL. When qdisc_create_dflt() cleans up from the error, it calls
qdisc_put() -> __qdisc_destroy(), which unconditionally calls qdisc_reset()
and triggers hhf_reset().
Does the pointer arithmetic here yield a NULL-derived pointer that will
cause a kernel panic when list_for_each_entry_safe() dereferences
head->next?
I noticed hhf_destroy() has a specific check (`if (!q->hh_flows)`) to avoid
this issue during cleanup. Would it make sense to add a similar check here?
> + list_del(&flow->flowchain);
> + kfree(flow);
> + }
> + }
> + WRITE_ONCE(q->hh_flows_current_cnt, 0);
> +
> + for (i = 0; i < HHF_ARRAYS_CNT; i++)
> + bitmap_zero(q->hhf_valid_bits[i], HHF_ARRAYS_LEN);
[Severity: High]
Similarly, q->hhf_valid_bits[i] will also be NULL on the initialization error
path.
Because bitmap_zero() internally uses memset(), will passing a NULL
pointer here cause an immediate crash when the cleanup path executes?
> + q->hhf_arrays_reset_timestamp = hhf_time_stamp();
> +}
> +
> static void hhf_reset(struct Qdisc *sch)
[ ... ]
prev parent reply other threads:[~2026-06-11 11:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 0:49 [PATCH] net/sched: hhf: clear heavy-hitter state on reset Samuel Moelius
2026-06-11 11:13 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260611111328.544867-2-horms@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sam.moelius@trailofbits.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.