Re: [PATCH net v2 2/2] net/sched: sch_teql: fix use-after-free on lower qdisc drop

[Simon Horman <horms@kernel.org>]

On Tue, Oct 27, 2026 at 05:19:26PM -0400, Jamal Hadi Salim wrote:
> On Tue, Oct 27, 2026 at 2:29 PM Simon Horman <horms@kernel.org> wrote:
> >
> > 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://netdev-ai.bots.linux.dev/sashiko/#/patchset/QDISC-Y0BY.v2.r0.20261024060625-1@mojatatu.com?part=2
> 
> So this email was stuck at sashiko because the email fields wouldnt
> allow it. Set at:
> email_status: Muted, smtp_enabled: false
> The same with patch 2/2

Fun times in AI-land.

> I will respond to both here. Summary is: i will not be sending an update.
> 
> For patch [1/2] net/sched: sch_teql: fix slaves_lock IRQ deadlock
> The High is pre-existing and not introduced by this patch, which only
> converts slaves_lock to a raw spinlock.
> I have a separate fix that bounds the walk by a slave_count maintained
> under slaves_lock; it will be posted after this  series gets merged.
> 
> Patch [2/2] net/sched: sch_teql: fix use-after-free on lower qdisc drop:
> 
> 1) Low: agreed, the changelog is misleading (the code is intended as written).
> NETDEV_TX_OK and NET_XMIT_CN are both counted as good transmits,
> matching  net_xmit_eval(); any other consumed result is charged to
> tx_dropped.
> I don't think it warrants a respin on its own unless something even
> semi-serious shows up in the code.
> 
> 2) Medium: the non-rotation is pre-existing.  Before this patch the
> drop path never advanced master->slaves either; it just retried the
> freed skb, which is the use-after-free being fixed.
> Advancing to NEXT_SLAVE(q) here is a  load-distribution improvement,
> not a correctness requirement of this fix.
>  IMO:   I would rather not inclued a policy change into the UAF fix; I
> can send it  separately.

Thanks for the feedback.
I agree with your suggested approaches.

Reviewed-by: Simon Horman <horms@kernel.org>