netdev - Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

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, 21 May 2009 14:51:22 -0300
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Caitlin Bestler <caitlin.bestler@...il.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Chris Van Hoof <vanhoof@...hat.com>,
	Clark Williams <williams@...hat.com>
Subject: Re: [RFC 1/2] net: Introduce recvmmsg socket syscall

Em Thu, May 21, 2009 at 10:26:58AM -0700, Caitlin Bestler escreveu:
> On Thu, May 21, 2009 at 9:55 AM, Arnaldo Carvalho de Melo
> <acme@...stprotocols.net> wrote:
> 
> >
> > I.e. recvmmsg would save the value of sk->sk_rcvtimeo at entry and
> > restore at exit, and would somehow go on subtracting the time
> > sock_recvmsg() took from it so that the following call finds a reduced
> > sk->sk_rcvtimeo iif it was configured in the first place and the socket
> > is in blocking mode.
> >
> > How does that sound?
> >
> 
> I suspect that an additional timeout value will be needed ultimately.

So you mean we need a timeout to wait for a datagram, that remains being
sk->sk_rcvtimeo (SO_RCVTIMEO), and one that is passed as a parameter to
recvmmsg?
 
> Essentially there is the existing timeout (how long will I wait before I
> want to be told that there have been no messages) and an additional
> "delivery pending" timeout (how long can the delivery of a message
> be delayed to attempt to coalesce it with other messages).

I gather this is an yes for the question I asked above :)
 
> There is also one sticky compliance issue with SCTP, delivery of an
> UNORDERED message MUST NOT be delayed waiting for other traffic.
> There is no guarantee that the local client will be scheduled immediately,
> just a prohibition on delaying delivery for the purpose of bundling.
> 
> That might mean a specific transport would have to support multiple
> conditional timeouts: maximum delay after an SCTP Event, after an
> UNORDERED message, after a message with PPID X, etc. Or for
> TCP after a PUSH FLAG, or after certain flags have been set, etc.
> 
> Those could probably be reduced to delivering immediately after
> any message that the transport flags as "urgent", and *all* error
> completions are urgent (which is what the code first shown does).

checking if MSG_OOB is set in the last datagram returned by the
unlocked_recvmsg call, that would make recvmmsg return imediately even
if in blocking mode and not having filled the array, ok.
 
> The specific transport could then use setsockopt to control what
> messages qualified as "urgent" in a transport specific manner.

OK

- Arnaldo
--
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