[PATCH] Fix bug 9412 - SMB2 server doesn't support recvfile.

[Stefan (metze) Metzmacher]

Hi Jones,

>>> 2014-04-03 2:06 GMT+08:00 Stefan (metze) Metzmacher <metze at samba.org>:
>>>
>>> And turn the socket into blocking mode once we get EAGAIN?
>>>
>>
>> Add poll_one_fd() and infinite waiting for socket fd is ready to read.
>>
>>
> Hello Jeremy, Metze,
> 
> After lookup the BUGS section in man page select/poll,
> it seems not a good idea to select/poll a fd with O_NONBLOCK,
> my modification may cause undefined behavior which is platform dependent.

I think you got that wrong, the man page says:

       Under Linux, select() may report a socket file descriptor as
"ready for reading", while nevertheless  a  subse-
       quent read blocks.  This could for example happen when data has
arrived but upon examination has wrong checksum
       and is discarded.  There may be other circumstances in which a
file descriptor is spuriously reported as ready.
       Thus it may be safer to use O_NONBLOCK on sockets that should not
block.

That means you if you 100% don't want to be blocked you should use
O_NONBLOCK in combination with select()/poll().

> After checking sys_sendfile(),
> a preliminary thought prompt to handle the EAGAIN in sys_recvfile(),
> please kindly help comment,
> thanks.

+				/* FIXME: For rare cases:
+				 * case1) a high latency network.
+				 * case2) a network undergoing severe congestion.
+				 * Should use fcntl + O_NONBLOCK here ? */
+				continue;

This is not such a rare case, we need to make sure a client doesn't
trigger a 100% CPU loop.

I think once we get EAGAIN or EWOULDBLOCK we should turn the socket into
blocking mode
(if it's not already) and restore the old state when we're done.

Jeremy, what do you think is the better place to handle this
sys_sendfile() or the smb2 caller?

Are there're any known VFS modules, which would be impacted?

metze