linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* recvmmsg() timeout behavior strangeness [RESEND]
@ 2014-04-30 13:59 Michael Kerrisk (man-pages)
  2014-05-03 10:28 ` Michael Kerrisk (man-pages)
  2014-05-12 10:15 ` Michael Kerrisk (man-pages)
  0 siblings, 2 replies; 37+ messages in thread
From: Michael Kerrisk (man-pages) @ 2014-04-30 13:59 UTC (permalink / raw)
  To: Arnaldo Carvalho de Melo, lkml
  Cc: mtk.manpages, linux-man, netdev, Ondřej Bílka,
	Caitlin Bestler, Neil Horman, Elie De Brauwer, David Miller,
	Steven Whitehouse, Rémi Denis-Courmont, Paul Moore,
	Chris Friesen

Arnaldo,

I raised this issue somewhat more than a year ago, here:
http://thread.gmane.org/gmane.linux.man/3477
but got no reply from you. (Chris Friesen in that thread agreed 
that there is a problem though.)

Here, a slightly revised version of that mail, since I've just bumper 
into a related problem in a different context...

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://markmail.org/message/m5l2ap4hiiimut6k#query:+page:1+mid:m5l2ap4hiiimut6k+state:results
(20-21 May 2009, "[RFC 1/2] net: Introduce recvmmsg...")

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 up to 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. If not, a fix seems to be needed,
since otherwise, it's hard to see how the recvmmsg() timeout argument
can sanely be used.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2014-06-27 11:37 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-30 13:59 recvmmsg() timeout behavior strangeness [RESEND] Michael Kerrisk (man-pages)
2014-05-03 10:28 ` Michael Kerrisk (man-pages)
2014-05-03 11:29   ` Florian Westphal
2014-05-03 11:39     ` Michael Kerrisk (man-pages)
2014-05-12 10:15 ` Michael Kerrisk (man-pages)
2014-05-12 14:34   ` Arnaldo Carvalho de Melo
2014-05-21 21:05     ` [PATCH/RFC] " Arnaldo Carvalho de Melo
2014-05-22 14:27       ` Michael Kerrisk (man-pages)
2014-05-24  6:13         ` Michael Kerrisk (man-pages)
2014-05-26 13:46         ` Arnaldo Carvalho de Melo
2014-05-26 21:17           ` Arnaldo Carvalho de Melo
2014-05-27 16:35             ` Michael Kerrisk (man-pages)
2014-05-27 19:21               ` Arnaldo Carvalho de Melo
2014-05-27 19:22                 ` Arnaldo Carvalho de Melo
2014-05-27 19:28                 ` Michael Kerrisk (man-pages)
2014-05-27 20:30                   ` Arnaldo Carvalho de Melo
2014-05-28  5:00                     ` Michael Kerrisk (man-pages)
2014-05-28 12:20                     ` Michael Kerrisk (man-pages)
2014-05-28 15:07                       ` Arnaldo Carvalho de Melo
2014-05-28 15:17                         ` David Laight
2014-05-28 19:50                           ` 'Arnaldo Carvalho de Melo'
2014-05-28 21:33                             ` Chris Friesen
2014-05-28 21:49                               ` 'Arnaldo Carvalho de Melo'
2014-05-29 10:53                             ` David Laight
2014-05-29 13:55                               ` 'Arnaldo Carvalho de Melo'
2014-05-29 14:06                                 ` David Laight
2014-05-29 14:17                                   ` 'Arnaldo Carvalho de Melo'
2014-05-29 14:40                                     ` David Laight
2014-05-29 15:33                                     ` [PATCH/RFC] Handle EFAULT in partial recvmmsg was " 'Arnaldo Carvalho de Melo'
2014-06-16  9:58                                     ` Michael Kerrisk (man-pages)
2014-06-24 20:25                                       ` Arnaldo Carvalho de Melo
2014-06-27 11:29                                         ` Michael Kerrisk (man-pages)
2014-05-29 14:07                               ` Michael Kerrisk (man-pages)
2014-06-27 11:37                       ` Michael Kerrisk (man-pages)
2014-05-23 19:00       ` David Miller
2014-05-23 19:55         ` Arnaldo Carvalho de Melo
2014-05-24  6:13           ` Michael Kerrisk (man-pages)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).