netdev - Re: recvmmsg() timeout behavior strangeness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Jan 2013 10:04:09 +0000
From:	Steven Whitehouse <steve@...gwyn.com>
To:	Chris Friesen <chris.friesen@...band.com>
Cc:	Michael Kerrisk <mtk.manpages@...il.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Caitlin Bestler <caitlin.bestler@...il.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Chris Van Hoof <vanhoof@...hat.com>,
	Clark Williams <williams@...hat.com>,
	Neil Horman <nhorman@...driver.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Andrew Grover <andy.grover@...il.com>,
	Elie De Brauwer <eliedebrauwer@...il.com>,
	linux-man@...r.kernel.org,
	Rémi Denis-Courmont 
	<remi.denis-courmont@...ia.com>
Subject: Re: recvmmsg() timeout behavior strangeness

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html