Ieee802154 socket problem with SIOCGIFADDR

Ieee802154 socket problem with SIOCGIFADDR

[Matteo Petracca]

Dear all,
I am working on a BeagleboneBlack with transceiver at86rf233.

When using ieee802154 sockets in my code I have:

ret = ioctl(socketfd, SIOCGIFADDR, &ifr);

and everything works fine with kernel 3.8.13.

In kernel 4.0.1 the request fails with the following kernel messages:

[  846.038365] RTNL: assertion failed at net/mac802154/iface.c (65)
[  846.044629] CPU: 0 PID: 2350 Comm: test Not tainted 4.0.1-bone1 #1
[  846.044653] Hardware name: Generic AM33XX (Flattened Device Tree)
[  846.044747] [<c0011f35>] (unwind_backtrace) from [<c00101b5>] 
(show_stack+0x11/0x14)
[  846.044876] [<c00101b5>] (show_stack) from [<bf8502f3>] 
(mac802154_wpan_ioctl+0xb6/0x100 [mac802154])
[  846.044972] [<bf8502f3>] (mac802154_wpan_ioctl [mac802154]) from 
[<bf8b738f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
[  846.045044] [<bf8b738f>] (ieee802154_sock_ioctl [ieee802154_socket]) 
from [<c05195fb>] (sock_ioctl+0xd3/0x1bc)
[  846.045094] [<c05195fb>] (sock_ioctl) from [<c00fca4d>] 
(do_vfs_ioctl+0x2cd/0x400)
[  846.045133] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>] 
(SyS_ioctl+0x4d/0x58)
[  846.045172] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>] 
(ret_fast_syscall+0x1/0x44)

Do you have any idea how to solve the problem?

Best,
Matteo

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

Hi,

On Sat, May 09, 2015 at 04:41:22PM +0200, Matteo Petracca wrote:
> Dear all,
> I am working on a BeagleboneBlack with transceiver at86rf233.
> 
> When using ieee802154 sockets in my code I have:
> 
> ret = ioctl(socketfd, SIOCGIFADDR, &ifr);
> 
> and everything works fine with kernel 3.8.13.
> 
> In kernel 4.0.1 the request fails with the following kernel messages:
> 
> [  846.038365] RTNL: assertion failed at net/mac802154/iface.c (65)
> [  846.044629] CPU: 0 PID: 2350 Comm: test Not tainted 4.0.1-bone1 #1
> [  846.044653] Hardware name: Generic AM33XX (Flattened Device Tree)
> [  846.044747] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
> (show_stack+0x11/0x14)
> [  846.044876] [<c00101b5>] (show_stack) from [<bf8502f3>]
> (mac802154_wpan_ioctl+0xb6/0x100 [mac802154])
> [  846.044972] [<bf8502f3>] (mac802154_wpan_ioctl [mac802154]) from
> [<bf8b738f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
> [  846.045044] [<bf8b738f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
> [<c05195fb>] (sock_ioctl+0xd3/0x1bc)
> [  846.045094] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
> (do_vfs_ioctl+0x2cd/0x400)
> [  846.045133] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
> (SyS_ioctl+0x4d/0x58)
> [  846.045172] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
> (ret_fast_syscall+0x1/0x44)
> 
> Do you have any idea how to solve the problem?
> 

I did this assertion there because I supposed that the rtnl lock is hold
while calling this callback. Now I see it isn't...

We need to hold the rtnl lock there because we accessing the mib values.

Try this:

diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
index 91b75ab..2a58788 100644
--- a/net/mac802154/iface.c
+++ b/net/mac802154/iface.c
@@ -62,8 +62,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
                (struct sockaddr_ieee802154 *)&ifr->ifr_addr;
        int err = -ENOIOCTLCMD;
 
-       ASSERT_RTNL();
-
+       rtnl_lock();
        spin_lock_bh(&sdata->mib_lock);
 
        switch (cmd) {
@@ -90,6 +89,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
        case SIOCSIFADDR:
                if (netif_running(dev)) {
                        spin_unlock_bh(&sdata->mib_lock);
+                       rtnl_unlock();
                        return -EBUSY;
                }
 
@@ -112,6 +112,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
        }
 
        spin_unlock_bh(&sdata->mib_lock);
+       rtnl_unlock();
        return err;
 }


I will put it in my queue for next patch series to remove the mib/pib
spinlocks. We have only the rtnl lock now.

- Alex

Re: Ieee802154 socket problem with SIOCGIFADDR

[Matteo Petracca]

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)

Matteo

On 09/05/2015 18:42, Alexander Aring wrote:
> Hi,
>
> On Sat, May 09, 2015 at 04:41:22PM +0200, Matteo Petracca wrote:
>> Dear all,
>> I am working on a BeagleboneBlack with transceiver at86rf233.
>>
>> When using ieee802154 sockets in my code I have:
>>
>> ret = ioctl(socketfd, SIOCGIFADDR, &ifr);
>>
>> and everything works fine with kernel 3.8.13.
>>
>> In kernel 4.0.1 the request fails with the following kernel messages:
>>
>> [  846.038365] RTNL: assertion failed at net/mac802154/iface.c (65)
>> [  846.044629] CPU: 0 PID: 2350 Comm: test Not tainted 4.0.1-bone1 #1
>> [  846.044653] Hardware name: Generic AM33XX (Flattened Device Tree)
>> [  846.044747] [<c0011f35>] (unwind_backtrace) from [<c00101b5>]
>> (show_stack+0x11/0x14)
>> [  846.044876] [<c00101b5>] (show_stack) from [<bf8502f3>]
>> (mac802154_wpan_ioctl+0xb6/0x100 [mac802154])
>> [  846.044972] [<bf8502f3>] (mac802154_wpan_ioctl [mac802154]) from
>> [<bf8b738f>] (ieee802154_sock_ioctl+0xf6/0x14c [ieee802154_socket])
>> [  846.045044] [<bf8b738f>] (ieee802154_sock_ioctl [ieee802154_socket]) from
>> [<c05195fb>] (sock_ioctl+0xd3/0x1bc)
>> [  846.045094] [<c05195fb>] (sock_ioctl) from [<c00fca4d>]
>> (do_vfs_ioctl+0x2cd/0x400)
>> [  846.045133] [<c00fca4d>] (do_vfs_ioctl) from [<c00fcbcd>]
>> (SyS_ioctl+0x4d/0x58)
>> [  846.045172] [<c00fcbcd>] (SyS_ioctl) from [<c000d641>]
>> (ret_fast_syscall+0x1/0x44)
>>
>> Do you have any idea how to solve the problem?
>>
> I did this assertion there because I supposed that the rtnl lock is hold
> while calling this callback. Now I see it isn't...
>
> We need to hold the rtnl lock there because we accessing the mib values.
>
> Try this:
>
> diff --git a/net/mac802154/iface.c b/net/mac802154/iface.c
> index 91b75ab..2a58788 100644
> --- a/net/mac802154/iface.c
> +++ b/net/mac802154/iface.c
> @@ -62,8 +62,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
>                  (struct sockaddr_ieee802154 *)&ifr->ifr_addr;
>          int err = -ENOIOCTLCMD;
>   
> -       ASSERT_RTNL();
> -
> +       rtnl_lock();
>          spin_lock_bh(&sdata->mib_lock);
>   
>          switch (cmd) {
> @@ -90,6 +89,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
>          case SIOCSIFADDR:
>                  if (netif_running(dev)) {
>                          spin_unlock_bh(&sdata->mib_lock);
> +                       rtnl_unlock();
>                          return -EBUSY;
>                  }
>   
> @@ -112,6 +112,7 @@ mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
>          }
>   
>          spin_unlock_bh(&sdata->mib_lock);
> +       rtnl_unlock();
>          return err;
>   }
>
>
> I will put it in my queue for next patch series to remove the mib/pib
> spinlocks. We have only the rtnl lock now.
>
> - Alex

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

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)
> 

mhh, this sounds like another issue.

1. What's your exactly ioctl call, then I can maybe reproduce your issue.

2. There are some information missing at you stacktrace, can you provide
   more information?

- Alex

Re: Ieee802154 socket problem with SIOCGIFADDR

[Matteo Petracca]

This is basically what I have in my program:

   int socketfd = 0;
   struct ifreq ifr;
   static const char *wpandevs[] = {
        "wpan0"
   };


  socket_config_wpan = wpandevs[0];
  socketfd = socket(PF_IEEE802154, SOCK_RAW, 0);

strncpy(ifr.ifr_name, socket_config_wpan, IF_NAMESIZE);
   ret = ioctl(socketfd, SIOCGIFADDR, &ifr);
   if (ret < 0) {
       fprintf(stderr,"ioctl: SIOCGIFADDR error\n");
       return;
    }

  In can say that in kernel 3.8.13 it works with no problems.

Matteo



On 11/05/2015 18: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)
>>
> mhh, this sounds like another issue.
>
> 1. What's your exactly ioctl call, then I can maybe reproduce your issue.
>
> 2. There are some information missing at you stacktrace, can you provide
>     more information?
>
> - Alex

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

On Mon, May 11, 2015 at 06:58:11PM +0200, Matteo Petracca wrote:
> This is basically what I have in my program:
> 
>   int socketfd = 0;
>   struct ifreq ifr;
>   static const char *wpandevs[] = {
>        "wpan0"
>   };
> 
> 
>  socket_config_wpan = wpandevs[0];
>  socketfd = socket(PF_IEEE802154, SOCK_RAW, 0);
> 
> strncpy(ifr.ifr_name, socket_config_wpan, IF_NAMESIZE);
>   ret = ioctl(socketfd, SIOCGIFADDR, &ifr);
>   if (ret < 0) {
>       fprintf(stderr,"ioctl: SIOCGIFADDR error\n");
>       return;
>    }
> 
>  In can say that in kernel 3.8.13 it works with no problems.
> 

I wrote a dirty hack [0]. Run it on my side and detected no issue.

The output is:

pan_id 0xabcd
short_addr 0x2

and that's my current pan_id and short_addr setting.

- Alex

[0] http://pastebin.com/EE5wGZ5Q

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

On Mon, May 11, 2015 at 06:51:27PM +0200, 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)
> > 
> 
> mhh, this sounds like another issue.
> 
> 1. What's your exactly ioctl call, then I can maybe reproduce your issue.
> 
> 2. There are some information missing at you stacktrace, can you provide
>    more information?

Maybe you can give me really the full output of the above stacktrace...
Very important is the first line.

- Alex

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

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

Re: Ieee802154 socket problem with SIOCGIFADDR

[Matteo Petracca]

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

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

On Tue, May 12, 2015 at 10:32:57AM +0200, Matteo Petracca wrote:
> 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)

can't be. The patch removes the RTNL assertion. Please check if you
really rebuild and update your kernel/modules.

Maybe try `uname -a` and check kernels build date/git HEAD id/whatever.

- Alex

Re: Ieee802154 socket problem with SIOCGIFADDR

[Matteo Petracca]

You were right, I did not remove the Assertion.

Now the patch is all there and the modules are
updated.

What happens now is a strange behaviour, booting
the system I just turn on the wpan interface putting
as panid 0xaaaa:

ifconfig wpan0 up

the device starts to read from the network, and this is
what I have in output with dmesg is:

[  131.445285] ieee802154: bad frame received (type = 3)
[  133.777933] ieee802154: bad frame received (type = 3)
[  136.110635] ieee802154: bad frame received (type = 3)
[  148.318471] ieee802154: bad frame received (type = 3)
[  150.651288] ieee802154: bad frame received (type = 3)
[  152.984910] ieee802154: bad frame received (type = 3)
[  165.195277] ieee802154: bad frame received (type = 3)
[  167.527936] ieee802154: bad frame received (type = 3)
[  169.860422] ieee802154: bad frame received (type = 3)
[  182.071635] ieee802154: bad frame received (type = 3)
[  184.406857] ieee802154: bad frame received (type = 3)
[  186.739487] ieee802154: bad frame received (type = 3)
[  198.947054] ieee802154: bad frame received (type = 3)
[  201.279710] ieee802154: bad frame received (type = 3)
[  203.612262] ieee802154: bad frame received (type = 3)
[  215.819843] ieee802154: bad frame received (type = 3)
[  218.155852] ieee802154: bad frame received (type = 3)
[  220.488465] ieee802154: bad frame received (type = 3)

Moreover SIOCGIFADDR still does not work.

Sorry for bothering you.

I don't know what to think.

Matteo

On 12/05/2015 10:39, Alexander Aring wrote:
> On Tue, May 12, 2015 at 10:32:57AM +0200, Matteo Petracca wrote:
>> 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)
> can't be. The patch removes the RTNL assertion. Please check if you
> really rebuild and update your kernel/modules.
>
> Maybe try `uname -a` and check kernels build date/git HEAD id/whatever.
>
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ieee802154 socket problem with SIOCGIFADDR

[Alexander Aring]

On Tue, May 12, 2015 at 11:48:36AM +0200, Matteo Petracca wrote:
> You were right, I did not remove the Assertion.
> 
> Now the patch is all there and the modules are
> updated.
> 
> What happens now is a strange behaviour, booting
> the system I just turn on the wpan interface putting
> as panid 0xaaaa:
> 
> ifconfig wpan0 up
> 
> the device starts to read from the network, and this is
> what I have in output with dmesg is:
> 
> [  131.445285] ieee802154: bad frame received (type = 3)
> [  133.777933] ieee802154: bad frame received (type = 3)
> [  136.110635] ieee802154: bad frame received (type = 3)
> [  148.318471] ieee802154: bad frame received (type = 3)
> [  150.651288] ieee802154: bad frame received (type = 3)
> [  152.984910] ieee802154: bad frame received (type = 3)
> [  165.195277] ieee802154: bad frame received (type = 3)
> [  167.527936] ieee802154: bad frame received (type = 3)
> [  169.860422] ieee802154: bad frame received (type = 3)
> [  182.071635] ieee802154: bad frame received (type = 3)
> [  184.406857] ieee802154: bad frame received (type = 3)
> [  186.739487] ieee802154: bad frame received (type = 3)
> [  198.947054] ieee802154: bad frame received (type = 3)
> [  201.279710] ieee802154: bad frame received (type = 3)
> [  203.612262] ieee802154: bad frame received (type = 3)
> [  215.819843] ieee802154: bad frame received (type = 3)
> [  218.155852] ieee802154: bad frame received (type = 3)
> [  220.488465] ieee802154: bad frame received (type = 3)
> 
> Moreover SIOCGIFADDR still does not work.
> 

This is a behaviour because we have lack of support to parse mac_cmd
frames [0]. And I see now I already told you that! [1]

The current parsing mechanism is very dataframes specfic there is an 
draft for reworking this frame parsing style and do it like mac80211
(which have a lot of more frametypes than 802.15.4). See [2]:
"new frame parsing style in mac802154 and ieee802154 based on mac80211
frame parsing design. Draft is mac802154 rx and 6LoWPAN. Crypto need to
be done at first, otherwise I can’t test it."

Nevertheless it needs time to supporting it, you could simple add a case
that the frame is delivered to userspace, but then this frame could not
valid 802.15.4 frametype and you need to check that again in userspace.

I also noticed that the raw socket don't put the mac header into payload
(which should it do), see [3] (that's something which already told you).

and yes, the 802.15.4 sockets needs a complete rework/cleanup. This is
an opentask section at [4], we should orient us at bluetooth socket
code.

- Alex

[0] http://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/mac802154/rx.c#n104
[1] http://www.spinics.net/lists/linux-wpan/msg01623.html
[2] http://wpan.cakelab.org/
[3] http://www.spinics.net/lists/linux-wpan/msg01623.html
[4] http://wpan.cakelab.org/