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

Stefan Metzmacher metze at samba.org
Wed Aug 18 13:11:09 UTC 2021


Hi Pavel,

> I have noticed "winbindd: domain child [ADDOMAIN]" is able to start
> processing of the next incoming request from the main winbindd only after
> the response from the DC is received. This was reproduced in
> ad_member_idmap_rid selftest environment via running:
> 
> id ADDOMAIN/user1 & id ADDOMAIN/user2 & id ADDOMAIN/user3 &
>
> To make the sequence of events clearly visible, the DC processing is made
> slower using 1 sec delay before each incoming request is started - using
> gdb breakpoint:

That's exactly the reason why we have winbindd children at all, the logic
within each child is not async at all. And we use the multiple children
in order to be at least async in the parent.

> I assume that this is an unwanted situation, since the purpose of tevent
> library is to achieve asynchronous communication, or? Can we get rid of the
> inner tevent loop which starts in dcerpc_binding_handle_call()? I am
> wondering what is this TODO comment (from commit 4030bc9b) about:
> 
> 528 NTSTATUS dcerpc_binding_handle_call(struct dcerpc_binding_handle *h,
> 
> ...
> 541 »·······/ * TODO: allow only one sync call

We should actually enforce dcerpc_binding_handle_call() to be not recursive.
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20210818/e77f2e25/OpenPGP_signature.sig>


More information about the samba-technical mailing list