Why the communication between winbindd child and DC is not asynchronous?

Pavel Filipensky pfilipen at redhat.com
Wed Aug 18 14:56:31 UTC 2021


Hi metze,

We should actually enforce dcerpc_binding_handle_call() to be not recursive.
>


I assume that  dcerpc_binding_handle_call() becomes recursive only if
(DEPRECATED) dcerpc_binding_handle_set_sync_ev() is called, but this is not
present in librpc (only in source4) and not called by winbindd child, or?
Also if I run 'id ADDOMAIN/user', none of the below breakpoints is hit in
winbindd child:
tevent_loop_allow_nesting
dcerpc_binding_handle_set_sync_ev

Can you please give me an example of some scenario which has a
non-asynchronous logic in winbind child? I would like to get familiar with
that, I am working on improvement of winbindd traces and  that might
beinetersting.

Cheers,
Pavel





> In some areas (at least in the past) we had the usage of *nested* event
> loops,
> where tevent_loop_once() is called recursively more than once on the same
> stack
> on the same tevent_context structure, which leads to unpredictable results.
> But I think we need to avoid the usage of tevent_loop_allow_nesting() and
> prove that everything still works, which is a very hard task to do.
>
> It would be nice to have everything async and tevent_req based in the
> parent
> and avoid the children completey, but the logic within the children is
> often
> very complex and it would be a lot of work to rewrite it to be completely
> tevent_req based.
>
> metze
>
>


More information about the samba-technical mailing list