Re: [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation

From: Alexander Aring <aar@pengutronix.de>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-wpan@vger.kernel.org, kernel@pengutronix.de,
	kaspar@schleiser.de,
	Jukka Rissanen <jukka.rissanen@linux.intel.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Patrik Flykt <Patrik.Flykt@linux.intel.com>
Subject: Re: [RFC bluetooth-next 00/20] bluetooth: rework 6lowpan implementation
Date: Tue, 12 Jul 2016 20:35:51 +0200	[thread overview]
Message-ID: <5b41b0e5-c017-20d9-c94f-11fb1ab2847d@pengutronix.de> (raw)
In-Reply-To: <CABBYNZJFStOf6qOcpP6DmdxFBx7swrnFPmQLizy0UyokwS64ng@mail.gmail.com>

Hi,

On 07/12/2016 04:51 PM, Luiz Augusto von Dentz wrote:
...
>>
>> HOW TO REPRODUCE:
>>
>> It's simple, do some high payloads which makes lot tx/rcv traffic on both sides:
>>
>> Node A:
>>
>>  ping6 $IP_NODEB%6lo0 -s 60000
>>
>> Node B:
>>
>>  ping6 ff02::1%6lo0
> 
> Im not sure I understand what you are trying to do with a packet of
> 60Kb, the l2cap_chan can most likely only do 1280 bytes and even with

60Kb is just some incredible high value to produce on both sides tx/rx
data. The other side will normally send some "defragmentation failure"
icmp messages.

This value is just to produce the high traffic, not practice payload.

> fragmentation this will consume the credits quicker than we can
> receive more so it will eventually starting buffering until it gets
> stuck. Note that it is probably still receiving credits but we

This is exactly what I like to do. Produce a lot of data to kill L3
layer, but this should not kill the L2 layer. Killing the L2 layer is
what's happend here.

If I do a lot of data on e.g. tcp traffic and the tcp connection will be
closed -> that's fine for me but afterwards starting a new L3 connection
should be still working. This is not the case here, I can kill L2 layer
and nothing works anymore, because L2 running into deadlock.

> probably have so much data buffered that all the credits are consumed
> almost immediately after receiving, or you don't see -EAGAIN more than
> once?
> 

My example shows that we transmit some data on both nodes, that is
important to check the l2cap_chan_send return type.

When I do that above and running into the deadlock the IPv6 connection
runs "NS" messages only, because it still can send on L3 layer but the
L2 layer is killed -> I get -EAGAIN in l2cap_chan_send always on both
nodes because tx_credits are on both nodes zero and will not be
incremented again.

So far I know these tx_credits will be incremented only if somebody
sends something again, right? This will never be the case again and I am
stucked in a deadlock which should not be there.

to your question:

"or you don't see -EAGAIN more than once"

I see -EAGAIN always at calling l2cap_chan_send on both nodes. I think I
can wait forever, after an year I still see "-EAGAIN" when calling
l2cap_chan_send.

Nevertheless, I will try to hit the deadlock (-EAGAIN) on both nodes so
nobody transmits anything anymore. Then waiting six hours and look if
still -EAGAIN is there on both nodes. I will report again here, after
that time it should working again, but I don't believe that.

- Alex