On 04/26/2018 01:52 PM, Christoph Paasch wrote:
>
> This kind of lock-taking also causes trouble with RCU LOCKDEP debugging - as
> I mentioned in a previous e-mail.
I have not looked into it so I can not comment. I am sure we will find a 
way to address it.
>
> And beyond that, it requires that everytime a TCP-change is being done, one
> needs to take MPTCP into account. E.g., when upstream added the SOCK_DESTROY
> interface (and Samsung backported it to v4.4), there were panics on Android
> devices (https://github.com/multipath-tcp/mptcp/issues/170).
>
> Avoid taking the meta-socket lock on subflow-work allows for much easier
> maintenance in the long-term.
The bug that you have pointed out is a run of the mill bug that we see 
everyday, there is nothing special about it.

Taking meta lock actually simplifies things a lot and has reduced 
maintainable cost, not taking the meta lock will create timing issues 
left and right. So we are just trading one headache with another.

Holding meta lock should not be piped up unnecessarily. Yes, if possible 
if should be changed, plus our patch has only 6 cases in TCP.

Shoaib.

[1] If MPTCP is built on top of TCP, any change in TCP will always have 
to worry about MPTCP particularly in the control path. There is a 
overhead of adding MPTCP on TCP and no one can argue against it.

>
>
> Christoph
>