[MPTCP] Re: [RFC PATCH 0/2] mptcp: fix deadlock in mptcp{,6}_release

[MPTCP] Re: [RFC PATCH 0/2] mptcp: fix deadlock in mptcp{,6}_release

[Mat Martineau]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Tue, 2 Mar 2021, Paolo Abeni wrote:

> This address the issue the easy way: removing the bugged feature
> (mcast support :).
>
> AFAICS the mcast related sockopt manipulate a global state, so there
> could be existing working application doing setsockopt(mcast opt) on
> TCP sockets. This is why I did not disable mcast at the inet level
> for stream sockets.
>
> Still I'm wondering if we should take the opposite approach: explicitly
> forbitting all setsockopt except the one we implement in
> net/mptcp/protocol.c
>

I think there was mailing list discussion about having an allowed list of 
SOL_TCP options, but I think applying that idea to the inet level slipped 
by. It does seem better to only allow the options we implement.

(by the way: it's forbid/forbidding)


Mat


> Additionally this possibly overlap with wider task - a more
> comprehensive sockopt support. Ence the RFC tag.
>
> Side note: syzbot confirm this fixes issues/170
>
> Paolo Abeni (2):
>  mptcp: forbit mcast-related sockopt on MPTCP sockets
>  mptcp: revert "mptcp: provide subflow aware release function"$ ....$
>
> net/mptcp/protocol.c | 100 ++++++++++++++++++++-----------------------
> 1 file changed, 47 insertions(+), 53 deletions(-)
>
> -- 
> 2.26.2
> _______________________________________________
> mptcp mailing list -- mptcp(a)lists.01.org
> To unsubscribe send an email to mptcp-leave(a)lists.01.org
>

--
Mat Martineau
Intel

[MPTCP] Re: [RFC PATCH 0/2] mptcp: fix deadlock in mptcp{,6}_release

[Matthieu Baerts]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Hi Paolo, Mat,

On 03/03/2021 02:56, Mat Martineau wrote:
> On Tue, 2 Mar 2021, Paolo Abeni wrote:
> 
>> This address the issue the easy way: removing the bugged feature
>> (mcast support :).
>>
>> AFAICS the mcast related sockopt manipulate a global state, so there
>> could be existing working application doing setsockopt(mcast opt) on
>> TCP sockets. This is why I did not disable mcast at the inet level
>> for stream sockets.
>>
>> Still I'm wondering if we should take the opposite approach: explicitly
>> forbitting all setsockopt except the one we implement in
>> net/mptcp/protocol.c
>>
> 
> I think there was mailing list discussion about having an allowed list 
> of SOL_TCP options, but I think applying that idea to the inet level 
> slipped by. It does seem better to only allow the options we implement.

Yes and probably easier to maintain a list of what has been implemented 
and/or validated (who mentioned packetdrill???) than having to block one 
because it can cause warnings or crashes.

BTW thank you for looking at that!

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net