Timeouts in HEAD ldap code.

[Jeremy Allison]

On Wed, Jun 01, 2005 at 02:09:10PM +0200, Volker Lendecke wrote:
> 
> Just to get it straight, trying to understand the requirements: A client
> blocks us in a SMB read call, an oplock break or a tdb message comes in, and
> we don't respond until the client is so kind to send us enough data? Ok, for
> oplocks this makes sense as the client would not respond anyway. But what
> about for example MSG_SMB_UNLOCK? What does that do?

We go into sys_read() when select has indicated the client is sending
us data. Yes, it's possible for us to block (ignoring the signals EINTR
and restarting the read) if the clients says it'll send us XX bytes
in the SMB header and then sends less than XX bytes but that connection
is broken in this case and we're going to die anyway.

> So is the reasonable thing to do to revert to the current 3_0 read_data
> implementation, and make read_data_until use the normal interrupting read
> system call?

No, I don't think so.

We have 2 cases for LDAP activity :

1). We're using LDAP library code - not signal safe and using alarm() to
terminate timed out reads().

In this case we should block the signals we know we might get other
than alarm() before the calls into the library code, and re-enable
them afterwards.

These areas should be easy to find as they are the same places we
call alarm(timeout) and alarm(0). We just add signal blocking functions
to the alarm setup and teardown.

2). We're using our own LDAP ASN.1 read code - using read_data_until().
In this case we're not using alarm signals and so we can make this code
signal safe (ie. ignore signals until we've finished the LDAP activity
or timed out). We do this by doing a select before each read() call,
calling read() directly, and re-doing the select with reduced timeout
each time read returns -1 with EAGAIN (non-blocking socket) or EINTR
(signal received).

The main SMB reading code path shouldn't be disturbed.

> BTW, why do we have read_data and read_socket_data in 3_0? From a glance I did
> not see any difference.

Probably legacy historical reasons (ie. reinvention of the wheel).

Jeremy