recvmmsg() timeout behavior strangeness

recvmmsg() timeout behavior strangeness

[Michael Kerrisk]

Hello Arnaldo,

As part of his attempt to better document the recvmmsg() syscall that
you added in commit a2e2725541fad72416326798c2d7fa4dafb7d337, Elie de
Brauwer alerted to me to some strangeness in the timeout behavior of
the syscall. I suspect there's a bug that needs fixing, as detailed
below.

AFAICT, the timeout argument was added to this syscall as a result of
the discussion here:
http://thread.gmane.org/gmane.linux.network/128582 .

If I understand correctly, the *intended* purpose of the timeout
argument is to set a limit on how long to wait for additional
datagrams after the arrival of an initial datagram. However, the
syscall behaves in quite a different way. Instead, it potentially
blocks forever, regardless of the timeout. The way the timeout seems
to work is as follows:

1. The timeout, T, is armed on receipt of first diagram, starting at time X.
2. After each further datagram is received, a check is made if we have
reached time X+T. If we have reached that time, then the syscall
returns.

Since the timeout is only checked after the arrival of each datagram,
we can have scenarios like the following:

0. Assume a timeout of 10 seconds, and that vlen is 5.
1. First datagram arrives at time X.
2. Second datagram arrives at time X+2 secs
3. No more datagrams arrive.

In this case, the call blocks forever. Is that intended behavior?
(Basically, if vlen-1 datagrams arrive before X+T, but then no more
datagrams arrive, the call will remain blocked forever.) If it's
intended behavior, could you elaborate the use case, since it would be
good to add that to the man page.

Thanks,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recvmmsg() timeout behavior strangeness

[Chris Friesen]

On 12/23/2012 02:50 PM, Michael Kerrisk wrote:

> If I understand correctly, the *intended* purpose of the timeout
> argument is to set a limit on how long to wait for additional
> datagrams after the arrival of an initial datagram. However, the
> syscall behaves in quite a different way. Instead, it potentially
> blocks forever, regardless of the timeout.

Looking at the code, I think you're correct.

The comments for a2e2725 say the timeout works like for ppoll(), where 
it is "an upper limit on the time for which poll() will block, in 
milliseconds."

I wonder if we could play some games with sk->sk_rcvtimeo to accomplish 
this?

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recvmmsg() timeout behavior strangeness

[Steven Whitehouse]

Hi,

On Wed, 2013-01-09 at 16:33 -0600, Chris Friesen wrote:
> On 12/23/2012 02:50 PM, Michael Kerrisk wrote:
> 
> > If I understand correctly, the *intended* purpose of the timeout
> > argument is to set a limit on how long to wait for additional
> > datagrams after the arrival of an initial datagram. However, the
> > syscall behaves in quite a different way. Instead, it potentially
> > blocks forever, regardless of the timeout.
> 
> Looking at the code, I think you're correct.
> 
> The comments for a2e2725 say the timeout works like for ppoll(), where 
> it is "an upper limit on the time for which poll() will block, in 
> milliseconds."
> 
> I wonder if we could play some games with sk->sk_rcvtimeo to accomplish 
> this?
> 
> Chris

Which timeout are we talking about? I've been copied into the thread
without seeing the start of it.

If this is the rcvtimeo then afaik this is supposed to be the max time
that the call waits for data, but is overridden by MSG_DONTWAIT, for
example, on a per call basis. I'd assume that recvmmsg should work
exactly like recvmsg in this case unless there is a good reason for it
to differ,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: recvmmsg() timeout behavior strangeness

[Chris Friesen]

On 01/10/2013 04:04 AM, Steven Whitehouse wrote:

> Which timeout are we talking about? I've been copied into the thread
> without seeing the start of it.

The discussion is about the timeout parameter for the recvmmsg() call. 
Currently in the recvmmsg() code it only checks the timeout after 
__sys_recvmsg() returns, so if __sys_recvmsg() blocks forever we could 
end up essentially ignoring the timeout.

> If this is the rcvtimeo then afaik this is supposed to be the max time
> that the call waits for data, but is overridden by MSG_DONTWAIT, for
> example, on a per call basis. I'd assume that recvmmsg should work
> exactly like recvmsg in this case unless there is a good reason for it
> to differ,

recvmsg() doesn't have a timeout parameter, so it uses SO_RCVTIMEO.

recvmmsg() has an explicit timeout parameter but it doesn't look like it 
works properly and the documentation doesn't mention how it is supposed 
to interact with SO_RCVTIMEO.

Chris