* kernel WARNING on skb_complete_tx_timestamp
@ 2015-04-11 1:34 Keller, Jacob E
2015-04-11 4:00 ` Eric Dumazet
0 siblings, 1 reply; 4+ messages in thread
From: Keller, Jacob E @ 2015-04-11 1:34 UTC (permalink / raw)
To: Richard Cochran (richardcochran@gmail.com); +Cc: netdev@vger.kernel.org
Hi Richard,
I don't know if you'd know this but I believe you're the best person to ask. If anyone else has an answer please feel free to chime in.
[ 2744.552823] Modules linked in: fm10k(OE) vxlan ip6_udp_tunnel udp_tunnel uio fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc openvswitch libcrc32c joydev x86_pkg_temp_thermal coretemp kvm_intel kvm mei_me crct10dif_pclmul crc32_pclmul wmi crc32c_intel mei ipmi_ssif iTCO_wdt iTCO_vendor_support ipmi_devintf ghash_clmulni_intel lpc_ich ipmi_si tpm_tis mfd_core tpm ipmi_msghandler ioatdma sb_edac shpchp edac_core i2c_i801 mgag200 drm_kms_helper ttm drm isci igb firewire_ohci firewire_core libsas ptp crc_itu_t dca scsi_transport_sas pps_core i2c_algo_bit [last unloaded: fm10k]
[ 2744.552896] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W OE 3.19.3-200.fc21.x86_64 #1
[ 2744.552899] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.8x23.060520140825 06/05/2014
[ 2744.552901] 0000000000000000 2f4c8b10ea3f9848 ffff88081ee03a38 ffffffff8176e215
[ 2744.552906] 0000000000000000 0000000000000000 ffff88081ee03a78 ffffffff8109bc1a
[ 2744.552910] ffff88081ee03c50 ffff88080e55fc00 ffff88080e55fc00 ffffffff81647c50
[ 2744.552914] Call Trace:
[ 2744.552917] <IRQ> [<ffffffff8176e215>] dump_stack+0x45/0x57
[ 2744.552931] [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0
[ 2744.552936] [<ffffffff81647c50>] ? skb_queue_purge+0x20/0x40
[ 2744.552941] [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20
[ 2744.552946] [<ffffffff81646911>] skb_release_head_state+0xe1/0xf0
[ 2744.552950] [<ffffffff81647b26>] skb_release_all+0x16/0x30
[ 2744.552954] [<ffffffff81647ba6>] kfree_skb+0x36/0x90
[ 2744.552958] [<ffffffff81647c50>] skb_queue_purge+0x20/0x40
[ 2744.552964] [<ffffffff81751f8d>] packet_sock_destruct+0x1d/0x90
[ 2744.552968] [<ffffffff81642053>] __sk_free+0x23/0x140
[ 2744.552973] [<ffffffff81642189>] sk_free+0x19/0x20
[ 2744.552977] [<ffffffff81647d60>] skb_complete_tx_timestamp+0x50/0x60
[ 2744.552988] [<ffffffffa02eee40>] fm10k_ts_tx_hwtstamp+0xd0/0x100 [fm10k]
[ 2744.552994] [<ffffffffa02e054e>] fm10k_1588_msg_pf+0x12e/0x140 [fm10k]
[ 2744.553002] [<ffffffffa02edf1d>] fm10k_tlv_msg_parse+0x8d/0xc0 [fm10k]
[ 2744.553010] [<ffffffffa02eb2d0>] fm10k_mbx_dequeue_rx+0x60/0xb0 [fm10k]
[ 2744.553016] [<ffffffffa02ebf98>] fm10k_sm_mbx_process+0x178/0x3c0 [fm10k]
[ 2744.553022] [<ffffffffa02e09ca>] fm10k_msix_mbx_pf+0xfa/0x360 [fm10k]
[ 2744.553030] [<ffffffff811030a7>] ? get_next_timer_interrupt+0x1f7/0x270
[ 2744.553036] [<ffffffff810f2a47>] handle_irq_event_percpu+0x77/0x1a0
[ 2744.553041] [<ffffffff810f2bab>] handle_irq_event+0x3b/0x60
[ 2744.553045] [<ffffffff810f5d6e>] handle_edge_irq+0x6e/0x120
[ 2744.553054] [<ffffffff81017414>] handle_irq+0x74/0x140
[ 2744.553061] [<ffffffff810bb54a>] ? atomic_notifier_call_chain+0x1a/0x20
[ 2744.553066] [<ffffffff8177777f>] do_IRQ+0x4f/0xf0
[ 2744.553072] [<ffffffff8177556d>] common_interrupt+0x6d/0x6d
[ 2744.553074] <EOI> [<ffffffff81609b16>] ? cpuidle_enter_state+0x66/0x160
[ 2744.553084] [<ffffffff81609b01>] ? cpuidle_enter_state+0x51/0x160
[ 2744.553087] [<ffffffff81609cf7>] cpuidle_enter+0x17/0x20
[ 2744.553092] [<ffffffff810de101>] cpu_startup_entry+0x321/0x3c0
[ 2744.553098] [<ffffffff81764497>] rest_init+0x77/0x80
[ 2744.553103] [<ffffffff81d4f02c>] start_kernel+0x4a4/0x4c5
[ 2744.553107] [<ffffffff81d4e120>] ? early_idt_handlers+0x120/0x120
[ 2744.553110] [<ffffffff81d4e4d7>] x86_64_start_reservations+0x2a/0x2c
[ 2744.553114] [<ffffffff81d4e62b>] x86_64_start_kernel+0x152/0x175
This occurs because of the WARN_ON in kfree_skb which results from sock_hold(sk) and sock_put(sk)
I have a driver (fm10k) which receives a notification of Tx timestamp via an IRQ, and then when I call skb_complete_tx_timestamp I get this warning. I believe this is a result of calling sk_free, which the description *says* is ok to call in any context.. but then we get this warning.
I'm really not sure exactly how this situation occurred. Eventually we call kfree_skb() while we are in irq context which results in the warning.
Regards,
Jake
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel WARNING on skb_complete_tx_timestamp
2015-04-11 1:34 kernel WARNING on skb_complete_tx_timestamp Keller, Jacob E
@ 2015-04-11 4:00 ` Eric Dumazet
2015-04-13 16:31 ` Keller, Jacob E
0 siblings, 1 reply; 4+ messages in thread
From: Eric Dumazet @ 2015-04-11 4:00 UTC (permalink / raw)
To: Keller, Jacob E
Cc: Richard Cochran (richardcochran@gmail.com),
netdev@vger.kernel.org
On Sat, 2015-04-11 at 01:34 +0000, Keller, Jacob E wrote:
> Hi Richard,
>
> I don't know if you'd know this but I believe you're the best person to ask. If anyone else has an answer please feel free to chime in.
>
> [ 2744.552823] Modules linked in: fm10k(OE) vxlan ip6_udp_tunnel udp_tunnel uio fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc openvswitch libcrc32c joydev x86_pkg_temp_thermal coretemp kvm_intel kvm mei_me crct10dif_pclmul crc32_pclmul wmi crc32c_intel mei ipmi_ssif iTCO_wdt iTCO_vendor_support ipmi_devintf ghash_clmulni_intel lpc_ich ipmi_si tpm_tis mfd_core tpm ipmi_msghandler ioatdma sb_edac shpchp edac_core i2c_i801 mgag200 drm_kms_helper ttm drm isci igb firewire_ohci firewire_core libsas ptp crc_itu_t dca scsi_transport_sas pps_core i2c_algo_bit [last unloaded: fm10k]
> [ 2744.552896] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W OE 3.19.3-200.fc21.x86_64 #1
> [ 2744.552899] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.8x23.060520140825 06/05/2014
> [ 2744.552901] 0000000000000000 2f4c8b10ea3f9848 ffff88081ee03a38 ffffffff8176e215
> [ 2744.552906] 0000000000000000 0000000000000000 ffff88081ee03a78 ffffffff8109bc1a
> [ 2744.552910] ffff88081ee03c50 ffff88080e55fc00 ffff88080e55fc00 ffffffff81647c50
> [ 2744.552914] Call Trace:
> [ 2744.552917] <IRQ> [<ffffffff8176e215>] dump_stack+0x45/0x57
> [ 2744.552931] [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0
> [ 2744.552936] [<ffffffff81647c50>] ? skb_queue_purge+0x20/0x40
> [ 2744.552941] [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20
> [ 2744.552946] [<ffffffff81646911>] skb_release_head_state+0xe1/0xf0
> [ 2744.552950] [<ffffffff81647b26>] skb_release_all+0x16/0x30
> [ 2744.552954] [<ffffffff81647ba6>] kfree_skb+0x36/0x90
> [ 2744.552958] [<ffffffff81647c50>] skb_queue_purge+0x20/0x40
> [ 2744.552964] [<ffffffff81751f8d>] packet_sock_destruct+0x1d/0x90
> [ 2744.552968] [<ffffffff81642053>] __sk_free+0x23/0x140
> [ 2744.552973] [<ffffffff81642189>] sk_free+0x19/0x20
> [ 2744.552977] [<ffffffff81647d60>] skb_complete_tx_timestamp+0x50/0x60
> [ 2744.552988] [<ffffffffa02eee40>] fm10k_ts_tx_hwtstamp+0xd0/0x100 [fm10k]
> [ 2744.552994] [<ffffffffa02e054e>] fm10k_1588_msg_pf+0x12e/0x140 [fm10k]
> [ 2744.553002] [<ffffffffa02edf1d>] fm10k_tlv_msg_parse+0x8d/0xc0 [fm10k]
> [ 2744.553010] [<ffffffffa02eb2d0>] fm10k_mbx_dequeue_rx+0x60/0xb0 [fm10k]
> [ 2744.553016] [<ffffffffa02ebf98>] fm10k_sm_mbx_process+0x178/0x3c0 [fm10k]
> [ 2744.553022] [<ffffffffa02e09ca>] fm10k_msix_mbx_pf+0xfa/0x360 [fm10k]
> [ 2744.553030] [<ffffffff811030a7>] ? get_next_timer_interrupt+0x1f7/0x270
> [ 2744.553036] [<ffffffff810f2a47>] handle_irq_event_percpu+0x77/0x1a0
> [ 2744.553041] [<ffffffff810f2bab>] handle_irq_event+0x3b/0x60
> [ 2744.553045] [<ffffffff810f5d6e>] handle_edge_irq+0x6e/0x120
> [ 2744.553054] [<ffffffff81017414>] handle_irq+0x74/0x140
> [ 2744.553061] [<ffffffff810bb54a>] ? atomic_notifier_call_chain+0x1a/0x20
> [ 2744.553066] [<ffffffff8177777f>] do_IRQ+0x4f/0xf0
> [ 2744.553072] [<ffffffff8177556d>] common_interrupt+0x6d/0x6d
> [ 2744.553074] <EOI> [<ffffffff81609b16>] ? cpuidle_enter_state+0x66/0x160
> [ 2744.553084] [<ffffffff81609b01>] ? cpuidle_enter_state+0x51/0x160
> [ 2744.553087] [<ffffffff81609cf7>] cpuidle_enter+0x17/0x20
> [ 2744.553092] [<ffffffff810de101>] cpu_startup_entry+0x321/0x3c0
> [ 2744.553098] [<ffffffff81764497>] rest_init+0x77/0x80
> [ 2744.553103] [<ffffffff81d4f02c>] start_kernel+0x4a4/0x4c5
> [ 2744.553107] [<ffffffff81d4e120>] ? early_idt_handlers+0x120/0x120
> [ 2744.553110] [<ffffffff81d4e4d7>] x86_64_start_reservations+0x2a/0x2c
> [ 2744.553114] [<ffffffff81d4e62b>] x86_64_start_kernel+0x152/0x175
>
> This occurs because of the WARN_ON in kfree_skb which results from sock_hold(sk) and sock_put(sk)
>
> I have a driver (fm10k) which receives a notification of Tx timestamp via an IRQ, and then when I call skb_complete_tx_timestamp I get this warning. I believe this is a result of calling sk_free, which the description *says* is ok to call in any context.. but then we get this warning.
>
> I'm really not sure exactly how this situation occurred. Eventually we call kfree_skb() while we are in irq context which results in the warning.
At first look, there are some issues with this driver.
fm10k_ts_tx_enqueue() is racy and seems also buggy, freeing wrong skb.
Could you try :
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
index
02008e976d186f754470340089f344e781e9bb04..070d4f0b3c03bb0e31e216eb82d00f4fdcb4ea9f 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
@@ -70,16 +70,15 @@ void fm10k_ts_tx_enqueue(struct fm10k_intfc
*interface, struct sk_buff *skb)
* if none are present then insert skb in tail of list
*/
skb = fm10k_ts_tx_skb(interface, FM10K_CB(clone)->fi.w.dglort);
- if (!skb)
+ if (!skb) {
+ skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
__skb_queue_tail(list, clone);
-
+ }
spin_unlock_irqrestore(&list->lock, flags);
/* if list is already has one then we just free the clone */
if (skb)
- kfree_skb(skb);
- else
- skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
+ kfree_skb(clone);
}
void fm10k_ts_tx_hwtstamp(struct fm10k_intfc *interface, __le16 dglort,
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel WARNING on skb_complete_tx_timestamp
2015-04-11 4:00 ` Eric Dumazet
@ 2015-04-13 16:31 ` Keller, Jacob E
2015-04-13 16:41 ` Keller, Jacob E
0 siblings, 1 reply; 4+ messages in thread
From: Keller, Jacob E @ 2015-04-13 16:31 UTC (permalink / raw)
To: eric.dumazet@gmail.com; +Cc: netdev@vger.kernel.org, richardcochran@gmail.com
Hi Eric,
On Fri, 2015-04-10 at 21:00 -0700, Eric Dumazet wrote:
> On Sat, 2015-04-11 at 01:34 +0000, Keller, Jacob E wrote:
> > Hi Richard,
> >
> > I don't know if you'd know this but I believe you're the best person to ask. If anyone else has an answer please feel free to chime in.
> >
> > [ 2744.552823] Modules linked in: fm10k(OE) vxlan ip6_udp_tunnel udp_tunnel uio fuse xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc openvswitch libcrc32c joydev x86_pkg_temp_thermal coretemp kvm_intel kvm mei_me crct10dif_pclmul crc32_pclmul wmi crc32c_intel mei ipmi_ssif iTCO_wdt iTCO_vendor_support ipmi_devintf ghash_clmulni_intel lpc_ich ipmi_si tpm_tis mfd_core tpm ipmi_msghandler ioatdma sb_edac shpchp edac_core i2c_i801 mgag200 drm_kms_helper ttm drm isci igb firewire_ohci firewire_core libsas ptp crc_itu_t dca scsi_transport_sas pps_core i2c_algo_bit [last unloaded: fm10k]
> > [ 2744.552896] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W OE 3.19.3-200.fc21.x86_64 #1
> > [ 2744.552899] Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.03.8x23.060520140825 06/05/2014
> > [ 2744.552901] 0000000000000000 2f4c8b10ea3f9848 ffff88081ee03a38 ffffffff8176e215
> > [ 2744.552906] 0000000000000000 0000000000000000 ffff88081ee03a78 ffffffff8109bc1a
> > [ 2744.552910] ffff88081ee03c50 ffff88080e55fc00 ffff88080e55fc00 ffffffff81647c50
> > [ 2744.552914] Call Trace:
> > [ 2744.552917] <IRQ> [<ffffffff8176e215>] dump_stack+0x45/0x57
> > [ 2744.552931] [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0
> > [ 2744.552936] [<ffffffff81647c50>] ? skb_queue_purge+0x20/0x40
> > [ 2744.552941] [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20
> > [ 2744.552946] [<ffffffff81646911>] skb_release_head_state+0xe1/0xf0
> > [ 2744.552950] [<ffffffff81647b26>] skb_release_all+0x16/0x30
> > [ 2744.552954] [<ffffffff81647ba6>] kfree_skb+0x36/0x90
> > [ 2744.552958] [<ffffffff81647c50>] skb_queue_purge+0x20/0x40
> > [ 2744.552964] [<ffffffff81751f8d>] packet_sock_destruct+0x1d/0x90
> > [ 2744.552968] [<ffffffff81642053>] __sk_free+0x23/0x140
> > [ 2744.552973] [<ffffffff81642189>] sk_free+0x19/0x20
> > [ 2744.552977] [<ffffffff81647d60>] skb_complete_tx_timestamp+0x50/0x60
> > [ 2744.552988] [<ffffffffa02eee40>] fm10k_ts_tx_hwtstamp+0xd0/0x100 [fm10k]
> > [ 2744.552994] [<ffffffffa02e054e>] fm10k_1588_msg_pf+0x12e/0x140 [fm10k]
> > [ 2744.553002] [<ffffffffa02edf1d>] fm10k_tlv_msg_parse+0x8d/0xc0 [fm10k]
> > [ 2744.553010] [<ffffffffa02eb2d0>] fm10k_mbx_dequeue_rx+0x60/0xb0 [fm10k]
> > [ 2744.553016] [<ffffffffa02ebf98>] fm10k_sm_mbx_process+0x178/0x3c0 [fm10k]
> > [ 2744.553022] [<ffffffffa02e09ca>] fm10k_msix_mbx_pf+0xfa/0x360 [fm10k]
> > [ 2744.553030] [<ffffffff811030a7>] ? get_next_timer_interrupt+0x1f7/0x270
> > [ 2744.553036] [<ffffffff810f2a47>] handle_irq_event_percpu+0x77/0x1a0
> > [ 2744.553041] [<ffffffff810f2bab>] handle_irq_event+0x3b/0x60
> > [ 2744.553045] [<ffffffff810f5d6e>] handle_edge_irq+0x6e/0x120
> > [ 2744.553054] [<ffffffff81017414>] handle_irq+0x74/0x140
> > [ 2744.553061] [<ffffffff810bb54a>] ? atomic_notifier_call_chain+0x1a/0x20
> > [ 2744.553066] [<ffffffff8177777f>] do_IRQ+0x4f/0xf0
> > [ 2744.553072] [<ffffffff8177556d>] common_interrupt+0x6d/0x6d
> > [ 2744.553074] <EOI> [<ffffffff81609b16>] ? cpuidle_enter_state+0x66/0x160
> > [ 2744.553084] [<ffffffff81609b01>] ? cpuidle_enter_state+0x51/0x160
> > [ 2744.553087] [<ffffffff81609cf7>] cpuidle_enter+0x17/0x20
> > [ 2744.553092] [<ffffffff810de101>] cpu_startup_entry+0x321/0x3c0
> > [ 2744.553098] [<ffffffff81764497>] rest_init+0x77/0x80
> > [ 2744.553103] [<ffffffff81d4f02c>] start_kernel+0x4a4/0x4c5
> > [ 2744.553107] [<ffffffff81d4e120>] ? early_idt_handlers+0x120/0x120
> > [ 2744.553110] [<ffffffff81d4e4d7>] x86_64_start_reservations+0x2a/0x2c
> > [ 2744.553114] [<ffffffff81d4e62b>] x86_64_start_kernel+0x152/0x175
> >
> > This occurs because of the WARN_ON in kfree_skb which results from sock_hold(sk) and sock_put(sk)
> >
> > I have a driver (fm10k) which receives a notification of Tx timestamp via an IRQ, and then when I call skb_complete_tx_timestamp I get this warning. I believe this is a result of calling sk_free, which the description *says* is ok to call in any context.. but then we get this warning.
> >
> > I'm really not sure exactly how this situation occurred. Eventually we call kfree_skb() while we are in irq context which results in the warning.
>
> At first look, there are some issues with this driver.
>
I should clarify here. I am working on fixing the issues with 1588 in
this driver. The actual panic I got wasn't on the same code as currently
in upstream. There are a lot of issues we're actively debugging now.
However, your suggestion below does seem like it still applies.
Hopefully the total set of fixes will be ready to post soon.
> fm10k_ts_tx_enqueue() is racy and seems also buggy, freeing wrong skb.
>
> Could you try :
>
> diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> index
> 02008e976d186f754470340089f344e781e9bb04..070d4f0b3c03bb0e31e216eb82d00f4fdcb4ea9f 100644
> --- a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> @@ -70,16 +70,15 @@ void fm10k_ts_tx_enqueue(struct fm10k_intfc
> *interface, struct sk_buff *skb)
> * if none are present then insert skb in tail of list
> */
> skb = fm10k_ts_tx_skb(interface, FM10K_CB(clone)->fi.w.dglort);
> - if (!skb)
> + if (!skb) {
> + skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
> __skb_queue_tail(list, clone);
> -
> + }
> spin_unlock_irqrestore(&list->lock, flags);
>
> /* if list is already has one then we just free the clone */
> if (skb)
> - kfree_skb(skb);
> - else
> - skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
> + kfree_skb(clone);
So free the clone instead of the original? I'm not entirely sure how
this changes the flow, but I will give this a shot.
Regards,
Jake
> }
>
> void fm10k_ts_tx_hwtstamp(struct fm10k_intfc *interface, __le16 dglort,
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: kernel WARNING on skb_complete_tx_timestamp
2015-04-13 16:31 ` Keller, Jacob E
@ 2015-04-13 16:41 ` Keller, Jacob E
0 siblings, 0 replies; 4+ messages in thread
From: Keller, Jacob E @ 2015-04-13 16:41 UTC (permalink / raw)
To: eric.dumazet@gmail.com; +Cc: netdev@vger.kernel.org, richardcochran@gmail.com
Hi,
On Mon, 2015-04-13 at 16:31 +0000, Keller, Jacob E wrote:
> Hi Eric,
> > > This occurs because of the WARN_ON in kfree_skb which results from sock_hold(sk) and sock_put(sk)
> > >
> > > I have a driver (fm10k) which receives a notification of Tx timestamp via an IRQ, and then when I call skb_complete_tx_timestamp I get this warning. I believe this is a result of calling sk_free, which the description *says* is ok to call in any context.. but then we get this warning.
> > >
> > > I'm really not sure exactly how this situation occurred. Eventually we call kfree_skb() while we are in irq context which results in the warning.
> >
> > At first look, there are some issues with this driver.
> >
>
> I should clarify here. I am working on fixing the issues with 1588 in
> this driver. The actual panic I got wasn't on the same code as currently
> in upstream. There are a lot of issues we're actively debugging now.
> However, your suggestion below does seem like it still applies.
> Hopefully the total set of fixes will be ready to post soon.
>
> > fm10k_ts_tx_enqueue() is racy and seems also buggy, freeing wrong skb.
> >
> > Could you try :
> >
> > diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> > b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> > index
> > 02008e976d186f754470340089f344e781e9bb04..070d4f0b3c03bb0e31e216eb82d00f4fdcb4ea9f 100644
> > --- a/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> > +++ b/drivers/net/ethernet/intel/fm10k/fm10k_ptp.c
> > @@ -70,16 +70,15 @@ void fm10k_ts_tx_enqueue(struct fm10k_intfc
> > *interface, struct sk_buff *skb)
> > * if none are present then insert skb in tail of list
> > */
> > skb = fm10k_ts_tx_skb(interface, FM10K_CB(clone)->fi.w.dglort);
> > - if (!skb)
> > + if (!skb) {
> > + skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
> > __skb_queue_tail(list, clone);
> > -
> > + }
> > spin_unlock_irqrestore(&list->lock, flags);
> >
> > /* if list is already has one then we just free the clone */
> > if (skb)
> > - kfree_skb(skb);
> > - else
> > - skb_shinfo(clone)->tx_flags |= SKBTX_IN_PROGRESS;
> > + kfree_skb(clone);
>
> So free the clone instead of the original? I'm not entirely sure how
> this changes the flow, but I will give this a shot.
>
> Regards,
> Jake
>
> > }
> >
> > void fm10k_ts_tx_hwtstamp(struct fm10k_intfc *interface, __le16 dglort,
> >
> >
> >
Turns out this was already applied on my test out-of-tree driver I found
the stack dump on. This does need to get posted to the list, but it
isn't the cause of the problem.
Regards,
Jake
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-13 16:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-11 1:34 kernel WARNING on skb_complete_tx_timestamp Keller, Jacob E
2015-04-11 4:00 ` Eric Dumazet
2015-04-13 16:31 ` Keller, Jacob E
2015-04-13 16:41 ` Keller, Jacob E
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).