On Mon, 2020-02-10 at 12:52 +0100, Florian Westphal wrote:
> Mat Martineau <mathew.j.martineau(a)linux.intel.com> wrote:
> > Userspace should not be able to directly manipulate subflow socket
> > options before a connection is established since it is not yet known if
> > it will be an MPTCP subflow or a TCP fallback subflow. TCP fallback
> > subflows can be more directly controlled by userspace because they are
> > regular TCP connections, while MPTCP subflow sockets need to be
> > configured for the specific needs of MPTCP. Use the same logic as
> > sendmsg/recvmsg to ensure that socket option calls are only passed
> > through to known TCP fallback subflows.
> > 
> > Signed-off-by: Mat Martineau <mathew.j.martineau(a)linux.intel.com>
> > ---
> > 
> > One other question: is it racy to have __mptcp_tcp_fallback() return an
> > unlocked msk, then do the sock_hold(ssk) from an unlocked state?
> 
> Yes.
> 
> > It seems like if holding the ssk reference count is necessary at all it
> > should be done while the msk is still locked. I'm considering a change
> > to __mptcp_tcp_fallback() to have it not release the msk lock and
> > instead have all the callers do that.
> 
> Yes, that seems like the right thing to do.

Agreed.

I think that a separate patch for the above would be nicer.

Cheers,

Paolo