Did you not consider using a/the security-key exchanged between the client and server, as the 'key' to lookup/store from MDS?
Mathi. ----- ramesh.bet...@oracle.com wrote: > Hi Hans, > > Thanks for providing the traces. These traces gave more clarity about > the race condition happening between authentication and TIPC sockets. > > I Ack for the latest patch with one comment: > > > There can be a memleak, if the client process exits after the expiry > of MDS DOWN_TMR (and with out calling mds_auth_server_disconnect()). > So a simple function to check for the stale (i.e., no PID exist) > process_info structs and delete them in mds_register_callback() may > help. > This latest patch stabilizes authentication feature and I sincerely > appreciate for listening to my review comments. > > Best Regards, > Ramesh. > > > On 9/17/2014 7:33 PM, Hans Feldt wrote: > > > > > > • Comment : > > > Here's a trace snippet from an opensaf start that it is hard to > explain... > > Sep 8 13:47:55.777790 osafimmnd [5233:mds_c_api.c:1614] TR svc UP > process_info NOTEXIST, svc:26, adest:2020f53b80025 > Sep 8 13:47:55.777801 osafimmnd [5233:mds_c_db.c:2352] >> > mds_process_info_add: dest:2020f53b80025, pid:0 > Sep 8 13:47:55.777987 osafimmnd [5233:mds_main.c:0151] TR mds: > received 77 from 2020f53b80025, pid 5335 > Sep 8 13:47:55.778006 osafimmnd [5233:mds_main.c:0167] TR dest > 2020f53b80025 already exist > Sep 8 13:47:55.792541 osafimmnd [5233:mds_c_api.c:2675] TR svc 26 DOWN > cnt:0, adest:2020f53b80025 > Sep 8 13:47:55.792557 osafimmnd [5233:mds_c_db.c:2361] >> > mds_process_info_del: dest:2020f53b80025, pid:5335 > > Sep 8 13:47:55.792655 osafimmnd [5233:mds_c_api.c:1614] TR svc UP > process_info NOTEXIST, svc:26, adest:2020f53b80025 > Sep 8 13:47:55.792679 osafimmnd [5233:mds_c_db.c:2352] >> > mds_process_info_add: dest:2020f53b80025, pid:0 > Sep 8 13:47:55.792701 osafimmnd [5233:mds_main.c:0151] TR mds: > received 77 from 2020f53b80025, pid 5335 > Sep 8 13:47:55.792945 osafimmnd [5233:mds_main.c:0167] TR dest > 2020f53b80025 already exist > Sep 8 13:47:55.811859 osafimmnd [5233:mds_main.c:0151] TR mds: > received 77 from 2020f53b80025, pid 5335 > Sep 8 13:47:55.811903 osafimmnd [5233:mds_main.c:0167] TR dest > 2020f53b80025 already exist > Sep 8 13:47:55.811994 osafimmnd [5233:mds_c_api.c:2675] TR svc 26 DOWN > cnt:0, adest:2020f53b80025 > Sep 8 13:47:55.812008 osafimmnd [5233:mds_c_db.c:2361] >> > mds_process_info_del: dest:2020f53b80025, pid:5335 > Sep 8 13:47:55.812091 osafimmnd [5233:mds_c_api.c:1614] TR svc UP > process_info NOTEXIST, svc:26, adest:2020f53b80025 > Sep 8 13:47:55.812104 osafimmnd [5233:mds_c_db.c:2352] >> > mds_process_info_add: dest:2020f53b80025, pid:0 > > Sep 8 13:47:55.812194 osafimmnd [5233:immnd_evt.c:0726] WA > immnd_evt_proc_imm_init: PID 0 (5335) for 2020f53b80025, MDS problem? > Sep 8 13:47:55.812742 osafimmnd [5233:mds_c_api.c:2675] TR svc 26 DOWN > cnt:0, adest:2020f53b80025 > Sep 8 13:47:55.812760 osafimmnd [5233:mds_c_db.c:2361] >> > mds_process_info_del: dest:2020f53b80025, pid:0 > > pid:5335 is amfnd > > > [tickets:#1050] amfnd sometimes fails to start due to ERR_LIBRARY from > saImmOmInitialize > > Status: review > Milestone: 4.5.0 > Created: Tue Sep 09, 2014 07:08 AM UTC by Hans Feldt > Last Updated: Mon Sep 15, 2014 01:45 PM UTC > Owner: Hans Feldt > > With MDS/TIPC amfnd randomly fails to start causing failed opensaf > start. > > osafimmnd logs the infamous "immnd_evt_proc_imm_init: ... MDS > problem?" > > Reason is a random timing variation of the TIPC topology DOWN event. > This sometimes causes the DOWN event to wrongly delete a newly added > process_info entry. > > The trigger for this problem is that some IMM clients in opensaf like > amfnd does not reuse IMM handles but initialize/finalize in a far from > optimal way. This should also be fixed. > > The solution under test consists of two parts: > 1) The MDS down event just starts a timer in MDS, when the timeout > event happens the process_info entry is deleted. > > 2) A new explicit disconnect() is added to the MDS API which is used > by IMMA library when it is about to close down the whole core library. > > > Sent from sourceforge.net because > opensaf-tickets@lists.sourceforge.net is subscribed to > https://sourceforge.net/p/opensaf/tickets/ > > To unsubscribe from further messages, a project admin can change > settings at https://sourceforge.net/p/opensaf/admin/tickets/options. > Or, if this is a mailing list, you can unsubscribe from the mailing > list. > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > > _______________________________________________ > Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensaf-tickets > > _______________________________________________ > Opensaf-tickets mailing list > Opensaf-tickets@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensaf-tickets ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
