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]

Message-ID: <20090521165515.GK5956@ghostprotocols.net>
Date:	Thu, 21 May 2009 13:55:15 -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 09:38:47AM -0700, Caitlin Bestler escreveu:
> > +
> > +       while (datagrams < vlen) {
> > +               err = __sys_recvmsg(sock, (struct msghdr __user *)entry, flags);
> > +               if (err < 0)
> > +                       goto out_put;
> > +               err = __put_user(err, &entry->msg_len);
> > +               if (err)
> > +                       goto out_put;
> > +               ++entry;
> > +               ++datagrams;
> > +       }
> >  out_put:
> >        fput_light(sock->file, fput_needed);
> >  out:
> > +       /*
> > +        * We may return less entries than requested (vlen) if the
> > +        * sock is non block and there aren't enough datagrams.
> > +        */
> > +       if (err == 0 || (err == -EAGAIN && (flags & MSG_DONTWAIT)))
> > +               return datagrams;
> >        return err;
> >  }
> >
 
> There is an assumption here that unless MSG_DONTWAIT is set, or there
> is an error, that the caller will be willing to wait indefinitely for
> N messages to show up -- and that it is never worth waking up the
> caller earlier with less than N messages.
 
> I think an application would more typically want to wait at most m
> msecs after the first message is received to see if any other messages
> can be delivered at the same time.

> A busy server could simply use DONTWAIT in a polling loop every cycle,
> but it would be nice to be able to wait indefinitely for *any* of your
> clients to send you a message.
 
> Further, with some sockets there are some messages that are more equal
> than others.

> Although valid messages, with no errors, they should be delivered to
> user-mode immediately.

> The example that leaps to my mind immediately are SCTP Events,
> particularly with one-to-many sockets. You could be waiting for N
> messages, knowing that a specific peer has been asked to send N
> messages. The 2nd message could be an SCTP event announcing that the
> specific association has been torn down (and hence the remaining
> messages will not be arriving).  Waiting for a different association
> to send enough messages to complete the request will not provide very
> prompt service.

Good points, that will require some sort of change to sk->sk_rcvtimeo
handling so that the timeout for each datagram are deduced from the
configured timeout for the socket, so that the existing code doesn't
have to be changed.

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?

- 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