smbd: High CPU usage

[Ralph Böhme]

On Wed, Jul 18, 2018 at 10:34:43PM +0200, Ralph Böhme wrote:
>On Wed, Jul 18, 2018 at 12:27:04PM -0700, Jeremy Allison wrote:
>>On Wed, Jul 18, 2018 at 09:21:43PM +0200, Ralph Böhme wrote:
>>>On Wed, Jul 18, 2018 at 12:12:05PM -0700, Jeremy Allison via samba-technical wrote:
>>>> Now all our socket calls are tevent based, I think we should probably
>>>> change the SMB1 code to match the SMB2 code and make the primary socket
>>>> non-blocking, then fix the sendfile internal implementation to change to
>>>> make the socket temporarily blocking, and back to non-blocking after the
>>>> sendfile completes.
>>>
>>>hm, I think we should avoid such hacks. Can't we just somehow go back to the
>>>event loop if the fd returns EAGAIN or similar for a sendfile() ?
>>
>>No. The reply may be in a partially sent state.
>>
>>There's nothing we can do until we've finished sending
>>the full read reply and there's no internal buffer
>>to store it as there is with a normal async or sync
>>read reply.
>
>hm, if you implement sendfile_send() with immediate events I guess that will
>have higher priority then the out queue processing of SMBX response PDUs. Just
>braindumping here, I'd have to take a closer look.

...and let smbd_smb2_flush_send_queue() return NT_STATUS_OK at the end of "if
(e->sendfile_header != NULL)".

But honestly, I have no idea what I'm talking about as I've successfully avoided
looking into the sendfile code path at the SMB2 layer until now. It makes such a
mess out of the simple fde based event handling, we should remove it. :)

-slow

-- 
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG Key Fingerprint:           FAE2 C608 8A24 2520 51C5
                               59E4 AA1E 9B71 2639 9E46