| Message ID | cover.1614706783.git.pabeni@redhat.com |
|---|---|
| Headers | show |
| Series | mptcp: fix deadlock in mptcp{,6}_release | expand |
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@lists.01.org > To unsubscribe send an email to mptcp-leave@lists.01.org > -- Mat Martineau Intel
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