Re: Ieee802154 socket problem with SIOCGIFADDR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've applied your patch properly.

By using your example this is what I have with kernel 4.0.2 for
beagleboneblack

[   44.362497] NET: Registered protocol family 36
[   44.369646] RTNL: assertion failed at net/mac802154/iface.c (65)
[   44.375894] CPU: 0 PID: 1166 Comm: a.out Not tainted 4.0.2-bone1 #1
[   44.375917] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 44.376010] [<c0011f55>] (unwind_backtrace) from [<c00101c9>] (show_stack+0x11/0x14) [ 44.376126] [<c00101c9>] (show_stack) from [<bf8982fb>] (mac802154_wpan_ioctl+0xbe/0x10c [mac802154]) [ 44.376237] [<bf8982fb>] (mac802154_wpan_ioctl [mac802154]) from [<bf8ac38f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket]) [ 44.376311] [<bf8ac38f>] (ieee802154_sock_ioctl [ieee802154_socket]) from [<c051996b>] (sock_ioctl+0xd3/0x1bc) [ 44.376360] [<c051996b>] (sock_ioctl) from [<c00fcad9>] (do_vfs_ioctl+0x2cd/0x400) [ 44.376398] [<c00fcad9>] (do_vfs_ioctl) from [<c00fcc59>] (SyS_ioctl+0x4d/0x58) [ 44.376436] [<c00fcc59>] (SyS_ioctl) from [<c000d641>] (ret_fast_syscall+0x1/0x44)

It is just using the code that you sent me yesterday.

Matteo


On 11/05/2015 19:51, Alexander Aring wrote:
On Mon, May 11, 2015 at 06:43:25PM +0200, Matteo Petracca wrote:
Hi,
I've applied your patch, but I ma still getting error:

.353646] Hardware name: Generic AM33XX (Flattened Device Tree)
[   88.353742] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
(show_stack+0x11/0x14)
[   88.353870] [<c00101b5>] (show_stack) from [<bf8292fb>]
(mac802154_wpan_ioctl+0xbe/0x10c [mac802154])
[   88.353974] [<bf8292fb>] (mac802154_wpan_ioctl [mac802154]) from
[<bf8a138f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[   88.354059] [<bf8a138f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
[<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[   88.354109] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
(do_vfs_ioctl+0x2cd/0x400)
[   88.354148] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
(SyS_ioctl+0x4d/0x58)
[   88.354188] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
(ret_fast_syscall+0x1/0x44)
maybe you did the wrong order and call rtnl_lock() after
spin_lock_bh(&sdata->mib_lock). When I do that then I get the following:

[   35.581616] ------------[ cut here ]------------
[   35.586553] WARNING: CPU: 0 PID: 1236 at kernel/locking/mutex.c:734 __mutex_unlock_slowpath+0x180/0x1a4()
[   35.596767] DEBUG_LOCKS_WARN_ON(in_interrupt())
[   35.601392] Modules linked in:
[   35.604814] CPU: 0 PID: 1236 Comm: a.out Not tainted 4.1.0-rc1-00069-g1add156-dirty #856
[   35.613322] Hardware name: Generic AM33XX (Flattened Device Tree)
[   35.619777] [<c0016534>] (unwind_backtrace) from [<c001308c>] (show_stack+0x10/0x14)
[   35.627906] [<c001308c>] (show_stack) from [<c0638800>] (dump_stack+0x84/0x9c)
[   35.635542] [<c0638800>] (dump_stack) from [<c003ffc4>] (warn_slowpath_common+0x7c/0xb8)
[   35.644069] [<c003ffc4>] (warn_slowpath_common) from [<c0040030>] (warn_slowpath_fmt+0x30/0x40)
[   35.653237] [<c0040030>] (warn_slowpath_fmt) from [<c063d6d4>] (__mutex_unlock_slowpath+0x180/0x1a4)
[   35.662867] [<c063d6d4>] (__mutex_unlock_slowpath) from [<c04ec874>] (netdev_run_todo+0x38/0x2a0)
[   35.672243] [<c04ec874>] (netdev_run_todo) from [<c062c5f4>] (mac802154_wpan_ioctl+0x70/0x13c)
[   35.681324] [<c062c5f4>] (mac802154_wpan_ioctl) from [<c0628ecc>] (ieee802154_sock_ioctl+0x194/0x204)
[   35.691047] [<c0628ecc>] (ieee802154_sock_ioctl) from [<c04ccc54>] (sock_ioctl+0x1c8/0x2a4)
[   35.699856] [<c04ccc54>] (sock_ioctl) from [<c0159988>] (do_vfs_ioctl+0x408/0x670)
[   35.707799] [<c0159988>] (do_vfs_ioctl) from [<c0159c5c>] (SyS_ioctl+0x6c/0x7c)
[   35.715527] [<c0159c5c>] (SyS_ioctl) from [<c000f520>] (ret_fast_syscall+0x0/0x4c)
[   35.723507] ---[ end trace eba2e6f7e74c5074 ]---


So please check that your rtnl_lock() is before spin_lock_bh(&sdata->mib_lock).

I recently send patches to remove the pib/mib lock it's enough to
locking everything is locked over rtnl (which is fix behaviour when
somebody tries to ifup and set addresses at the same time) and the most
mib values are readonly while ifup. I hope this will reduce the current
locking complexity a lot.

- Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux