Re: [PATCH mptcp-next] mptcp: ignore unsupported msg flags

[Florian Westphal <fw@strlen.de>]

Paolo Abeni <pabeni@redhat.com> wrote:
> Looking at the code even MSG_DONTWAIT, MSG_EOR, MSG_MORE, MSG_OOB
> MSG_ZEROCOPY has some effect on TCP.

We handle DONTWAIT in mptcp, and the other ones, afaics, do not result
in a user-visible change (i.e., if we would not support DONTWAIT, we
would cause userspace do block in send() even if userspace specifically
asked for us not to, so that would be a bug).

But for the others I think ignoring is fine.

> MSG_ZEROCOPY needs to be enabled via setsockopt()
> 
> Currently we implement MSG_DONTWAIT, silently ignore MSG_MORE and we
> bail on MSG_OOB, MSG_EOR, MSG_ZEROCOPY
> 
> > > should we define a 'bail on use' mask with a subset of the above? The
> > > candidates I see are:
> >  
> > > MSG_TRUNC
> > > MSG_PEEK
> > > MSG_OOB
> > 
> > Looks like we only need to handle FASTOPEN.
> 
> LGTM, for sendmsg() sake: ignoring MSG_OOB and MSG_EOR does not look
> too evil to me ;)

Agree.

> Than there is recvmsg()...
> 
> With a quick code inspections looks like TCP support:
> MSG_PEEK, MSG_TRUNC, MSG_OOB, MSG_WAITALL, MSG_DONTWAIT, MSG_DONTWAIT, 
> MSG_ERRQUEUE
> 
> MSG_ERRQUEUE requires to be enabled via IP_RECVERR()
> 
> We currently implement MSG_WAITALL and MSG_DONTWAIT, soon MSG_PEEK and
> we bail on all the others.
> 
> Ignoring MSG_ERRQUEUE or MSG_TRUNC may silently break user-space
> application.

Indeed.

> I think we could provide a dummy impl for MSG_ERRQUEUE: always
> returning empty msg, which will be consistent with the lack of
> setsockopt support. We could even call into inet_recv_error(), as the
> relevant queue will always be empty, and could possibly simplify a
> complete implementation someday.
> 
> I also think we should bail on MSG_TRUNC, and silently ignore all the
> others.
> 
> WDYT?

Sounds good.  MSG_TRUNC support should be easy to add as well.