question on a possibility for a netdev deadlock

Development archive
1

Hi all,

I've tested the ng_ stack with samr21-xpro boards using the new ng_at86rf2xx driver. Since I sometimes encountered hardfaults I took a look in the ISR handling of the driver [1].

There we handle incoming packets when the receiver has finished the RX process [2]. Since we are in a ISR, all other processes has been interrupted.

Now when we call _receive_data() function inside the ISR, that in turn calls pktbuf handling/manipulating functions [3], we try to acquire the mutex protecting the pktbuf [4].

Since we are still inside of the ISR probably the mutex is acquired by someone else. If true this leads to a deadlock since the ISR would wait forever to acquire the mutex and never return to leave the ISR.

Additionally if we successfully acquire the mutex, we could produce inconsistencies iff the protection is not performed consistently.

Just wanted to ask if I'm mistaken here and missed something.

Best regards, Martin

[1] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L671 [2] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L688 [3] https://github.com/RIOT-OS/RIOT/blob/master/drivers/ng_at86rf2xx/ng_at86rf2xx_netdev.c#L271 [4] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/crosslayer/ng_pktbuf/ng_pktbuf.c#L81

2

Hi Martin,

all the mentioned function are not called in interrupt context. Take a look at ng_at86rf2xx.c. There you find the real ISR that sends a msg to the next higher level notifying about the IRQ. Then from there everything else in the driver is executed from thread context.

So I guess this is unrelated to the problems you are having.

Cheers, Daniel

3

Ahh, thx for clarification.

Best regards, Martin