Hang in tstream_bsd_writev_handler when W10 (at least) calls lsa_LookupSids2 with 1789 SIDs.

[Stefan Metzmacher]

Hi Richard,

> QA sent me a doozie.
> 
> Samba 4.3.0 pre-release.

Why are they using a pre-release (I guess that's even before rc1)?

> They created a file with 1814 ACEs in its ACL using PowerShell
> (although I had to fix their script because it took hours because of
> the way they did it,)
> 
> Then, when they used the ACL Editor to retrieve and display the SD,
> Samba hung in tstream_bsd_writev_handler calling writev.

This sounds like https://bugzilla.samba.org/show_bug.cgi?id=11312

Which should be fixed for quite some time in Samba >= 4.2.3.

> The problem seems to be that there is a little less than 110,xxx bytes
> (that was the size of the RPC being sent back) on the UNIX socket that
> the RPC layer uses to communicate with the SMB layer, and we do not
> use non-blocking sockets there.

But we should...

> So, all those fragments are processed
> as queued events, but the last one blocks and none of the events that
> would remove data from the socket ever get to run and Samba is hung.
> 
> If you look at the code in net/unix and net/core in Linux you will see
> that AF_UNIX sockets do not implement setsockopt and I could not find
> any way to increase the buffer size for UNIX sockets, so I solved the
> problem by changing tstream_bsd_writev_send to never call
> tstream_bsd_writev_handler but call tstream_bsd_set_writeable_handler,
> however, the comment about the performance bothers me. I also could
> not find a way to make that the behavior only for AF_UNIX sockets.
> 
> Is there a better way?

Using non-blocking sockets.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20151025/259b37c6/signature.sig>