diff options
| author | 2026-05-02 10:20:58 -0700 | |
|---|---|---|
| committer | 2026-05-02 10:21:00 -0700 | |
| commit | 386829cd895b985b410f85253b1a7247a38148c2 (patch) | |
| tree | 91478226e09593baa593edcfab27d527aac385cc /samples/kobject/ssh:/git@git.zx2c4.com | |
| parent | amd-xgbe: fix PTP addend overflow causing frozen clock (diff) | |
| parent | selftests/tc-testing: Add tests that force red and sfb to dequeue from child's gso_skb (diff) | |
Merge branch 'replace-direct-dequeue-call-with-qdisc_dequeue_peeked'
Jamal Hadi Salim says:
====================
Replace direct dequeue call with qdisc_dequeue_peeked
When sfb and red qdiscs have children (eg qfq qdisc) whose peek() callback is
qdisc_peek_dequeued(), we could get a kernel panic. When the parent of such
qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from
its child (red/sfb in this case), it will do the following:
1a. do a peek() - and when sensing there's an skb the child can offer, then
- the child in this case(red/sfb) calls its child's (qfq) peek.
qfq does the right thing and will return the gso_skb queue packet.
Note: if there wasnt a gso_skb entry then qfq will store it there.
1b. invoke a dequeue() on the child (red/sfb). And herein lies the problem.
- red/sfb will call the child's dequeue() which will essentially just
try to grab something of qfq's queue.
The right thing to do in #1b is to grab the skb off gso_skb queue.
This patchset fixes that issue by changing #1b to use qdisc_dequeue_peeked()
method instead.
Patch 1 fixes the issue for red qdisc. Patch 2 fixes it for sfb.
Patch 3 adds testcases for the two setups.
====================
Link: https://patch.msgid.link/20260430152957.194015-1-jhs@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'samples/kobject/ssh:/git@git.zx2c4.com')
0 files changed, 0 insertions, 0 deletions
