[SSSD] [PATCH] fix early free of sdap_handle
Simo Sorce
ssorce at redhat.com
Fri Apr 16 20:01:27 UTC 2010
On Fri, 16 Apr 2010 10:02:08 +0400
Eugene Indenbom <eindenbom at gmail.com> wrote:
> > You said you want to be resistant to random callback freeing the
> > sdap_handle, so this is the sequence that still gives me trouble:
> >
> > 1. sdap_process_result is called
> > 2. sdap_handle_release(final = false) is called
> > 3. conncb destroyed
> > 3. op->callback is called
> > 4. talloc_zfree(gsh) is called
> > 5. sdap_handle_destroy is called
> > 6. sdap_handle_release(final = true) is called
> > 7. netx op->callback is called
> > 8. talloc_zfree(gsh) is called (2nd time .. not good)
> >
> > I don't see how you prevent this in your code, given ctx->gsh is
> > zeroed only when talloc_zfree() returns.
> >
> This problem was one of major issues when I have started to work on
> failover reconnect problem.
>
> The complete set of my patches addressed the issue by implementing
> reference counting of connection usage (see
> https://fedorahosted.org/pipermail/sssd-devel/2010-April/003113.html,
> patch #4). When reference counting is in place, sdap_handle is not
> destroyed until all operations complete. So inner
> sdap_handle_release(final = true) calls no callbacks.
>
> So after I suggested patch #3 as a separate fix for "early free of
> sdap_handle" problem, I have looked into this issue again and found
> the deficiency in talloc_zfree you have mentioned above. The I have
> developed a simple patch to fix it, but was holding it back for a
> while waiting for this discussion to calm down.
>
> Now I am sending this patch in separate e-mail for approval.
Ah btw, I re-checked this with Sumit and it turns out that calling
talloc_free(X) within the destructor of X is not really a problem and
will not cause a recursion. Talloc will just return an not run the
destructor again.
So the patch to talloc_zfree() is strictly not necessary,
although it probably does no harm either so I'm ok with it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
More information about the sssd-devel
mailing list