[tipc-discussion] [PATCH net-next v2 0/4] some small fixes

When running TIPC in large clusters we have experienced behavior that potentially may become problematic in the future. This series picks some low-hanging fruit in this regard, and also fixes a couple of other minor issues. v2: #1: Found even more remnants to remove. #2: Clarified problem

[tipc-discussion] [PATCH net-next v2 2/4] tipc: eliminate buffer leak in bearer layer

When enabling a bearer we create a 'neigbor discoverer' instance by calling the function tipc_disc_create() before the bearer is actually registered in the list of enabled bearers. Because of this, the very first discovery broadcast message, created by the mentioned function, is lost, since it

[tipc-discussion] [PATCH net-next v2 4/4] tipc: reduce transmission rate of RESET messages when link is down

When a link is down, it will continuously try to re-establish contact with the peer by sending out a RESET message at each timeout interval. The default value for this interval is currently 375 ms. This is wasteful, and may become a problem in very large clusters with dozens or hundereds of nodes

[tipc-discussion] [PATCH net-next v2 3/4] tipc: stricter filtering of packets in bearer layer

Resetting a bearer/interface, with the consequence of resetting all its pertaining links, is not an atomic action. This becomes particularly evident in very large clusters, where a lot of traffic may happen on the remaining links while we are busy shutting them down. In extreme cases, we may even

[tipc-discussion] list_add corruption. next->prev should be prev (ffff88034b1d1c88), but was (null)

Based on Kernel 4.4.0+some of the latest tipc fixes. The card is not come up, required to re-seat. Also still seeing "Dropping name table..." [ 255.418898] WARNING: CPU: 5 PID: 110 at lib/list_debug.c:29 __list_add+0x81/0xd0() [ 255.426646] list_add corruption. next->prev should be prev

Re: [tipc-discussion] kernel page allocation problem

Hi Leon, Yes, you are running TIPC 2.0, but that does not really mean much. The version number hasn't changed the last 4-5 years, while huge parts of the code has been fundamentally rewritten during that period. There were several issues like the one you have encountered, and almost all of

Re: [tipc-discussion] Kernel 4.4.0 - tipc __list_del_entry

I merged fixes (listed below) to my kernel 4.4.0 and tested. The send_msg crash is gone but I do still see following: 1. "Dropping name table" ... 2. general protection fault: 1 SMP Mar 23 15:13:25 [SEQ 429781] kernel: [

[tipc-discussion] subscr.c: Added new function is removed on latest: why

// file subscr.c I do see tipc_subscrp_subscribe() added on Feb 2nd but the changes are reverted on March 7th version of file. Any reason why the tipc_subscrp_subscribe() is not on latest version? // Feb 2nd

Re: [tipc-discussion] BUG: unable to handle kernel NULL pointer dereference at 0000000000000039 ==> tipc_sendmsg

Hi Guna, NULL pointer dereference at 0039, translates to (gdb) p &((struct tipc_skb_cb *)((struct sk_buff *)0)->cb)->wakeup_pending $8 = (bool *) 0x39 This issue is fixed in commit: f214fc402967e1 ("tipc: Revert "tipc: use existing sk_write_queue for outgoing packet chain") This

Re: [tipc-discussion] [PATCH net-next 4/4] tipc: reduce transmission rate of RESET messages when link is down

On 03/27/2016 04:05 AM, Jon Maloy wrote: > When a link is down, it will continuously try to re-establish contact > with the peer by sending out a RESET message at each timeout interval. > The default value for this interval is currently 375 ms. This is > wasteful, and may become a problem in very

Re: [tipc-discussion] [PATCH net-next 3/4] tipc: stricter filtering of packets in bearer layer

Hi Jon, The change also makes us come back to the original state as there was a flag member in bearer struct which is used to indicate whether bearer is up or down. Actually we ever had lots of discussions about it, and ultimately we removed it from bearer struct. Now if we re-add it into

Re: [tipc-discussion] [PATCH net-next 1/4] tipc: remove remnants from old broadcast code

On 03/27/2016 04:05 AM, Jon Maloy wrote: > We remove a couple of leftover fields in struct tipc_bearer. Those > were used by the old broadcast implementation, and are not needed > any longer. There are no functional changes in this commit. > > Signed-off-by: Jon Maloy