From: Rao Shoaib <rao.shoaib at oracle.com>
To: mptcp at lists.01.org
Subject: Re: [MPTCP] [Weekly meetings] MoM - 16th of April 2018
Date: Thu, 26 Apr 2018 14:25:24 -0700 [thread overview]
Message-ID: <ab963222-29d5-d93d-ae42-f3fd6e3be948@oracle.com> (raw)
In-Reply-To: 20180426205206.GA19260@MacBook-Pro-6.local
[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]
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
>
next reply other threads:[~2018-04-26 21:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-26 21:25 Rao Shoaib [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-04-30 18:35 [MPTCP] [Weekly meetings] MoM - 16th of April 2018 Rao Shoaib
2018-04-30 16:34 Christoph Paasch
2018-04-27 0:43 Rao Shoaib
2018-04-26 22:20 Christoph Paasch
2018-04-26 20:52 Christoph Paasch
2018-04-26 19:04 Rao Shoaib
2018-04-26 18:31 Rao Shoaib
2018-04-26 17:27 Matthieu Baerts
2018-04-24 10:46 Matthieu Baerts
2018-04-23 20:13 Rao Shoaib
2018-04-16 17:18 Matthieu Baerts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ab963222-29d5-d93d-ae42-f3fd6e3be948@oracle.com \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.