From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
"Ondřej Bílka" <neleai@seznam.cz>,
"Caitlin Bestler" <caitlin.bestler@gmail.com>,
"Neil Horman" <nhorman@tuxdriver.com>,
"Elie De Brauwer" <eliedebrauwer@gmail.com>,
"David Miller" <davem@davemloft.net>,
"Steven Whitehouse" <steve@chygwyn.com>,
"Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>,
"Paul Moore" <paul@paul-moore.com>,
"Chris Friesen" <chris.friesen@windriver.com>
Subject: Re: [PATCH/RFC] Re: recvmmsg() timeout behavior strangeness [RESEND]
Date: Mon, 26 May 2014 10:46:47 -0300 [thread overview]
Message-ID: <20140526134647.GB8176@kernel.org> (raw)
In-Reply-To: <537E0961.8040005@gmail.com>
Em Thu, May 22, 2014 at 04:27:45PM +0200, Michael Kerrisk (man-pages) escreveu:
> Hi Arnaldo,
>
> On 05/21/2014 11:05 PM, Arnaldo Carvalho de Melo wrote:
> > Em Mon, May 12, 2014 at 11:34:51AM -0300, Arnaldo Carvalho de Melo escreveu:
> >> Em Mon, May 12, 2014 at 12:15:25PM +0200, Michael Kerrisk (man-pages) escreveu:
> >>> Hi Arnaldo,
> >
> >>> Ping!
> >
> >> I acknowledge the problem, the timeout has to be passed to the
> >> underlying ->recvmsg() implementations that should return the time spent
> >> waiting for each packet, so that we can accrue that at recvmmsg level.
> >
> >> We can do either passing an extra timeout parameter to the recvmsg
> >> implementations or using some struct sock member to specify that
> >> timeout.
> >
> >> The first approach is intrusive, touches tons of files, so I'll try
> >> making it all mostly transparent by hooking into sock_rcvtimeo()
> >> somehow.
> >
> > But after thinking a bit more, looks like we need to do that, please
> > take a look at the attached patch to see if it addresses the problem.
> >
> > Mostly it adds a new timeop to the per protocol recvmsg()
> > implementations, that, if not NULL, should be used instead of
> > SO_RCVTIMEO.
> >
> > since the underlying recvmsg implementations already check that timeout,
> > return what is remaining, that will then be used in subsequent recvmsg
> > calls, at the end we just convert it back to timespec format.
> >
> > In most cases it is just passed to skb_recv_datagram, that will check
> > the pointer, use it and update if not NULL.
> >
> > Should have no problems, but I only did a boot with a system with this
> > patch applied, no problems noticed on a normal desktop session, ssh,
> > etc.
>
> Thanks! I applied this patch against 3.15-rc6.
>
> recvmmsg() now (mostly) does what I expect:
> * it waits until either the timeout expires or vlen messages
> have been received
> * If no message is received before timeout, it returns -1/EAGAIN.
> * If vlen messages are received before the timeout expires, then
> the remaining time is returned in timeout.
>
> One question: in the event that the call is interrupted by a signal
> handler, it fails (as expected) with EINTR, but the 'timeout' value is
> not updated with the remaining time on the timer. Would it be desirable
> to emulate the behavior of select() (and other syscalls) in this
> respect, and instead return the remaining time if interrupted by
> a signal?
I think so, will check how to achieve that!
> Cheers,
>
> Michael
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-05-26 13:46 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 13:59 recvmmsg() timeout behavior strangeness [RESEND] Michael Kerrisk (man-pages)
[not found] ` <536101C9.9090601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
[not found] ` <20140512143451.GB13801-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-05-21 21:05 ` [PATCH/RFC] " Arnaldo Carvalho de Melo
[not found] ` <20140521210535.GA5414-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
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 [this message]
[not found] ` <20140526134647.GB8176-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-05-26 21:17 ` Arnaldo Carvalho de Melo
2014-05-27 16:35 ` Michael Kerrisk (man-pages)
[not found] ` <5384BEC5.2080607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-27 19:21 ` Arnaldo Carvalho de Melo
[not found] ` <20140527192115.GD25474-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-05-27 19:22 ` Arnaldo Carvalho de Melo
2014-05-27 19:28 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkht1vubHueYPpkRu_W5B8OYW3rPUkHeLEq5WMVbCvO47w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-27 20:30 ` Arnaldo Carvalho de Melo
2014-05-28 5:00 ` Michael Kerrisk (man-pages)
[not found] ` <20140527203010.GA2764-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-05-28 12:20 ` Michael Kerrisk (man-pages)
2014-05-28 15:07 ` Arnaldo Carvalho de Melo
[not found] ` <20140528150720.GB2764-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-05-28 15:17 ` David Laight
2014-05-28 19:50 ` 'Arnaldo Carvalho de Melo'
[not found] ` <20140528195004.GD2764-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
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'
[not found] ` <20140529141705.GI2764-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
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)
[not found] ` <CAKgNAkj-MVfeqEeffWKMNok0yO-Rm1kyY+zhXEy-U9NkB+aLow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-06-24 20:25 ` Arnaldo Carvalho de Melo
[not found] ` <20140624202541.GD3456-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-06-27 11:29 ` Michael Kerrisk (man-pages)
2014-05-29 14:07 ` Michael Kerrisk (man-pages)
[not found] ` <5385D47A.3070401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-06-27 11:37 ` Michael Kerrisk (man-pages)
2014-05-23 19:00 ` David Miller
[not found] ` <20140523.150055.2214666905697701415.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2014-05-23 19:55 ` Arnaldo Carvalho de Melo
[not found] ` <20140523195522.GH2741-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2014-05-24 6:13 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140526134647.GB8176@kernel.org \
--to=acme@kernel.org \
--cc=caitlin.bestler@gmail.com \
--cc=chris.friesen@windriver.com \
--cc=davem@davemloft.net \
--cc=eliedebrauwer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=neleai@seznam.cz \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=paul@paul-moore.com \
--cc=remi.denis-courmont@nokia.com \
--cc=steve@chygwyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).