LTP recv/recvmsg tests failing on 3.17

LTP recv/recvmsg tests failing on 3.17

[Chuck Ebbert]

LTP tests recv01, recvfrom01 and recvmsg01 are reporting failure on
their "invalid flags" tests on 3.17. They pass a value of -1 for flags
and expect to get EINVAL back, but now they get EAGAIN. It looks like
this is due to:

commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b
Author: Willem de Bruijn <willemb@google.com>
Date:   Mon Aug 4 22:11:49 2014 -0400

    net-timestamp: TCP timestamping

which adds this hunk to net/ipv4/tcp.c:

@@ -1617,6 +1630,9 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
        struct sk_buff *skb;
        u32 urg_hole = 0;
 
+       if (unlikely(flags & MSG_ERRQUEUE))
+               return ip_recv_error(sk, msg, len, addr_len);
+
        if (sk_can_busy_loop(sk) && skb_queue_empty(&sk->sk_receive_queue) &&
            (sk->sk_state == TCP_ESTABLISHED))
                sk_busy_loop(sk, nonblock);

Before this change, the first flag tested was MSG_OOB, which eventually
causes EINVAL to be returned. Now this flag gets tested first, and
ip_recv_err() returns EAGAIN.

LTP setting every flag and expecting behavior to remain unchanged is
probably wrong, but is EAGAIN correct here? I can't find any spec for
this.

Re: LTP recv/recvmsg tests failing on 3.17

[Willem de Bruijn]

On Tue, Sep 23, 2014 at 10:11 AM, Chuck Ebbert <cebbert.lkml@gmail.com> wrote:
> LTP tests recv01, recvfrom01 and recvmsg01 are reporting failure on
> their "invalid flags" tests on 3.17. They pass a value of -1 for flags
> and expect to get EINVAL back, but now they get EAGAIN.
..
>
> Before this change, the first flag tested was MSG_OOB, which eventually
> causes EINVAL to be returned. Now this flag gets tested first, and
> ip_recv_err() returns EAGAIN.
>
> LTP setting every flag and expecting behavior to remain unchanged is
> probably wrong, but is EAGAIN correct here? I can't find any spec for
> this.

EINVAL does seem a suitable return value for invalid
combinations of flags, if those are explicitly checked. The
stack does not do this, though. Most flags are simply
ignored. For backward compatibility, this leniency is
likely required.

Previously, EINVAL was returned, but not  because msg_flags
contained an unsupported combination. MSG_OOB happened
to be the first tested flag in the set and happens to return
EINVAL when no urgent data is waiting.

I think applications simply cannot assume a consistent
return value when passing unsupported combinations
of flags. This is undefined behavior.

Re: LTP recv/recvmsg tests failing on 3.17

[Chuck Ebbert]

On Tue, 23 Sep 2014 10:57:41 -0400
Willem de Bruijn <willemb@google.com> wrote:

> I think applications simply cannot assume a consistent
> return value when passing unsupported combinations
> of flags. This is undefined behavior.

Yeah, I think LTP is wrong here. There is no explicit test for invalid
combinations of flags and it was assuming there was.

But I was also wondering why we return EAGAIN here for no data waiting,
when we return EINVAL for the same case with a different type of data.
There's no spec and it's not documented, so I guess the answer is "it's
always been that way."

Re: LTP recv/recvmsg tests failing on 3.17

[David Miller]

From: Willem de Bruijn <willemb@google.com>
Date: Tue, 23 Sep 2014 10:57:41 -0400

> I think applications simply cannot assume a consistent
> return value when passing unsupported combinations
> of flags. This is undefined behavior.

Agreed.

Re: LTP recv/recvmsg tests failing on 3.17

[Willem de Bruijn]

> But I was also wondering why we return EAGAIN here for no data waiting,
> when we return EINVAL for the same case with a different type of data.
> There's no spec and it's not documented, so I guess the answer is "it's
> always been that way."

EAGAIN is the common response. I don't know why TCP urgent
data returns EINVAL. It is unusual enough that the relevant line
in tcp_recv_urg explicitly comments on it:

                return -EINVAL; /* Yes this is right ! */