From: Erik Hugne [mailto:erik.hu...@gmail.com] Sent: Thursday, 02 June, 2016 14:11 To: Ying Xue Cc: Richard Alpe; Parthasarathy Bhuvaragan; Jon Maloy; tipc-discussion@lists.sourceforge.net Subject: RE: [RFC PATCH] tipc: fix timer handling when socket is owned
On Jun 2, 2016 1:03 PM, "Xue, Ying" <ying....@windriver.com> wrote: >> >> Acked-by: Ying Xue <ying....@windriver.com> >> >> Jon, whatever the patch can fix Guna's issue or not, I think the change is >> right because there is an obvious error that we deliver message through >> tipc_node_xmit_skb() when "owner" flag is set. >> So, I suggest that the patch should be submitted to upstream as soon as >> possible. >> >If you think the change is reasonable, could you please help me test it? >My crappy AMD A10 laptop does not handle VM's well.. >I have one concern about it, locking policy have changed slightly since >tipc_node_xmit_skb is now called with the socket spinlock held. And i dont >know if this introduces a new race.. Logically it should be ok, since it only means that the response message always ends up in the backlog queue. But it is still an unnecessary change. Personally I liked better the first proposal, which I think was simpler. Why not 1) grab the lock and the mutex, if necessary after several attempts. 2) fetch all relevant socket fields to the stack. 3) release the lock and the mutex 4) create the message 5) send the message This would give only one timeout function and minimal time spent inside the lock/mutex. I you do so you should also extend the wait period for retrial to more e.g., 1 second until you retry. The risk of finding the socket busy again after a longer period is lower. ///jon >//E ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
