* Calling can_free_echo_skb() from interrupt causes WARN
@ 2014-09-30 4:21 Thomas Körper
2014-10-29 21:00 ` Oliver Hartkopp
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Körper @ 2014-09-30 4:21 UTC (permalink / raw)
To: linux-can@vger.kernel.org
Hi linux-can,
I'm working on a new driver for one of our CAN cards.
In the TX error interrupt I call can_free_echo_skb(), but I get a warning and stack trace then. I'd say its kfree_skb() must not be called from interrupt context - replacing it by dev_kfree_skb_any() seems to fix it.
But I'm not the first one calling can_free_echo_skb() from interrupt... so, what am I missing?
Regards,
Thomas
[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360717] Modules linked in: can_raw esd402(O) can_dev(O) can arc4 md4 nls_utf8 cifs nfsv3 i915 nfsd auth_rpcgss nfs_acl rfcomm bnep nfs bluetooth hisax lockd video drm_kms_helper sunrpc drm coretemp kvm isdn fscache dell_wmi gpio_ich sparse_keymap i2c_algo_bit crc_ccitt binfmt_misc dcdbas lpc_ich serio_raw wmi mac_hid parport_pc ppdev lp parport hid_generic usbhid hid r8169 e1000e mii psmouse ptp pps_core
[ 1153.360754] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G O 3.17.0-rc4+ #1
[ 1153.360756] Hardware name: Dell Inc. OptiPlex 760 /0M858N, BIOS A05 08/17/2009
[ 1153.360760] 00000000 00000000 f580dedc c167906f 00000000 f580df0c c105bb7e c187cf30
[ 1153.360764] 00000000 0000001f c1911ffb 00000233 c158b909 c158b909 f4e1a600 00000003
[ 1153.360768] f4e1a600 f580df1c c105bc42 00000009 00000000 f580df28 c158b909 f4e1a600
[ 1153.360772] Call Trace:
[ 1153.360778] [<c167906f>] dump_stack+0x41/0x52
[ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
[ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30
[ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0
[ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30
[ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80
[ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
[ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50
[ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110
[ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90
[ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0
[ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34
[ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0
[ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0
[ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0
[ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370
[ 1153.360847] [<c167c723>] schedule+0x23/0x60
[ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460
[ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
[ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0
[ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30
[ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Calling can_free_echo_skb() from interrupt causes WARN
2014-09-30 4:21 Calling can_free_echo_skb() from interrupt causes WARN Thomas Körper
@ 2014-10-29 21:00 ` Oliver Hartkopp
2014-10-30 4:11 ` AW: " Thomas Körper
0 siblings, 1 reply; 4+ messages in thread
From: Oliver Hartkopp @ 2014-10-29 21:00 UTC (permalink / raw)
To: Thomas Körper, linux-can@vger.kernel.org
Hi Thomas,
did you fix this - or do we need to change it in can_free_echo_skb() globally?
Regards,
Oliver
On 30.09.2014 06:21, Thomas Körper wrote:
> Hi linux-can,
>
> I'm working on a new driver for one of our CAN cards.
>
> In the TX error interrupt I call can_free_echo_skb(), but I get a warning and stack trace then. I'd say its kfree_skb() must not be called from interrupt context - replacing it by dev_kfree_skb_any() seems to fix it.
>
> But I'm not the first one calling can_free_echo_skb() from interrupt... so, what am I missing?
>
>
> Regards,
> Thomas
>
>
> [ 1153.360705] ------------[ cut here ]------------
> [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
> [ 1153.360717] Modules linked in: can_raw esd402(O) can_dev(O) can arc4 md4 nls_utf8 cifs nfsv3 i915 nfsd auth_rpcgss nfs_acl rfcomm bnep nfs bluetooth hisax lockd video drm_kms_helper sunrpc drm coretemp kvm isdn fscache dell_wmi gpio_ich sparse_keymap i2c_algo_bit crc_ccitt binfmt_misc dcdbas lpc_ich serio_raw wmi mac_hid parport_pc ppdev lp parport hid_generic usbhid hid r8169 e1000e mii psmouse ptp pps_core
> [ 1153.360754] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G O 3.17.0-rc4+ #1
> [ 1153.360756] Hardware name: Dell Inc. OptiPlex 760 /0M858N, BIOS A05 08/17/2009
> [ 1153.360760] 00000000 00000000 f580dedc c167906f 00000000 f580df0c c105bb7e c187cf30
> [ 1153.360764] 00000000 0000001f c1911ffb 00000233 c158b909 c158b909 f4e1a600 00000003
> [ 1153.360768] f4e1a600 f580df1c c105bc42 00000009 00000000 f580df28 c158b909 f4e1a600
> [ 1153.360772] Call Trace:
> [ 1153.360778] [<c167906f>] dump_stack+0x41/0x52
> [ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
> [ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
> [ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
> [ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30
> [ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0
> [ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30
> [ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80
> [ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
> [ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
> [ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
> [ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
> [ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
> [ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50
> [ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
> [ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110
> [ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90
> [ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0
> [ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34
> [ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0
> [ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0
> [ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0
> [ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
> [ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370
> [ 1153.360847] [<c167c723>] schedule+0x23/0x60
> [ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460
> [ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
> [ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
> [ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0
> [ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30
> [ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110
> [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* AW: Calling can_free_echo_skb() from interrupt causes WARN
2014-10-29 21:00 ` Oliver Hartkopp
@ 2014-10-30 4:11 ` Thomas Körper
2014-10-30 20:37 ` Oliver Hartkopp
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Körper @ 2014-10-30 4:11 UTC (permalink / raw)
To: Oliver Hartkopp, linux-can@vger.kernel.org
Hi Oliver,
not fixed. I think it should be changed - but as mentioned, I don't understand why this never happened before / someone else.
Regards,
Thomas
-----Ursprüngliche Nachricht-----
Von: Oliver Hartkopp [mailto:socketcan@hartkopp.net]
Gesendet: Mittwoch, 29. Oktober 2014 22:00
An: Thomas Körper; linux-can@vger.kernel.org
Betreff: Re: Calling can_free_echo_skb() from interrupt causes WARN
Hi Thomas,
did you fix this - or do we need to change it in can_free_echo_skb() globally?
Regards,
Oliver
On 30.09.2014 06:21, Thomas Körper wrote:
> Hi linux-can,
>
> I'm working on a new driver for one of our CAN cards.
>
> In the TX error interrupt I call can_free_echo_skb(), but I get a warning and stack trace then. I'd say its kfree_skb() must not be called from interrupt context - replacing it by dev_kfree_skb_any() seems to fix it.
>
> But I'm not the first one calling can_free_echo_skb() from interrupt... so, what am I missing?
>
>
> Regards,
> Thomas
>
>
> [ 1153.360705] ------------[ cut here ]------------
> [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
> [ 1153.360717] Modules linked in: can_raw esd402(O) can_dev(O) can arc4 md4 nls_utf8 cifs nfsv3 i915 nfsd auth_rpcgss nfs_acl rfcomm bnep nfs bluetooth hisax lockd video drm_kms_helper sunrpc drm coretemp kvm isdn fscache dell_wmi gpio_ich sparse_keymap i2c_algo_bit crc_ccitt binfmt_misc dcdbas lpc_ich serio_raw wmi mac_hid parport_pc ppdev lp parport hid_generic usbhid hid r8169 e1000e mii psmouse ptp pps_core
> [ 1153.360754] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G O 3.17.0-rc4+ #1
> [ 1153.360756] Hardware name: Dell Inc. OptiPlex 760 /0M858N, BIOS A05 08/17/2009
> [ 1153.360760] 00000000 00000000 f580dedc c167906f 00000000 f580df0c c105bb7e c187cf30
> [ 1153.360764] 00000000 0000001f c1911ffb 00000233 c158b909 c158b909 f4e1a600 00000003
> [ 1153.360768] f4e1a600 f580df1c c105bc42 00000009 00000000 f580df28 c158b909 f4e1a600
> [ 1153.360772] Call Trace:
> [ 1153.360778] [<c167906f>] dump_stack+0x41/0x52
> [ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
> [ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
> [ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
> [ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30
> [ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0
> [ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30
> [ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80
> [ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
> [ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
> [ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
> [ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
> [ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
> [ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50
> [ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
> [ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110
> [ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90
> [ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0
> [ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34
> [ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0
> [ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0
> [ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0
> [ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
> [ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370
> [ 1153.360847] [<c167c723>] schedule+0x23/0x60
> [ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460
> [ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
> [ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
> [ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0
> [ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30
> [ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110
> [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: AW: Calling can_free_echo_skb() from interrupt causes WARN
2014-10-30 4:11 ` AW: " Thomas Körper
@ 2014-10-30 20:37 ` Oliver Hartkopp
0 siblings, 0 replies; 4+ messages in thread
From: Oliver Hartkopp @ 2014-10-30 20:37 UTC (permalink / raw)
To: Thomas Körper, linux-can@vger.kernel.org
Maybe other driver did not had this case to remove the echo skb inside the
error handling - or they did not test it like this - or the debugging was not
enabled ;-)
Don't know.
Would you like to send a patch - as you discovered the issue?
Regards,
Oliver
On 10/30/2014 05:11 AM, Thomas Körper wrote:
> Hi Oliver,
>
> not fixed. I think it should be changed - but as mentioned, I don't understand why this never happened before / someone else.
>
>
> Regards,
> Thomas
>
>
> -----Ursprüngliche Nachricht-----
> Von: Oliver Hartkopp [mailto:socketcan@hartkopp.net]
> Gesendet: Mittwoch, 29. Oktober 2014 22:00
> An: Thomas Körper; linux-can@vger.kernel.org
> Betreff: Re: Calling can_free_echo_skb() from interrupt causes WARN
>
> Hi Thomas,
>
> did you fix this - or do we need to change it in can_free_echo_skb() globally?
>
> Regards,
> Oliver
>
> On 30.09.2014 06:21, Thomas Körper wrote:
>> Hi linux-can,
>>
>> I'm working on a new driver for one of our CAN cards.
>>
>> In the TX error interrupt I call can_free_echo_skb(), but I get a warning and stack trace then. I'd say its kfree_skb() must not be called from interrupt context - replacing it by dev_kfree_skb_any() seems to fix it.
>>
>> But I'm not the first one calling can_free_echo_skb() from interrupt... so, what am I missing?
>>
>>
>> Regards,
>> Thomas
>>
>>
>> [ 1153.360705] ------------[ cut here ]------------
>> [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
>> [ 1153.360717] Modules linked in: can_raw esd402(O) can_dev(O) can arc4 md4 nls_utf8 cifs nfsv3 i915 nfsd auth_rpcgss nfs_acl rfcomm bnep nfs bluetooth hisax lockd video drm_kms_helper sunrpc drm coretemp kvm isdn fscache dell_wmi gpio_ich sparse_keymap i2c_algo_bit crc_ccitt binfmt_misc dcdbas lpc_ich serio_raw wmi mac_hid parport_pc ppdev lp parport hid_generic usbhid hid r8169 e1000e mii psmouse ptp pps_core
>> [ 1153.360754] CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: G O 3.17.0-rc4+ #1
>> [ 1153.360756] Hardware name: Dell Inc. OptiPlex 760 /0M858N, BIOS A05 08/17/2009
>> [ 1153.360760] 00000000 00000000 f580dedc c167906f 00000000 f580df0c c105bb7e c187cf30
>> [ 1153.360764] 00000000 0000001f c1911ffb 00000233 c158b909 c158b909 f4e1a600 00000003
>> [ 1153.360768] f4e1a600 f580df1c c105bc42 00000009 00000000 f580df28 c158b909 f4e1a600
>> [ 1153.360772] Call Trace:
>> [ 1153.360778] [<c167906f>] dump_stack+0x41/0x52
>> [ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
>> [ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
>> [ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0
>> [ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30
>> [ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0
>> [ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30
>> [ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80
>> [ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
>> [ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
>> [ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
>> [ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
>> [ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
>> [ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50
>> [ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
>> [ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110
>> [ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90
>> [ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0
>> [ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34
>> [ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0
>> [ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0
>> [ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0
>> [ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
>> [ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370
>> [ 1153.360847] [<c167c723>] schedule+0x23/0x60
>> [ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460
>> [ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
>> [ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
>> [ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0
>> [ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30
>> [ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110
>> [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-30 20:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-30 4:21 Calling can_free_echo_skb() from interrupt causes WARN Thomas Körper
2014-10-29 21:00 ` Oliver Hartkopp
2014-10-30 4:11 ` AW: " Thomas Körper
2014-10-30 20:37 ` Oliver Hartkopp
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).