[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTScNSGYxWtB-D_iL_7TQO=z4r5_29-W8d=VRwh1M6Ym_UQ@mail.gmail.com>
Date: Tue, 23 Sep 2014 10:57:41 -0400
From: Willem de Bruijn <willemb@...gle.com>
To: Chuck Ebbert <cebbert.lkml@...il.com>
Cc: Network Development <netdev@...r.kernel.org>
Subject: Re: LTP recv/recvmsg tests failing on 3.17
On Tue, Sep 23, 2014 at 10:11 AM, Chuck Ebbert <cebbert.lkml@...il.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.
--
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
Powered by blists - more mailing lists