linux-kernel - Re: [PATCH/RFC] Re: recvmmsg() timeout behavior strangeness [RESEND]

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: <20140527203010.GA2764@kernel.org>
Date:	Tue, 27 May 2014 17:30:10 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Ondřej Bílka <neleai@...nam.cz>,
	Caitlin Bestler <caitlin.bestler@...il.com>,
	Neil Horman <nhorman@...driver.com>,
	Elie De Brauwer <eliedebrauwer@...il.com>,
	David Miller <davem@...emloft.net>,
	Steven Whitehouse <steve@...gwyn.com>,
	Rémi Denis-Courmont 
	<remi.denis-courmont@...ia.com>, Paul Moore <paul@...l-moore.com>,
	Chris Friesen <chris.friesen@...driver.com>
Subject: Re: [PATCH/RFC] Re: recvmmsg() timeout behavior strangeness [RESEND]

Em Tue, May 27, 2014 at 09:28:37PM +0200, Michael Kerrisk (man-pages) escreveu:
> On Tue, May 27, 2014 at 9:21 PM, Arnaldo Carvalho de Melo
> <acme@...stprotocols.net> wrote:
> > Em Tue, May 27, 2014 at 06:35:17PM +0200, Michael Kerrisk (man-pages) escreveu:
> >> On 05/26/2014 11:17 PM, Arnaldo Carvalho de Melo wrote:
> >> > Can you try the attached patch on top of the first one?
> >
> >> Patches on patches is a way to make your testers work unnecessarily
> >> harder. Also, it means that anyone else who was interested in this
> >
> > It was meant to highlight the changes with regard to the previous patch,
> > i.e. to make things easier for reviewing.
> 
> (I don't think that works...)

Lets try both then, attached goes the updated patch, and this is the
diff to the last combined one:

diff --git a/net/socket.c b/net/socket.c
index 310a50971769..379be43879db 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2478,8 +2478,7 @@ SYSCALL_DEFINE5(recvmmsg, int, fd, struct mmsghdr __user *, mmsg,
 
 	datagrams = __sys_recvmmsg(fd, mmsg, vlen, flags, &timeout_sys);
 
-	if (datagrams > 0 &&
-	    copy_to_user(timeout, &timeout_sys, sizeof(timeout_sys)))
+	if (copy_to_user(timeout, &timeout_sys, sizeof(timeout_sys)))
 		datagrams = -EFAULT;
 
 	return datagrams;
 
------------------------------------------

This is a quick thing just to show where the problem lies, need to think
how to report an -EFAULT at this point properly, i.e. look at
__sys_recvmmsg for something related (returning the number of
successfully copied datagrams to userspace while storing the error for
subsequent reporting):

        if (err == 0)
                return datagrams;

        if (datagrams != 0) {
                /*
                 * 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
                         * 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).
                         */
                        sock->sk->sk_err = -err;
                }

                return datagrams;
        }

I.e. userspace would have to use getsockopt(SO_ERROR)... need to think
more about it, sidetracked now, will be back to this.

Anyway, attached goes the current combined patch.

- Arnaldo

> >> thread likely got lost at this point, because they probably didn't
> >> save the first patch. All of this to say: it makes life much easier
> >> if you provide a complete new self-contained patch on each iteration.
> >
> > If you prefer it that way, find one attached, that I was about to send
> > (but you can wait till I use your program to test it ;-) )
> >
> >> > It starts adding explicit parentheses on a ternary, as David requested,
> >> > and then should return the remaining timeouts in cases like signals,
> >> > etc.
> >> >
> >> > Please let me know if this is enough.
> >>
> >> Nope, it doesn't fix the problem. (I applied both patches against 3.15-rc7)
> >
> > What was the problem experienced?
> 
> The problem is that after EINTR, the timeout is not updated with the
> remaining time until expiry. (This was true with just patch 1 applied,
> and is also true with both patch 1 and patch 2 applied.)
> 
> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

View attachment "recvmmsg-timeout-v3.patch" of type "text/plain" (78114 bytes)