From what I can tell, most of the libscf calls in the name services code are not on the lookup path. The exceptions are 1) the smf_get_state call in nscd's switch engine, 2) the smf_restart_instance call when nscd detects configuration changes and needs to restart itself, 3) the calls in the nss_mdns backend to read properties.
For 1) nscd does not hold any locks before calling smf_get_state() as it is often the case that looking up from a backend could take a long time so it releases all the locks before invoking the switch engine. The is the path most of the getXbyY operations will go through (when nscd is running), so as long as deadlock will not happen within smf_get_state(), then we are safe. For 2), fix to CR 6628289 makes sure any getXbyY calls caused by the smf_restart_instance processing will not block. For 3), it seems that the nss_mds backend is only reading, not storing, the SMF properties, and no mutexes and condition variables are used, so it seems fine too. Currently, NSS backends (except nss_mdns) are not using SMF as configuration repository, so libscf is not really used. Duckwater will change this. But as Tomas promised, we will work closely with the SMF team and everyone involved to prevent the deadlock and infinite recursion. Tomas is on vacation until the end of year, he can provide more specifics in this area when he is back. Thanks, Michen David Bustos wrote: > Name services team, > > Per http://www.opensolaris.org/jive/message.jspa?messageID=177109#178420 > I made a list of libscf calls which can block on name service calls. It > is included at the end of this mail. From you I ask for a list of name > service calls which might block on libscf calls. An exhaustive list > doesn't seem to be necessary at this time, since as you can see from my > list, libscf calls only block on getuseruid(). > > I fully expect that our lists will portray cycles which represent > possible deadlocks between svc.configd and nscd. In that case I believe > we will have to negotiate qualifiers for the semantics which will break > those cycles. > > Finally, once we agree on the blocking semantics of our interfaces, > I think we should establish an authoritative location for them, which > will probably imply amendment procedures. Block comments in the source > base or an ARC contract might be good candidates. > > > David > > > Public libscf functions which might block on name service calls: > > - scf_instance_add_pg(), > scf_instance_delete(), > scf_iter_next_value(), > scf_pg_delete(), > scf_property_get_value(), > scf_scope_add_service(), > scf_service_add_instance(), > scf_service_add_pg(), > scf_service_delete(), > scf_transaction_commit(), and > scf_transaction_start() > > might block on getuseruid(). > > No other libscf functions will block on name service calls. > _______________________________________________ > smf-discuss mailing list > smf-discuss at opensolaris.org >
