From: 'Arnaldo Carvalho de Melo' <acme@kernel.org>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
"Ondrej 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: [PATCH/RFC] Handle EFAULT in partial recvmmsg was Re: [PATCH/RFC] Re: recvmmsg() timeout behavior strangeness [RESEND]
Date: Thu, 29 May 2014 12:33:42 -0300 [thread overview]
Message-ID: <20140529153342.GJ2764@kernel.org> (raw)
In-Reply-To: <20140529141705.GI2764@kernel.org>
Em Thu, May 29, 2014 at 11:17:05AM -0300, 'Arnaldo Carvalho de Melo' escreveu:
> Em Thu, May 29, 2014 at 02:06:04PM +0000, David Laight escreveu:
> > From: 'Arnaldo Carvalho de Melo'
> > ...
> > > > I remember some discussions from an XNET standards meeting (I've forgotten
> > > > exactly which errors on which calls were being discussed).
> > > > My recollection is that you return success with a partial transfer
> > > > count for ANY error that happens after some data has been transferred.
> > > > The actual error will be returned when it happens again on the next
> > > > system call - Note the AGAIN, not a saved error.
> > > A saved error, for the right entity, in the recvmmsg case, that
> > > basically is batching multiple recvmsg syscalls, doesn't sound like a
> > > problem, i.e. the idea is to, as much as possible, mimic what multiple
> > > recvmsg calls would do, but reduce its in/out kernel (and inside kernel
> > > subsystems) overhead.
> > > Perhaps we can have something in between, i.e. for things like EFAULT,
> > > we should report straight away, effectively dropping whatever datagrams
> > > successfully received in the current batch, do you agree?
> > Not unreasonable - EFAULT shouldn't happen unless the application
> > is buggy.
> Ok.
So the patch below should handle it, and record that the packets were
dropped, not at the transport level, like UDP_MIB_INERRORS, for
instance, would indicate, but at the batching, recvmmsg level, so
perhaps we'll need a MIB variable for that.
Also a counterpart to the trace_kfree_skb(skb, udp_recvmsg) tracepoint
for dropwatch and similar tools to use, Neil?
I'm keeping this separate from the timeout update patch.
- Arnaldo
diff --git a/net/socket.c b/net/socket.c
index abf56b2a14f9..63491f015912 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2415,13 +2415,17 @@ out_put:
return datagrams;
if (datagrams != 0) {
+ if (err == -EFAULT) {
+ atomic_add(datagrams, &sock->sk->sk_drops);
+ return -EFAULT;
+ }
/*
* We may return less entries than requested (vlen) if the
* sock is non block and there aren't enough datagrams...
*/
if (err != -EAGAIN) {
/*
- * ... or if recvmsg returns an error after we
+ * ... or if recvmsg returns a socket error after we
* received some datagrams, where we record the
* error to return on the next call or if the
* app asks about it using getsockopt(SO_ERROR).
next prev parent reply other threads:[~2014-05-29 15:33 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
[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 ` 'Arnaldo Carvalho de Melo' [this message]
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=20140529153342.GJ2764@kernel.org \
--to=acme@kernel.org \
--cc=David.Laight@ACULAB.COM \
--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).