Bug 13954
| Summary: | Oops in rtnetlink code when creating CAN device | ||
|---|---|---|---|
| Product: | Networking | Reporter: | Dmitry Baryshkov (dbaryshkov) |
| Component: | Other | Assignee: | Alexey Dobriyan (adobriyan) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | adobriyan, dbaryshkov |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.31-rc5 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Dmitry Baryshkov
2009-08-10 11:34:26 UTC
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13954 Thanks. > Summary: Oops in rtnetlink code when creating can device > Product: Networking > Version: 2.5 > Kernel Version: 2.6.30-rc5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: acme@ghostprotocols.net > ReportedBy: dbaryshkov@gmail.com > Regression: No > > > I've got a nice oops when looking around new CAN code in kernel. > > root@qemux86:~# ip link add type can > [ 713.113325] BUG: unable to handle kernel NULL pointer dereference at > (null) > [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420 > [ 713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000 > [ 713.115627] Oops: 0000 [#1] SMP > [ 713.115972] last sysfs file: > /sys/devices/virtual/backlight/fujitsu-laptop/brightness > [ 713.116137] Modules linked in: > [ 713.116137] > [ 713.116137] Pid: 1803, comm: ip Not tainted (2.6.31-rc5 #68) > [ 713.116137] EIP: 0060:[<c13eecab>] EFLAGS: 00000246 CPU: 0 > [ 713.116137] EIP is at register_netdevice+0xab/0x420 > [ 713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001 > [ 713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34 > [ 713.116137] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0 > task.ti=c61aa000) > [ 713.116137] Stack: > [ 713.116137] c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000 > c72c6000 > 00000000 > [ 713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090 > c61abc18 c6f3d028 > [ 713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46 > 00000008 c1546f80 > [ 713.116137] Call Trace: > [ 713.116137] [<c13f732f>] ? rtnl_create_link+0x4f/0x130 > [ 713.116137] [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0 > [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0 > [ 713.116137] [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0 > [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0 > [ 713.116137] [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220 > [ 713.116137] [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220 > [ 713.116137] [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0 > [ 713.116137] [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50 > [ 713.116137] [<c140085b>] ? netlink_unicast+0x29b/0x2b0 > [ 713.116137] [<c1400a5b>] ? netlink_sendmsg+0x1eb/0x2f0 > [ 713.116137] [<c13db72b>] ? sock_sendmsg+0xdb/0x110 > [ 713.116137] [<c10bef17>] ? __d_instantiate+0x57/0xe0 > [ 713.116137] [<c1053cd0>] ? autoremove_wake_function+0x0/0x60 > [ 713.116137] [<c110a75f>] ? ext3_lookup+0xaf/0x130 > [ 713.116137] [<c10bfd24>] ? d_alloc+0x114/0x1a0 > [ 713.116137] [<c10c5a95>] ? mntput_no_expire+0x25/0xe0 > [ 713.116137] [<c11b518e>] ? copy_from_user+0x3e/0x150 > [ 713.116137] [<c11b518e>] ? copy_from_user+0x3e/0x150 > [ 713.116137] [<c13e55cb>] ? verify_iovec+0x3b/0xc0 > [ 713.116137] [<c13db8b8>] ? sys_sendmsg+0x158/0x280 > [ 713.116137] [<c107a22c>] ? unlock_page+0x4c/0x70 > [ 713.116137] [<c108efb8>] ? __do_fault+0x378/0x470 > [ 713.116137] [<c10a81d3>] ? lookup_object+0x33/0x80 > [ 713.116137] [<c107a820>] ? filemap_fault+0x0/0x3c0 > [ 713.116137] [<c1029ba9>] ? kmemcheck_mark_freed+0x19/0x40 > [ 713.116137] [<c11b518e>] ? copy_from_user+0x3e/0x150 > [ 713.116137] [<c13dcd97>] ? sys_socketcall+0xb7/0x290 > [ 713.116137] [<c10230fa>] ? do_page_fault+0x18a/0x2a0 > [ 713.116137] [<c100324f>] ? sysenter_do_call+0x12/0x26 > [ 713.116137] Code: ff ff 3b 96 84 02 00 00 72 d6 8b 86 b4 00 00 00 c7 86 00 > 02 00 00 00 00 00 00 c7 86 04 02 00 00 ff ff ff ff c7 46 4c ff ff ff ff <8b> > 10 > 85 d2 74 2f 89 f0 ff d2 83 f8 00 89 c7 74 24 b8 fb ff ff > [ 713.116137] EIP: [<c13eecab>] register_netdevice+0xab/0x420 SS:ESP > 0068:c61abb34 > [ 713.116137] CR2: 0000000000000000 > [ 713.142874] ---[ end trace 883d4085b7c1045b ]--- > Boy, the backtrace is a bit hard to follow. Maybe enabling frame pointers would clean it up. The 'ip link add type can' is flawed with two problems: 1) all functions inside drivers/net/can/dev.c expect to have at least struct can_priv as device private. However can_link_ops doesn't declare .priv_size field. 2) Nearly the same problem that bite me in this trace: can_setup didn't provide netdev->netdev_ops field, however register_netdevice (the function that crashed) doesn't check for ops existance (!= NULL) and so crashed at ->ndo_init Reply-To: oliver.hartkopp@volkswagen.de Andrew Morton wrote: > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > > >> http://bugzilla.kernel.org/show_bug.cgi?id=13954 >> > > Thanks. > > >> Summary: Oops in rtnetlink code when creating can device >> Product: Networking >> Version: 2.5 >> Kernel Version: 2.6.30-rc5 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: Other >> AssignedTo: acme@ghostprotocols.net >> ReportedBy: dbaryshkov@gmail.com >> Regression: No >> >> >> I've got a nice oops when looking around new CAN code in kernel. >> >> root@qemux86:~# ip link add type can >> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference at >> (null) >> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420 >> [ 713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000 >> [ 713.115627] Oops: 0000 [#1] SMP >> [ 713.115972] last sysfs file: >> /sys/devices/virtual/backlight/fujitsu-laptop/brightness >> [ 713.116137] Modules linked in: >> [ 713.116137] >> [ 713.116137] Pid: 1803, comm: ip Not tainted (2.6.31-rc5 #68) >> [ 713.116137] EIP: 0060:[<c13eecab>] EFLAGS: 00000246 CPU: 0 >> [ 713.116137] EIP is at register_netdevice+0xab/0x420 >> [ 713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001 >> [ 713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34 >> [ 713.116137] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 >> [ 713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0 >> task.ti=c61aa000) >> [ 713.116137] Stack: >> [ 713.116137] c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000 >> c72c6000 >> 00000000 >> [ 713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090 >> c61abc18 c6f3d028 >> [ 713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46 >> 00000008 c1546f80 >> [ 713.116137] Call Trace: >> [ 713.116137] [<c13f732f>] ? rtnl_create_link+0x4f/0x130 >> [ 713.116137] [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0 >> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0 >> [ 713.116137] [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0 >> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0 >> [ 713.116137] [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220 >> [ 713.116137] [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220 >> [ 713.116137] [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0 >> [ 713.116137] [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50 >> The problem is, that ip link add type can is not possible as you can not create 'real' CAN devices like can0, can1, ... To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use ip link add type vcan see drivers/net/can/vcan.c --- For real hardware CAN devices the netlink interface is only used for the configuration of already existing interfaces. From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c i was not able to find any method to disallow the creation of interfaces, will say: How can a netlink user provide the information, that he's not able to create new devices via netlink??? @Patrick: Do you have an idea for this? Is it a new use-case for netlink that needs to be implemented? Regards, Oliver Oliver Hartkopp wrote:
>>> I've got a nice oops when looking around new CAN code in kernel.
>>>
>>> root@qemux86:~# ip link add type can
>>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference
>>> at (null)
>>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420
>>> ...
> The problem is, that
>
> ip link add type can
>
> is not possible as you can not create 'real' CAN devices like can0,
> can1, ...
>
> To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use
>
> ip link add type vcan
>
> see drivers/net/can/vcan.c
>
> ---
>
> For real hardware CAN devices the netlink interface is only used for the
> configuration of already existing interfaces.
> From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c
> i was not able to find any method to disallow the creation of
> interfaces, will say: How can a netlink user provide the information,
> that he's not able to create new devices via netlink???
>
> @Patrick: Do you have an idea for this? Is it a new use-case for netlink
> that needs to be implemented?
You could add a ->newlink() function that unconditionally returns
an error.
Reply-To: oliver.hartkopp@volkswagen.de Patrick McHardy wrote: > Oliver Hartkopp wrote: > >>>> I've got a nice oops when looking around new CAN code in kernel. >>>> >>>> root@qemux86:~# ip link add type can >>>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference >>>> at (null) >>>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420 >>>> ... >>>> >> The problem is, that >> >> ip link add type can >> >> is not possible as you can not create 'real' CAN devices like can0, >> can1, ... >> >> To create 'software CAN devices' like vcan0, vcan1, vcan2, ... we use >> >> ip link add type vcan >> >> see drivers/net/can/vcan.c >> >> --- >> >> For real hardware CAN devices the netlink interface is only used for the >> configuration of already existing interfaces. >> From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c >> i was not able to find any method to disallow the creation of >> interfaces, will say: How can a netlink user provide the information, >> that he's not able to create new devices via netlink??? >> >> @Patrick: Do you have an idea for this? Is it a new use-case for netlink >> that needs to be implemented? >> > > You could add a ->newlink() function that unconditionally returns > an error. > > Yes, that fixed it. I created a can_newlink() function just returning -EINVAL ... I'll cook a patch and send it on netdev (when it gets online again). Thanks (to all), Oliver Oliver Hartkopp wrote:
>>> For real hardware CAN devices the netlink interface is only used for the
>>> configuration of already existing interfaces.
>>> From a quick view on the rtnl_newlink() function in net/core/rtnetlink.c
>>> i was not able to find any method to disallow the creation of
>>> interfaces, will say: How can a netlink user provide the information,
>>> that he's not able to create new devices via netlink???
>>>
>>> @Patrick: Do you have an idea for this? Is it a new use-case for netlink
>>> that needs to be implemented?
>>>
>>
>> You could add a ->newlink() function that unconditionally returns
>> an error.
>>
>>
>
> Yes, that fixed it.
>
> I created a can_newlink() function just returning -EINVAL ...
>
> I'll cook a patch and send it on netdev (when it gets online again).
I'd suggest to use EOPNOTSUPP for consistency.
Reply-To: oliver.hartkopp@volkswagen.de Patrick McHardy wrote: > >>> You could add a ->newlink() function that unconditionally returns >>> an error. >>> >>> >>> >> Yes, that fixed it. >> >> I created a can_newlink() function just returning -EINVAL ... >> >> I'll cook a patch and send it on netdev (when it gets online again). >> > > I'd suggest to use EOPNOTSUPP for consistency. > > Ok. Will do so. Thanks! Oliver Reply-To: oliver@hartkopp.net Oliver Hartkopp wrote: > Andrew Morton wrote: >> (switched to email. Please respond via emailed reply-to-all, not via the >> bugzilla web interface). >> >> On Mon, 10 Aug 2009 11:34:28 GMT bugzilla-daemon@bugzilla.kernel.org >> wrote: >> >> >>> http://bugzilla.kernel.org/show_bug.cgi?id=13954 >>> >> >> Thanks. >> >> >>> Summary: Oops in rtnetlink code when creating can device >>> Product: Networking >>> Version: 2.5 >>> Kernel Version: 2.6.30-rc5 >>> Platform: All >>> OS/Version: Linux >>> Tree: Mainline >>> Status: NEW >>> Severity: normal >>> Priority: P1 >>> Component: Other >>> AssignedTo: acme@ghostprotocols.net >>> ReportedBy: dbaryshkov@gmail.com >>> Regression: No >>> >>> >>> I've got a nice oops when looking around new CAN code in kernel. >>> >>> root@qemux86:~# ip link add type can >>> [ 713.113325] BUG: unable to handle kernel NULL pointer dereference >>> at (null) >>> [ 713.114216] IP: [<c13eecab>] register_netdevice+0xab/0x420 >>> [ 713.114920] *pdpt = 00000000061bd001 *pde = 0000000000000000 [ >>> 713.115627] Oops: 0000 [#1] SMP [ 713.115972] last sysfs file: >>> /sys/devices/virtual/backlight/fujitsu-laptop/brightness >>> [ 713.116137] Modules linked in: >>> [ 713.116137] [ 713.116137] Pid: 1803, comm: ip Not tainted >>> (2.6.31-rc5 #68) [ 713.116137] EIP: 0060:[<c13eecab>] EFLAGS: >>> 00000246 CPU: 0 >>> [ 713.116137] EIP is at register_netdevice+0xab/0x420 >>> [ 713.116137] EAX: 00000000 EBX: 00000000 ECX: 00000001 EDX: 00000001 >>> [ 713.116137] ESI: c72c6000 EDI: 00000000 EBP: c61abb54 ESP: c61abb34 >>> [ 713.116137] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 >>> [ 713.116137] Process ip (pid: 1803, ti=c61aa000 task=c6f395e0 >>> task.ti=c61aa000) >>> [ 713.116137] Stack: >>> [ 713.116137] c61abb54 c13f732f 00000001 c61abbb4 894f908a 00000000 >>> c72c6000 >>> 00000000 >>> [ 713.116137] <0> c61abc74 c13f8278 c61abbb4 00000010 c165d494 c1652090 >>> c61abc18 c6f3d028 >>> [ 713.116137] <0> 894f908a 894f908a c61abc18 c13f7da0 c61abc74 c13f7f46 >>> 00000008 c1546f80 >>> [ 713.116137] Call Trace: >>> [ 713.116137] [<c13f732f>] ? rtnl_create_link+0x4f/0x130 >>> [ 713.116137] [<c13f8278>] ? rtnl_newlink+0x4d8/0x4e0 >>> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0 >>> [ 713.116137] [<c13f7f46>] ? rtnl_newlink+0x1a6/0x4e0 >>> [ 713.116137] [<c13f7da0>] ? rtnl_newlink+0x0/0x4e0 >>> [ 713.116137] [<c13f7d00>] ? rtnetlink_rcv_msg+0x180/0x220 >>> [ 713.116137] [<c13f7b80>] ? rtnetlink_rcv_msg+0x0/0x220 >>> [ 713.116137] [<c1400e56>] ? netlink_rcv_skb+0x86/0xb0 >>> [ 713.116137] [<c13f7b5a>] ? rtnetlink_rcv+0x2a/0x50 >>> > Just to close this issue: The patch has just been committed by Dave to net-2.6 for 2.6.31 upstream ... http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=993e6f2fd487e2acddd711f79cf48f3420731382 Thanks to all of you. Oliver |