[SSSD] [PATCH] RESPONDER: Refactor DP requests into tevent_req style

Jakub Hrozek jhrozek at redhat.com
Tue Nov 29 11:32:23 UTC 2011


On Mon, Nov 28, 2011 at 11:28:18AM -0500, Stephen Gallagher wrote:
> On Mon, 2011-11-28 at 15:01 +0100, Jakub Hrozek wrote:
> > On Fri, Nov 18, 2011 at 12:17:42PM -0500, Stephen Gallagher wrote:
> > > This patch addresses a number of code-maintenance issues and one
> > > hard-to-spot bug that has been hiding in the responder code for a long
> > > time.
> > > 
> > > The code has been changed so that we will now follow the tevent_req
> > > style for requesting data from the Data Provider. We will attach
> > > tevent_req objects to the DP request object and call tevent_req_[done|
> > > error] on them once the processing is complete.
> > > 
> > > For those requests that don't need to wait for a reply (such as midpoint
> > > cache refresh), the caller need only talloc_free() the returned
> > > tevent_req. The cache update will still continue in the background, but
> > > no notification of completion will be sent to this caller.
> > > 
> > > The major bug that this addresses was the present of two timeouts being
> > > monitored for the same request: one was set in tevent directly by the
> > > NSS responder and the other was created implicitly by the D-BUS
> > > communication. Under some hard-to-reproduce situations, these could
> > > interact negatively and result in one cancelling the other. It has now
> > > been reduced down to using ONLY the D-BUS timeout.
> > 
> > (I hope I don't break threading..I lost some mail and ended up importing
> > sssd-devel contents from public archives)
> > 
> > Nack,
> > 
> > sssd_nss segfaults when setpwent is run:
> 
> Thanks, I made a bad assumption in the enumeration code that dctx was
> available. I'm now carrying the cli_ctx explicitly.
> 
> New patch attached.

Ack, just consider one change before pushing the "error:" label in
check_cache() always passes ENOMEM into nss_cmd_send_error. I think it
should use whatever is in ret.



More information about the sssd-devel mailing list