[PATCH 0/6] IPv6 support
by Peter Krystad
Implemented support for IPv6. selftests pass with ipv6=true, but
they take twice as long to run...
With re-factoring the addition of IPv6 is very clean but I did not
split files yet as it will be hard to squash any changes after the
such a split.
Still to do: multiple subflows, handling IPv4-mapped connections.
Peter Krystad (6):
mptcp: Reference af_ops routines through struct ipv4_specific
mptcp: Re-factor create socket/subflow routines to be af-agnostic
mptcp: Re-factor mptcp_stream_ops routines to be af-agnostic
mptcp: Re-factor subflow routines to be af-agnostic
mptcp: Export low-level routines for IPv6
mptcp: Add IPv6 support
include/net/mptcp.h | 3 +
include/net/tcp.h | 3 +
net/ipv6/tcp_ipv6.c | 16 +++-
net/mptcp/ctrl.c | 11 +++
net/mptcp/protocol.c | 174 +++++++++++++++++++++++++++++++--------
net/mptcp/protocol.h | 9 +-
net/mptcp/subflow.c | 191 +++++++++++++++++++++++++++++++++++++------
7 files changed, 342 insertions(+), 65 deletions(-)
--
2.17.2
1 year, 2 months
[PATCH] mptcp: fix stray wake-up event
by Paolo Abeni
We always need to set subflow->data_avail after each tcp_read_sock()
or mptcp_subflow_recv_lookup() may pick the wrong sock.
Squash-to: "mptcp: recvmsg() can drain data from multiple subflows"
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
net/mptcp/protocol.c | 18 +++++++++---------
net/mptcp/subflow.c | 1 +
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 3af5f121af9e..696f1d03a61d 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -473,6 +473,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
read_descriptor_t desc;
struct socket *ssock;
struct tcp_sock *tp;
+ bool done = false;
struct sock *ssk;
int copied = 0;
int target;
@@ -498,7 +499,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
len = min_t(size_t, len, INT_MAX);
target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);
- while (copied < len) {
+ while (!done) {
u32 map_remaining;
int bytes_read;
@@ -515,7 +516,7 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
tp = tcp_sk(ssk);
lock_sock(ssk);
- while (mptcp_subflow_data_available(ssk)) {
+ while (mptcp_subflow_data_available(ssk) && !done) {
/* try to read as much data as available */
map_remaining = subflow->map_data_len -
mptcp_subflow_get_map_offset(subflow);
@@ -526,8 +527,8 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
if (bytes_read < 0) {
if (!copied)
copied = bytes_read;
- release_sock(ssk);
- goto out;
+ done = true;
+ continue;
}
pr_debug("msk ack_seq=%llx -> %llx", msk->ack_seq,
@@ -535,13 +536,13 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
msk->ack_seq += bytes_read;
copied += bytes_read;
if (copied >= len) {
- release_sock(ssk);
- goto out;
+ done = true;
+ continue;
}
if (tp->urg_data && tp->urg_seq == tp->copied_seq) {
pr_err("Urgent data present, cannot proceed");
- release_sock(ssk);
- goto out;
+ done = true;
+ continue;
}
}
release_sock(ssk);
@@ -590,7 +591,6 @@ static int mptcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
mptcp_wait_data(sk, &timeo);
}
-out:
release_sock(sk);
return copied;
}
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 7bae7c35ea6b..f08c4b713978 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -576,6 +576,7 @@ bool mptcp_subflow_data_available(struct sock *sk)
}
if (!subflow_check_data_avail(sk)) {
+ subflow->data_avail = 0;
/* set EoF only there is no data available - we already spooled
* all the pending skbs
*/
--
2.21.0
1 year, 2 months
[Weekly meetings] MoM - 24th of October 2019
by Matthieu Baerts
Hello,
Yesterday, we had our 72nd meeting with Mat, Peter and Ossama (Intel
OTC), Paolo, Florian and Davide (RedHat) and myself (Tessares).
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Accepted patches:
- mptcp: recvmsg refactor follow-up:
- by Paolo
- fix tests
- Accepted by Matth & Mat
- Fix issues in prerequisite [IPv6] patches:
- by Peter
- 3 patches: 1 has been applied, accepted by Matth
Pending patches:
- mptcp: switch mptcp_poll to use parent sock wait queue:
- include: mptcp: sendmsg scheduler skeleton
- include: mptcp_poll should not block on each subflow:
- by Florian
- v2
- Accepted by Paolo
- *Waiting for application*
- selftests: mptcp: increase test coverage:
- include: selftests: fixes and improvements
- include: prepare for mptcp ipv6 support
- by Florian
- v3 sent + 1 new one
- *Waiting for review*
- mptcp: Add DATA_FIN transmission and handling:
- by Mat
- RFC
- Commented by Paolo, Christoph
- new version expected
- IPv6 support:
- by Peter
- RFC
- Commented by Paolo, Matth
- new version expected
- Fix issues in prerequisite [IPv6] patches:
- by Peter
- 3 patches: 2 are left on review
- Paolo raised a question about IPv4 mapped in IPv6: add the
support for later?
- new version expected
- selftests:mptcp: increase timeout:
- by Matth
- v2
- *Waiting for review*
- Fix bug processing options:
- by Peter
- *Waiting for review*
Remaining items for the initial submission: Planning:
- Part 1 (mainly TCP changes, will be sent with Part 2):
- MAINTAINERS file
- Part 2 (minimum set for MPTCP, up to KSelftests, one subflow):
- MPTCPv1 support
- opti in TCP options?
- Send DATA_FIN, no corner cases
- Part 3 (after the KSelftests, to be sent ideally before the end
of the year)
- Full DATA_FIN support
- Shared recv window
- Active backup support
Remaining items for the initial submission: Update:
- IPv6 support → part 2:
- Peter is working on a v2
- MPTCP v1 support → part 2:
- Paolo started to look at the RFC to support Christoph
- Christoph will be the submitter of the patch
- *Matth*: publish a branch with mptcp.org + MPTCPv1
- is it OK to have v0 then switch to v1 in the same series?
- maybe better to do the squashing to have a clearer code
(hoping the v1 simplify a bit some parts)
- will check if we squash or not when we have the code
- DATA_FIN → part 3 (after kselftests):
- Mat is working on it
- working on top of the recent changes done and the
mptcp_rcvmesg refactor
- trying to list the different corner cases (e.g. this is the
last packet and it is dropped)
- maybe we can have only the sending part for the moment
without the corner cases in the part 2 (before kselftests, after TCP)
- Mat will look at that perspective
- Shared recv window → part 3 (after kselftests, OK because we only
support one subflow before that):
- work to be done
- Active backup support → part 3 (after kselftests) or 4 (extra):
- Paolo is working on it
- receive part is done
- send side is handle by Florian
- found one issue with MP_JOIN
- optimisation of options in TCP "struct mptcp_options_received":
- Peter has a patch to share
- MAINTAINERS file
timeout in selftest:
- we will try to have default "series" around ~45seconds
IPv4 mapped in IPv6:
- add the support for later
- only support v4 only and v6 only
Feedback from netdev:
- nope :'(
- could be good to send a message to the list, explaining with
other words what we have sent, what it would be useful for us
- it is likely possible that we will not get any replies if we
don't ask or send something else
- Mat was asking if it could help if someone else was sending the
patches? Maybe just unlucky: reviewers were maybe busy
Patchwork:
- we need username
- Mat will check with Peter which one to use
- *Matth* will send the list to Patchwork maintainers
- Mat added their email in the subscribers list
Netdev?:
-
https://netdevconf.info/0x14/news.html?netdev-0x14-call-for-submissions
- In Vancouver
- close to Seattle
- Submission: around January
Next meeting:
- We propose to have it next Thursday, the 31st of October.
- *NOT* the usual time if you are going to change the clock this
weekend: 16:00 UTC (9am PDT, *5pm CET*)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20191031
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you next week,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
1 year, 2 months
Patchwork: "maintainer status"
by Matthieu Baerts
Hi,
After the last meeting, we said it would be interesting to have
patchwork to easily list pending patches with their status and not
having to maintain the list manually.
I contacted Patchwork maintainers and it seems they are OK to add MPTCP
to the list of projects. But they are asking 2 questions:
> - do you want all of your team to have maintainer status in
patchwork? (ie, should they all be able to update patch states?)
I don't know exactly who would need to have this. I guess everybody who
did a review with an "accept" ("LGTM") should be able to directly change
the status, no?
Patchwork maintainers are asking me to give them a list of usernames.
With the web interface, I can only get your user ID and email address
but not your username. May you reply to me in private (or to the list)
with your username?
(The username you used to log-in: https://patchwork.ozlabs.org )
I didn't find any user account for Peter and Ossama. I don't know if you
would like to be added to the list of people who can change the status
of the pending patches for the kernel but if yes, you can create an
account on the website:
https://patchwork.ozlabs.org/register/
> - are you able to subscribe <email> to your mailing list, without
requiring a confirmation step?
I guess that's a question for Mat :)
Cheers,
Matt
--
Matthieu Baerts | R&D Engineer
matthieu.baerts(a)tessares.net
Tessares SA | Hybrid Access Solutions
www.tessares.net
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium
1 year, 2 months