HI Jon,
Thanks for your clear explanation. Yes, I misunderstood the scenario. You are
right and its solution is much simpler and safer than before.
Please go ahead.
Thanks,
Ying
From: Jon Maloy [mailto:jon.ma...@ericsson.com]
Sent: 2016年2月23日 21:17
To: Xue, Ying; jason
Cc: Jon Maloy; Richard A
Anybody who has time to look into this?
///jon
On 02/19/2016 06:41 PM, Jon Maloy wrote:
> The compatibility functionality has been broken, and causes a crash as
> shown below:
>
> Bisecting seems to indicate that the culprit is:
>
> commit 263ea09084d172cac6e40459a690babe8de8e448
> ("Revert "gen
In Commit 94153e36e709e ("tipc: use existing sk_write_queue for
outgoing packet chain"), we assume that we fill & empty the socket's
sk_write_queue within the same lock_sock() session.
This is not true if the link is congested. During congestion, the
socket lock is released while we wait for the c
Until now, while processing CONN_ACK message the socket wakeup is
called when the check for congestion returns true. This is incorrect.
In this commit, we call the socket wakeup only if congestion is
released in CONN_ACK message processing path.
Signed-off-by: Parthasarathy Bhuvaragan
---
net/t
Although we have never seen it happen, we have identified the
following problematic scenario when nodes are stopped and deleted:
CPU0:CPU1:
tipc_node_xxx() //ref == 1
tipc_node_put()//ref -> 0
When the TIPC module is unloaded, we have identified a race condition
that allows a node reference counter to go to zero and the node instance
being freed before the node timer is finished with accessing it. This
leads to occasional crashes, especially in multi-namespace environments.
The scenario
Ack-by: Ying Xue
-Original Message-
From: Jon Maloy [mailto:jon.ma...@ericsson.com]
Sent: 2016年2月20日 9:17
To: tipc-discussion@lists.sourceforge.net;
parthasarathy.bhuvara...@ericsson.com; Xue, Ying; richard.a...@ericsson.com;
jon.ma...@ericsson.com; huzhiji...@gmail.com
Cc: ma...@donjo
Yes, this works for me too, and I see no problem with it.
Acked-by Jon Maloy
Thanks
///jon
On 02/24/2016 11:02 AM, Florian Westphal wrote:
> Jon Maloy wrote:
>> Anybody who has time to look into this?
> So this appears to work for me, do you see any problems with this?
>
> Subject: [-next] ne
Partha,
I think it would be simpler to just always keep the packet list on the
stack, like it was before I introduced the faulty patch.
Yes, it costs a couple of cycles extra, but simplicity is also an
important factor here.
///jon
On 02/24/2016 10:23 AM, Parthasarathy Bhuvaragan wrote:
> In C
