From: Eric Dumazet <hidden> Date: 2021-09-27 23:49:35
On 9/27/21 4:30 PM, Ben Greear wrote:
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
From: Ben Greear <hidden> Date: 2021-09-28 00:04:06
On 9/27/21 4:49 PM, Eric Dumazet wrote:
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Thanks,
Ben
From: Ben Greear <hidden> Date: 2021-09-28 00:26:12
On 9/27/21 5:04 PM, Ben Greear wrote:
On 9/27/21 4:49 PM, Eric Dumazet wrote:
quoted
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Still running stable. I also notice we have been using fq-codel for a while and haven't noticed
this problem (next most recent kernel we might have run similar test on would be 5.13-ish).
I'll duplicate this test on our older kernels tomorrow to see if it looks like a regression or
if we just haven't actually done this exact test in a while...
Thanks,
Ben
From: Ben Greear <hidden> Date: 2021-09-28 22:00:56
On 9/27/21 5:16 PM, Ben Greear wrote:
On 9/27/21 5:04 PM, Ben Greear wrote:
quoted
On 9/27/21 4:49 PM, Eric Dumazet wrote:
quoted
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Still running stable. I also notice we have been using fq-codel for a while and haven't noticed
this problem (next most recent kernel we might have run similar test on would be 5.13-ish).
I'll duplicate this test on our older kernels tomorrow to see if it looks like a regression or
if we just haven't actually done this exact test in a while...
We can reproduce this crash as far back as 5.4 using fq-codel, with our pktgen driving mac-vlans.
We did not try any kernels older than 5.4.
We cannot reproduce with pfifo on 5.15-rc3 on an overnight run.
We cannot produce with user-space UDP traffic on any kernel/qdisc combination.
Our pktgen is configured for multi-skb of 0 (no multiple submits of the same skb)
While looking briefly at fq-codel, I didn't notice any locking in the code that crashed.
Any chance that it makes assumptions that would be incorrect with pktgen running multiple
threads (one thread per mac-vlan) on top of a single qdisc belonging to the underlying NIC?
Thanks,
Ben
From: Eric Dumazet <hidden> Date: 2021-09-28 23:25:44
On 9/28/21 3:00 PM, Ben Greear wrote:
On 9/27/21 5:16 PM, Ben Greear wrote:
quoted
On 9/27/21 5:04 PM, Ben Greear wrote:
quoted
On 9/27/21 4:49 PM, Eric Dumazet wrote:
quoted
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Still running stable. I also notice we have been using fq-codel for a while and haven't noticed
this problem (next most recent kernel we might have run similar test on would be 5.13-ish).
I'll duplicate this test on our older kernels tomorrow to see if it looks like a regression or
if we just haven't actually done this exact test in a while...
We can reproduce this crash as far back as 5.4 using fq-codel, with our pktgen driving mac-vlans.
We did not try any kernels older than 5.4.
We cannot reproduce with pfifo on 5.15-rc3 on an overnight run.
We cannot produce with user-space UDP traffic on any kernel/qdisc combination.
Our pktgen is configured for multi-skb of 0 (no multiple submits of the same skb)
While looking briefly at fq-codel, I didn't notice any locking in the code that crashed.
Any chance that it makes assumptions that would be incorrect with pktgen running multiple
threads (one thread per mac-vlan) on top of a single qdisc belonging to the underlying NIC?
qdisc are protected by a qdisc spinlock.
fq-codel does not have to lock anything in its enqueue() and dequeue() methods.
I guess your local changes to pktgen might be to blame.
pfifo is much simpler than fq-codel, it uses less fields from skb.
From: Ben Greear <hidden> Date: 2021-09-29 19:07:29
On 9/28/21 4:25 PM, Eric Dumazet wrote:
On 9/28/21 3:00 PM, Ben Greear wrote:
quoted
On 9/27/21 5:16 PM, Ben Greear wrote:
quoted
On 9/27/21 5:04 PM, Ben Greear wrote:
quoted
On 9/27/21 4:49 PM, Eric Dumazet wrote:
quoted
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Still running stable. I also notice we have been using fq-codel for a while and haven't noticed
this problem (next most recent kernel we might have run similar test on would be 5.13-ish).
I'll duplicate this test on our older kernels tomorrow to see if it looks like a regression or
if we just haven't actually done this exact test in a while...
We can reproduce this crash as far back as 5.4 using fq-codel, with our pktgen driving mac-vlans.
We did not try any kernels older than 5.4.
We cannot reproduce with pfifo on 5.15-rc3 on an overnight run.
We cannot produce with user-space UDP traffic on any kernel/qdisc combination.
Our pktgen is configured for multi-skb of 0 (no multiple submits of the same skb)
While looking briefly at fq-codel, I didn't notice any locking in the code that crashed.
Any chance that it makes assumptions that would be incorrect with pktgen running multiple
threads (one thread per mac-vlan) on top of a single qdisc belonging to the underlying NIC?
qdisc are protected by a qdisc spinlock.
fq-codel does not have to lock anything in its enqueue() and dequeue() methods.
I guess your local changes to pktgen might be to blame.
pfifo is much simpler than fq-codel, it uses less fields from skb.
I looked through my pktgen, and the skb creation and setup code looks pretty
similar to upstream pktgen.
I also added this debugging code:
[greearb@ben-dt4 linux-5.15.dev.y]$ git diff
The printout I see when this hits is:
fq-codel-drop: idx: 955 maxbacklog: 7756222 threshold: 3878111 max_packets: 64 len: 93868 i: 62
kernel BUG at net/sched/sch_fq_codel.c:171!
.....
So, I guess this means that the backlog byte counter is out of sync with the packet queue somehow?
Any suggestions for what kinds of issues in pktgen could cause this?
Thanks,
Ben
--
Ben Greear [off-list ref]
Candela Technologies Inc http://www.candelatech.com
From: Eric Dumazet <hidden> Date: 2021-09-29 23:21:33
On 9/29/21 12:07 PM, Ben Greear wrote:
quoted hunk
On 9/28/21 4:25 PM, Eric Dumazet wrote:
quoted
On 9/28/21 3:00 PM, Ben Greear wrote:
quoted
On 9/27/21 5:16 PM, Ben Greear wrote:
quoted
On 9/27/21 5:04 PM, Ben Greear wrote:
quoted
On 9/27/21 4:49 PM, Eric Dumazet wrote:
quoted
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Still running stable. I also notice we have been using fq-codel for a while and haven't noticed
this problem (next most recent kernel we might have run similar test on would be 5.13-ish).
I'll duplicate this test on our older kernels tomorrow to see if it looks like a regression or
if we just haven't actually done this exact test in a while...
We can reproduce this crash as far back as 5.4 using fq-codel, with our pktgen driving mac-vlans.
We did not try any kernels older than 5.4.
We cannot reproduce with pfifo on 5.15-rc3 on an overnight run.
We cannot produce with user-space UDP traffic on any kernel/qdisc combination.
Our pktgen is configured for multi-skb of 0 (no multiple submits of the same skb)
While looking briefly at fq-codel, I didn't notice any locking in the code that crashed.
Any chance that it makes assumptions that would be incorrect with pktgen running multiple
threads (one thread per mac-vlan) on top of a single qdisc belonging to the underlying NIC?
qdisc are protected by a qdisc spinlock.
fq-codel does not have to lock anything in its enqueue() and dequeue() methods.
I guess your local changes to pktgen might be to blame.
pfifo is much simpler than fq-codel, it uses less fields from skb.
I looked through my pktgen, and the skb creation and setup code looks pretty
similar to upstream pktgen.
I also added this debugging code:
[greearb@ben-dt4 linux-5.15.dev.y]$ git diff
@@ -165,6 +165,11 @@ static unsigned int fq_codel_drop(struct Qdisc *sch, unsigned int max_packets,
len = 0;
i = 0;
do {
+ if (!flow->head) {
+ pr_err("fq-codel-drop: idx: %d maxbacklog: %d threshold: %d max_packets: %d len: %d i: %d\n",
+ idx, maxbacklog, threshold, max_packets, len, i);
+ BUG_ON(1);
+ }
skb = dequeue_head(flow);
len += qdisc_pkt_len(skb);
mem += get_codel_cb(skb)->mem_usage;
The printout I see when this hits is:
fq-codel-drop: idx: 955 maxbacklog: 7756222 threshold: 3878111 max_packets: 64 len: 93868 i: 62
kernel BUG at net/sched/sch_fq_codel.c:171!
.....
So, I guess this means that the backlog byte counter is out of sync with the packet queue somehow?
Any suggestions for what kinds of issues in pktgen could cause this?
Modifications to skbs after they were queued to the qdisc.
qdisc_pkt_len(skb) uses skb->cb[] storage. Make sure to not use it.
From: Eric Dumazet <hidden> Date: 2021-09-29 23:28:50
On 9/29/21 4:21 PM, Eric Dumazet wrote:
On 9/29/21 12:07 PM, Ben Greear wrote:
quoted
On 9/28/21 4:25 PM, Eric Dumazet wrote:
quoted
On 9/28/21 3:00 PM, Ben Greear wrote:
quoted
On 9/27/21 5:16 PM, Ben Greear wrote:
quoted
On 9/27/21 5:04 PM, Ben Greear wrote:
quoted
On 9/27/21 4:49 PM, Eric Dumazet wrote:
quoted
On 9/27/21 4:30 PM, Ben Greear wrote:
quoted
Hello,
In a hacked upon kernel, I'm getting crashes in fq-codel when doing bi-directional
pktgen traffic on top of mac-vlans. Unfortunately for me, I've made big changes to
pktgen so I cannot easily run this test on stock kernels, and there is some chance
some of my hackings have caused this issue.
But, in case others have seen similar, please let me know. I shall go digging
in the meantime...
Looks to me like 'skb' is NULL in line 120 below.
pktgen must not be used in a mode where a single skb
is cloned and reused, if packet needs to be stored in a qdisc.
qdisc of all sorts assume skb->next/prev can be used as
anchor in their list.
If the same skb is queued multiple times, lists are corrupted.
Please double check your clone_skb pktgen setup.
I thought we had IFF_TX_SKB_SHARING for this, and that macvlan was properly clearing this bit.
My pktgen config was not using any duplicated queueing in this case.
I changed to pfifo fast and so far it is stable for ~10 minutes, where before it would crash
within a minute. I'll let it bake overnight....
Still running stable. I also notice we have been using fq-codel for a while and haven't noticed
this problem (next most recent kernel we might have run similar test on would be 5.13-ish).
I'll duplicate this test on our older kernels tomorrow to see if it looks like a regression or
if we just haven't actually done this exact test in a while...
We can reproduce this crash as far back as 5.4 using fq-codel, with our pktgen driving mac-vlans.
We did not try any kernels older than 5.4.
We cannot reproduce with pfifo on 5.15-rc3 on an overnight run.
We cannot produce with user-space UDP traffic on any kernel/qdisc combination.
Our pktgen is configured for multi-skb of 0 (no multiple submits of the same skb)
While looking briefly at fq-codel, I didn't notice any locking in the code that crashed.
Any chance that it makes assumptions that would be incorrect with pktgen running multiple
threads (one thread per mac-vlan) on top of a single qdisc belonging to the underlying NIC?
qdisc are protected by a qdisc spinlock.
fq-codel does not have to lock anything in its enqueue() and dequeue() methods.
I guess your local changes to pktgen might be to blame.
pfifo is much simpler than fq-codel, it uses less fields from skb.
I looked through my pktgen, and the skb creation and setup code looks pretty
similar to upstream pktgen.
I also added this debugging code:
[greearb@ben-dt4 linux-5.15.dev.y]$ git diff
@@ -165,6 +165,11 @@ static unsigned int fq_codel_drop(struct Qdisc *sch, unsigned int max_packets,
len = 0;
i = 0;
do {
+ if (!flow->head) {
+ pr_err("fq-codel-drop: idx: %d maxbacklog: %d threshold: %d max_packets: %d len: %d i: %d\n",
+ idx, maxbacklog, threshold, max_packets, len, i);
+ BUG_ON(1);
+ }
skb = dequeue_head(flow);
len += qdisc_pkt_len(skb);
mem += get_codel_cb(skb)->mem_usage;
The printout I see when this hits is:
fq-codel-drop: idx: 955 maxbacklog: 7756222 threshold: 3878111 max_packets: 64 len: 93868 i: 62
kernel BUG at net/sched/sch_fq_codel.c:171!
.....
So, I guess this means that the backlog byte counter is out of sync with the packet queue somehow?
Any suggestions for what kinds of issues in pktgen could cause this?
Modifications to skbs after they were queued to the qdisc.
qdisc_pkt_len(skb) uses skb->cb[] storage. Make sure to not use it.
Actually the bug seems to be in pktgen, vs NET_XMIT_CN
You probably would hit the same issues with other qdisc also using NET_XMIT_CN
@@ -3567,6 +3567,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)caseNET_XMIT_DROP:caseNET_XMIT_CN:/* skb has been consumed */+pkt_dev->last_ok=1;pkt_dev->errors++;break;default:/* Drivers are not supposed to return other values! */
@@ -3567,6 +3567,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)caseNET_XMIT_DROP:caseNET_XMIT_CN:/* skb has been consumed */+pkt_dev->last_ok=1;pkt_dev->errors++;break;default:/* Drivers are not supposed to return other values! */
Thanks, that makes sense to me. I'll test that out tomorrow...
Thanks,
Ben
--
Ben Greear [off-list ref]
Candela Technologies Inc http://www.candelatech.com
case NET_XMIT_DROP:
case NET_XMIT_CN:
/* skb has been consumed */
+ pkt_dev->last_ok = 1;
pkt_dev->errors++;
break;
default: /* Drivers are not supposed to return other values! */
While patching my variant of pktgen, I took a look at the 'default' case. I think
it should probably go above NET_XMIT_DROP and fallthrough into the consumed pkt path?
Although, probably not a big deal since only bugs elsewhere would hit that path, and
we don't really know if skb would be consumed in that case or not.
Thanks,
Ben
case NET_XMIT_DROP:
case NET_XMIT_CN:
/* skb has been consumed */
+ pkt_dev->last_ok = 1;
pkt_dev->errors++;
break;
default: /* Drivers are not supposed to return other values! */
While patching my variant of pktgen, I took a look at the 'default' case. I think
it should probably go above NET_XMIT_DROP and fallthrough into the consumed pkt path?
Although, probably not a big deal since only bugs elsewhere would hit that path, and
we don't really know if skb would be consumed in that case or not.
This is probably dead code after commit
commit f466dba1832f05006cf6caa9be41fb98d11cb848 pktgen: ndo_start_xmit can return NET_XMIT_xxx values
So this does not really matter anymore.
case NET_XMIT_DROP:
case NET_XMIT_CN:
/* skb has been consumed */
+ pkt_dev->last_ok = 1;
pkt_dev->errors++;
break;
default: /* Drivers are not supposed to return other values! */
While patching my variant of pktgen, I took a look at the 'default' case. I think
it should probably go above NET_XMIT_DROP and fallthrough into the consumed pkt path?
Although, probably not a big deal since only bugs elsewhere would hit that path, and
we don't really know if skb would be consumed in that case or not.
This is probably dead code after commit
commit f466dba1832f05006cf6caa9be41fb98d11cb848 pktgen: ndo_start_xmit can return NET_XMIT_xxx values
So this does not really matter anymore.
Alternative would be the following patch.
NET_XMIT_CN means the packet has been queued for transmit,
but that we might have dropped prior packets.
Probably not a big deal to make the difference in pktgen.
@@ -3565,8 +3566,8 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)gotoxmit_more;break;caseNET_XMIT_DROP:-caseNET_XMIT_CN:/* skb has been consumed */+pkt_dev->last_ok=1;pkt_dev->errors++;break;default:/* Drivers are not supposed to return other values! */
@@ -3567,6 +3567,7 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)caseNET_XMIT_DROP:caseNET_XMIT_CN:/* skb has been consumed */+pkt_dev->last_ok=1;pkt_dev->errors++;break;default:/* Drivers are not supposed to return other values! */
While patching my variant of pktgen, I took a look at the 'default' case. I think
it should probably go above NET_XMIT_DROP and fallthrough into the consumed pkt path?
Although, probably not a big deal since only bugs elsewhere would hit that path, and
we don't really know if skb would be consumed in that case or not.
This is probably dead code after commit
commit f466dba1832f05006cf6caa9be41fb98d11cb848 pktgen: ndo_start_xmit can return NET_XMIT_xxx values
So this does not really matter anymore.
Alternative would be the following patch.
NET_XMIT_CN means the packet has been queued for transmit,
but that we might have dropped prior packets.
Probably not a big deal to make the difference in pktgen.
@@ -3565,8 +3566,8 @@ static void pktgen_xmit(struct pktgen_dev *pkt_dev)gotoxmit_more;break;caseNET_XMIT_DROP:-caseNET_XMIT_CN:/* skb has been consumed */+pkt_dev->last_ok=1;pkt_dev->errors++;break;default:/* Drivers are not supposed to return other values! */
Yes, I like that the XMIT_CN then means to increment the seq_num, though for my own purposes,
I wouldn't want to increment the sofar++ in that case (and maybe not do other logic in that case),
since we know at least something dropped.
For fq-codel, seems that XMIT_CN could mean that the attempted packet actually was queued
for xmit, but at least some other packets were purged.
Thanks,
Ben
--
Ben Greear [off-list ref]
Candela Technologies Inc http://www.candelatech.com
case NET_XMIT_DROP:
case NET_XMIT_CN:
/* skb has been consumed */
+ pkt_dev->last_ok = 1;
pkt_dev->errors++;
break;
default: /* Drivers are not supposed to return other values! */
While patching my variant of pktgen, I took a look at the 'default' case. I think
it should probably go above NET_XMIT_DROP and fallthrough into the consumed pkt path?
Although, probably not a big deal since only bugs elsewhere would hit that path, and
we don't really know if skb would be consumed in that case or not.
This is probably dead code after commit
commit f466dba1832f05006cf6caa9be41fb98d11cb848 pktgen: ndo_start_xmit can return NET_XMIT_xxx values
So this does not really matter anymore.
Alternative would be the following patch.
NET_XMIT_CN means the packet has been queued for transmit,
but that we might have dropped prior packets.
Probably not a big deal to make the difference in pktgen.
goto xmit_more;
break;
case NET_XMIT_DROP:
- case NET_XMIT_CN:
/* skb has been consumed */
+ pkt_dev->last_ok = 1;
pkt_dev->errors++;
break;
default: /* Drivers are not supposed to return other values! */
Yes, I like that the XMIT_CN then means to increment the seq_num, though for my own purposes,
I wouldn't want to increment the sofar++ in that case (and maybe not do other logic in that case),
since we know at least something dropped.
For fq-codel, seems that XMIT_CN could mean that the attempted packet actually was queued
for xmit, but at least some other packets were purged.
Thanks,
Ben
This does fix the crash for me (my patch in my tree is slightly different, but same idea).
Thanks,
Ben