Re: [tipc-discussion] [PATCH net 1/1] tipc: fix premature addition of node to lookup table

From: Jon Maloy Date: Wed, 10 Feb 2016 16:14:57 -0500 > In commit 5266698661401a ("tipc: let broadcast packet reception > use new link receive function") we introduced a new per-node > broadcast reception link instance. This link is created at the > moment the node itself

Re: [tipc-discussion] TIPC client/server as kernel modules

Hi Paolo, Yes you can. You can create a kernel socket with AF_TIPC from any module and use it the way you wish. If you want an example, look at the topology server (server.{h,c}, subcsr.{h,c}) inside the TIPC module itself. Regards ///jon > -Original Message- > From: Pablo Pessolani

[tipc-discussion] TIPC client/server as kernel modules

Hi: Is it possible to write a TIPC client (and a server) application as linux kernel module? I think in a some kind of TIPC kernel API as ksockets is for TCP. Thanks in advance. PAP -- Site24x7 APM

Re: [tipc-discussion] [PATCH net-next 1/1] tipc: eliminate risk of finding to-be-deleted node instance

> -Original Message- > From: Xue, Ying [mailto:ying@windriver.com] > Sent: Tuesday, 16 February, 2016 08:42 > To: Jon Maloy; tipc-discussion@lists.sourceforge.net; Parthasarathy > Bhuvaragan; > Richard Alpe; huzhiji...@gmail.com > Cc: ma...@donjonn.com > Subject: RE: [PATCH net-next

Re: [tipc-discussion] [PATCH net-next 1/1] tipc: eliminate risk of finding to-be-deleted node instance

@@ -395,21 +396,19 @@ static void tipc_node_delete(struct tipc_node *node) { list_del_rcu(>list); hlist_del_rcu(>hash); It's better to move two lines of code above to tipc_node_kref_release(), ensuring we remove the node from the two lists only when node is released. Regards,

[tipc-discussion] [PATCH net v2 1/1] tipc: fix crash during node removal

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 freed before the node timer is finished with accessing it. This leads to occasional crashes, especially in multi-namespace environments. The scenario goes

[tipc-discussion] [PATCH net-next 1/1] tipc: eliminate risk of finding to-be-deleted node instance

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