[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <82d10189f1ca99ccba4c161884d446cbb3246ce9.camel@redhat.com>
Date: Tue, 07 Dec 2021 11:37:35 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>,
Mat Martineau <mathew.j.martineau@...ux.intel.com>
Cc: netdev@...r.kernel.org, Maxim Galaganov <max@...ernet.ru>,
davem@...emloft.net, matthieu.baerts@...sares.net,
mptcp@...ts.linux.dev
Subject: Re: [PATCH net-next 10/10] mptcp: support TCP_CORK and TCP_NODELAY
On Mon, 2021-12-06 at 17:30 -0800, Jakub Kicinski wrote:
> On Fri, 3 Dec 2021 14:35:41 -0800 Mat Martineau wrote:
> > +static int mptcp_setsockopt_sol_tcp_nodelay(struct mptcp_sock *msk, sockptr_t optval,
> > + unsigned int optlen)
> > +{
> > + struct mptcp_subflow_context *subflow;
> > + struct sock *sk = (struct sock *)msk;
> > + int val;
> > +
> > + if (optlen < sizeof(int))
> > + return -EINVAL;
> > +
> > + if (copy_from_sockptr(&val, optval, sizeof(val)))
> > + return -EFAULT;
>
> Should we check that optval is not larger than sizeof(int) or if it is
> that the rest of the buffer is zero? Or for the old school options we
> should stick to the old school behavior?
I think it's useful if we keep the MPTCP socket options binary API as
close as possible to the plain TCP ones: that allows for seamless
switching existing TCP application to MPTCP with no code changes.
Old school, please ;)
Cheers,
Paolo
Powered by blists - more mailing lists