[PATCH net-next 0/6] mptcp: avoid workqueue usage for data
by Paolo Abeni
The current locking schema used to protect the MPTCP data-path
requires the usage of the MPTCP workqueue to process the incoming
data, depending on trylock result.
The above poses scalability limits and introduces random delays
in MPTCP-level acks.
With this series we use a single spinlock to protect the MPTCP
data-path, removing the need for workqueue and delayed ack usage.
This additionally reduces the number of atomic operations required
per packet and cleans-up considerably the poll/wake-up code.
Paolo Abeni (6):
mptcp: open code mptcp variant for lock_sock
mptcp: implement wmem reservation
mptcp: protect the rx path with the msk socket spinlock
mptcp: allocate TX skbs in msk context
mptcp: avoid a few atomic ops in the rx path
mptcp: use mptcp release_cb for delayed tasks
include/net/sock.h | 1 +
net/core/sock.c | 2 +-
net/mptcp/mptcp_diag.c | 2 +-
net/mptcp/options.c | 47 +--
net/mptcp/protocol.c | 733 ++++++++++++++++++++++++++++++-----------
net/mptcp/protocol.h | 34 +-
net/mptcp/subflow.c | 14 +-
7 files changed, 598 insertions(+), 235 deletions(-)
--
2.26.2
1 year, 6 months
Address ID assignment in netlink PM
by Othman, Ossama
Hi Paolo,
While debugging a netlink PM "get addr" issue I was having in mptcpd I found that the address ID assigned by mptcpd was being overridden by the kernel. Based on the code in pm_nl_ctl.c in the MPTCP self tests, and the code in pm_netlink.c in the kernel, the MPTCP_PM_CMD_ADD_ADDR command accepts an optional address ID attribute. When that attribute is available the ID is stored in the corresponding mptcp_pm_addr_entry instance by mptcp_pm_parse_addr():
if (tb[MPTCP_PM_ADDR_ATTR_ID])
entry->addr.id = nla_get_u8(tb[MPTCP_PM_ADDR_ATTR_ID]);
However, that value is later overridden in mptcp_pm_nl_append_new_local_addr():
entry->addr.id = pernet->next_id++;
That causes the userspace to lose track of an address it added with a specific ID, at which point the only way to find out the new ID is to dump the addrs to find the new ID corresponding to local address in question. Is this the intended behavior? It seems like userspace- and kernel-based address ID assignment should be mutually exclusive. Otherwise we run into this sort of scenario. Is there a need for the kernel to assign IDs in the netlink PM case?
Please let me know if I'm misunderstanding how ID assignment is expected to work when using the netlink PM.
Thanks for your help!
-Ossama
1 year, 6 months
[MPTCP][PATCH mptcp-next 0/2] remove address when netlink flush addrs and testcase
by Geliang Tang
This patchset removes address when netlink do flush addrs command, and
adds the testcase for flush addrs command.
Geliang Tang (2):
mptcp: remove address when netlink flush addrs
selftests: mptcp: add the flush addrs testcase
net/mptcp/pm_netlink.c | 15 ++++--
.../testing/selftests/net/mptcp/mptcp_join.sh | 52 +++++++++++++------
2 files changed, 47 insertions(+), 20 deletions(-)
--
2.26.2
1 year, 6 months
[PATCH net] mptcp: fix NULL ptr dereference on bad MPJ
by Paolo Abeni
If an msk listener receives an MPJ carrying an invalid token, it
will zero the request socket msk entry. That should later
cause fallback and subflow reset - as per RFC - at
subflow_syn_recv_sock() time due to failing hmac validation.
Since commit 4cf8b7e48a09 ("subflow: introduce and use
mptcp_can_accept_new_subflow()"), we unconditionally dereference
- in mptcp_can_accept_new_subflow - the subflow request msk
before performing hmac validation. In the above scenario we
hit a NULL ptr dereference.
Address the issue doing the hmac validation earlier.
Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()")
Tested-by: Davide Caratti <dcaratti(a)redhat.com>
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
net/mptcp/subflow.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index ac4a1fe3550b..953906e40742 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -543,9 +543,8 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
fallback = true;
} else if (subflow_req->mp_join) {
mptcp_get_options(skb, &mp_opt);
- if (!mp_opt.mp_join ||
- !mptcp_can_accept_new_subflow(subflow_req->msk) ||
- !subflow_hmac_valid(req, &mp_opt)) {
+ if (!mp_opt.mp_join || !subflow_hmac_valid(req, &mp_opt) ||
+ !mptcp_can_accept_new_subflow(subflow_req->msk)) {
SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
fallback = true;
}
--
2.26.2
1 year, 7 months
[Weekly meetings] MoM - 26th of November 2020
by Matthieu Baerts
Hello everyone,
Today, we just had our 126th meeting with Davide, Paolo and Florian
(RedHat) and myself (Tessares).
Christoph, Mat and Ossama were not able to join, still trying to handle
Maradona's loss... Be brave guys! (and turkeys too!)
Thanks again for this new good meeting!
Here are the minutes of the meeting:
Accepted patches:
- The list of accepted patches can be seen on PatchWork:
https://patchwork.ozlabs.org/project/mptcp/list/?state=3
netdev (if mptcp ML is in cc) (Florian Westphal, Mat Martineau,
Paolo Abeni):
1405745 [net-next,v2] mptcp: be careful on MPTCP-level ack.
1405649 [net-next] mptcp: put reference in mptcp timeout timer
1405488 [net-next] mptcp: be careful on MPTCP-level ack.
1403243 [net-next,10/10] mptcp: refine MPTCP-level ack scheduling
1403242 [net-next,09/10] mptcp: track window announced to peer
1403241 [net-next,08/10] selftests: mptcp: add ADD_ADDR IPv6 test cases
1403240 [net-next,07/10] mptcp: send out dedicated ADD_ADDR packet
1403239 [net-next,06/10] mptcp: change add_addr_signal type
1403238 [net-next,05/10] mptcp: keep unaccepted MPC subflow into join list
1403237 [net-next,04/10] selftests: mptcp: add link failure test case
1403233 [net-next,03/10] mptcp: skip to next candidate if subflow has
unacked...
1403234 [net-next,02/10] mptcp: fix state tracking for fallback socket
1403236 [net-next,01/10] mptcp: drop WORKER_RUNNING status bit
our repo (by: Florian Westphal, Geliang Tang, Paolo Abeni):
1406513 [net] mptcp: fix NULL ptr dereference on bad MPJ
1406183 [mptcp-next,3/3] mptcp: parse and act on incoming FASTCLOSE option
1406182 [mptcp-next,2/3] tcp: parse mptcp options contained in reset
packets
1406180 [mptcp-next,1/3] mptcp: hold mptcp socket before calling tcp_done
1405424 [net-next,v2] mptcp: be careful on MPTCP-level ack.
1404620 [net-next] mptcp: use the variable sk instead of open-coding
1404614 [mptcp-next] Squash to "mptcp: protect the rx path with the msk
socke...
1403573 [v4,mptcp-next,2/2] mptcp: rename add_addr_signal and
mptcp_add_addr_...
1403572 [v4,mptcp-next,1/2] mptcp: drop rm_addr_signal flag
1403526 [net-next] Squash-to: "mptcp: use mptcp release_cb for delayed
tasks"
1403370 squashto: mptcp: protect the rx path with the msk socket spinlock
1403303 [net-next] Squash-to: "mptcp: protect the rx path with the msk
socket...
1403300 [net-next] Squash-to: "mptcp: open code mptcp variant for
lock_sock"
Pending patches:
- The list of pending patches can be seen on PatchWork:
https://patchwork.ozlabs.org/project/mptcp/list/?state=*
netdev (if mptcp ML is in cc) (by: Paolo Abeni):
1406703 [net] mptcp: fix NULL ptr dereference on bad MPJ
our repo (by: Florian Westphal, Geliang Tang, Paolo Abeni):
1370700: RFC: [RFC,2/4] tcp: move selected mptcp helpers to tcp.h/mptcp.h
1370702: RFC: [RFC,4/4] tcp: parse tcp options contained in reset packets
1375893: RFC: [RFC,mptpcp-next] mptcp: add ooo prune support:
- Parked
1395128: Changes Requested: [1/5] tcp: make two mptcp helpers available
to tcp stack
1395131: Changes Requested: [3/5] mptcp: add mptcp reset option support
1395133: Changes Requested: [5/5] mptcp: send fastclose if userspace
closes socket with unread data:
- Can be switched to RFC
1403495: Changes Requested: [mptcp-next,1/5] mptcp: add the outgoing
MP_PRIO support
1403497: Changes Requested: [mptcp-next,2/5] mptcp: add the incoming
MP_PRIO support
1403498: Changes Requested: [mptcp-next,3/5] mptcp: deal with
MPTCP_PM_ADDR_FLAG_BACKUP in PM netlink
1403499: Changes Requested: [mptcp-next,4/5] mptcp: add the mibs for MP_PRIO
1403500: Changes Requested: [mptcp-next,5/5] selftests: mptcp: add the
MP_PRIO testcases:
- Mat did a review, new version needed (or reply?)
1405799: Changes Requested: [v6,mptcp-next,1/9] mptcp: create the
listening socket for new port
1405800: Changes Requested: [v6,mptcp-next,2/9] mptcp: set the listening
socket's subflow
1405801: Changes Requested: [v6,mptcp-next,3/9] mptcp: release the
listening socket
1405802: Changes Requested: [v6,mptcp-next,4/9] mptcp: add port number
check for MP_JOIN
1405803: Changes Requested: [v6,mptcp-next,5/9] mptcp: add port number
announced check
1405804: Changes Requested: [v6,mptcp-next,6/9] mptcp: deal with
MPTCP_PM_ADDR_ATTR_PORT in PM netlink
1405805: Changes Requested: [v6,mptcp-next,7/9] selftests: mptcp: add
port argument for pm_nl_ctl
1405806: Changes Requested: [v6,mptcp-next,8/9] mptcp: add the mibs for
ADD_ADDR with port
1405807: Changes Requested: [v6,mptcp-next,9/9] selftests: mptcp: add
testcases for ADD_ADDR with port
1405894: Changes Requested: [mptcp-next] Squash to "mptcp: add port
number announced check":
- Paolo did a review, new version needed
- some architectural changes might be needed, see patch 2/9.
- we can continue the discussion by email
1406217: New: [net-next] mptcp: be careful on subflows shutdown:
- Applied by Matth just before the meeting
1406751: New: [v3] mptcp: let MPTCP create max size skbs:
- Paolo was sad nobody did a review for his patch sent 2 minutes
before the meeting :-/
Issues on Github:
https://github.com/multipath-tcp/mptcp_net-next/issues/
Recently opened (latest from last week: 113)
115 [syzkaller] WARNING in sk_stream_kill_queues [bug] [syzkaller]:
- Maybe a fix from Paolo, see:
1406217: mptcp: be careful on subflows shutdown
- now in the export branch
- @Christoph: may you try this please?
114 packetdrill: dss tolerance issue to emit the FIN+ACK [bug]
[packetdrill]:
- Maybe due to something else done in //?
Bugs (opened, flagged as "bug" and assigned)
94 Packetdrill: after a received DATA_FIN, no new packets can be
treated [bug] [packetdrill] @dcaratti:
- WIP
85 Packetdrill: multiple timeout reported by the CI [bug]
[packetdrill] @matttbe:
- WIP
Bugs (opened and flagged as "bug" and not assigned)
115 [syzkaller] WARNING in sk_stream_kill_queues [bug] [syzkaller]
114 packetdrill: dss tolerance issue to emit the FIN+ACK [bug]
[packetdrill]
112 sporadic failure of mptcp_join.sh selftest 13 [bug]
111 [syzkaller] divide error in __tcp_select_window [bug] [syzkaller]:
- closed by Paolo
110 [syzkaller] memory leak in __ip_mc_join_group [bug] [syzkaller]
108 [syzkaller] memory leak in sk_clone_lock [bug] [syzkaller]
107 Review use of WARN_ON() / WARN_ON_ONCE() [bug]
106 [syzkaller] BUG: Bad page state [bug] [syzkaller]
105 warning in `mptcp_reset_timer()` with `mptcp_connect.sh -m mmap`
[bug]:
- we should check if we can closed
- TODO: Matth
104 [syzkaller] general protection fault in skb_release_data [bug]
[syzkaller]
103 [syzkaller] WARNING in inet_csk_listen_stop [bug] [syzkaller]
99 simult_flows selftest is unstable: remaining sockets in
TIME-WAIT state [bug]
65 clearing properly the status in listen() [bug]
56 msk connection state set without msk lock [bug]
In Progress (opened and assigned)
96 Python: add support for IPPROTO_MPTCP [enhancement] @matttbe
76 [gs]etsockopt per subflow: BPF [enhancement] @matttbe
54 ADD_ADDR: ports support [enhancement] @geliangtang
51 MP_PRIO support [enhancement] @geliangtang
43 [syzkaller] Change syzkaller to exercise MPTCP inet_diag
interface [enhancement] [syzkaller] @cpaasch
Recently closed (since last week)
116 [syzkaller] WARNING in corrupted [bug] [syzkaller]
113 selftests: mptcp_connect MPTCP → TCP: file received by client
does not match [bug]
109 [syzkaller] memory leak in skb_ext_add [bug] [syzkaller]
70 [syzkaller] WARNING in mptcp_reset_timer [bug] [syzkaller]
FYI: Current Roadmap:
- Bugs: https://github.com/multipath-tcp/mptcp_net-next/projects/2
- Current merge window (5.11):
https://github.com/multipath-tcp/mptcp_net-next/projects/6
- For later: https://github.com/multipath-tcp/mptcp_net-next/projects/4
Patch prefix:
- When looking at patchwork, it is no always clear to distinct if
the patch is for MPTCP tree ("internal review") or netdev.
- Proposition of using tags:
- mptcp-next → for net-next (now or later):
- If it has a "Fixes" tag, applied at the bottom of the tree
- If not, new feature, at the end (or add instructions in
the comments)
- mptcp-net → for net (ASAP):
- to be applied at the bottom of the tree
- net-next → sent to netdev for net-next and mptcp ML is in CC
- net → sent to netdev for -net and mptcp ML is in CC
- not mandatory, just to help filtering patches :)
Address ID assignment in netlink PM:
- linked to Ossama's email
- idea was to keep the kernel side management simple
- we could let the userspace setting an ID but we need to be
careful if it sets a duplicated one, etc.
- but work needs to be done in the kernel side
Patches to send to netdev:
- net:
- Paolo's has some fixes
- net-next:
- workqueue removal thing
mptcp: use mptcp release_cb for delayed tasks
mptcp: avoid a few atomic ops in the rx path
mptcp: allocate TX skbs in msk context
mptcp: protect the rx path with the msk socket spinlock
mptcp: implement wmem reservation
mptcp: open code mptcp variant for lock_sock
- Paolo is going to send them
- some reports on top of net-next mention issues with some
selftests → this should be fixed by this rework. Maybe better to apply
these patches then.
Malformed MP_JOIN:
- Florian is looking at sending the RST directly instead of SYN+ACK
then RST later
- (also looking at the path taken in TCP code)
Extra tests:
- news about Syzkaller? (Christoph):
- See Github #115
- @Christoph: may you try to repro #115 please?
- news about interop with mptcp.org? (Christoph):
- /
- news about Intel's kbuild? (Mat):
- /
- packetdrill (Davide):
- Davide's daughter is going to review Florian's patches
- CI (Matth):
- ↓
Github Action:
- new IRC notif when a tag is published (e.g. CI has updated the
export branch)
- TODO: notif when issues are created or closed but not the comments
- TODO: notif for the builds
- TODO: port what is done by Tessares' CI to GH Actions.
Perf:
- Paolo was looking at removing an extra spinlock but didn't see diff
- the lack of tput improvement and the wide gap vs TCP is likely a
test artifact:
- MPTCP does not acquire the msk socket lock to enter the RX
path: each sendmsg over loopback ends-up enqueuing data to msk, doing
most of receiver work inside the sender process context. The sender is
the bottle-neck, while we have much free CPU time in the receiver
process, not used.
- TCP acquires the socket lock to enter the rx path, sendmsg
may find that held by the receiver and defer the rx processing to the
backlog. The processing is split among the sender and the receiver
process. The lookback tput is higher, but also the cumulative CPU
utilization.
- using two different VMs - one for the sender and one for the
receiver - should avoid the above artifact
mptcpd:
- https://bugzilla.redhat.com/show_bug.cgi?id=1899884
- Davide did a good job from start, already got some reviews so we
expect to have it included mid of December
Next meeting:
- We propose to have the next meeting on Thursday, the 3rd of December.
- Usual UTC time: 16:00 UTC (8am PST, 5pm CET, Midnight CST)
- Still open to everyone!
- https://annuel2.framapad.org/p/mptcp_upstreaming_20201203
Feel free to comment on these points and propose new ones for the next
meeting!
Talk to you on Thursday,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
1 year, 7 months
[PATCH net-next] mptcp: be careful on subflows shutdown
by Paolo Abeni
When the workqueue disposes of the msk, the subflows can still
receive some data from the peer after __mptcp_close_ssk()
completes.
The above could trigger a race between the msk receive path and the
msk destruction. Acquiring the mptcp_data_lock() in __mptcp_destroy_sock()
will not save the day: the rx path could be reached even after msk
destruction completes.
Instead use the subflow 'disposable' flag to prevent entering
the msk receive path after __mptcp_close_ssk().
Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
this could possibly fix issues#115, @Christoph could
you please have a spin on syzkaller?
---
net/mptcp/protocol.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index dd912697ffdd..2a8174a7e630 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -701,6 +701,13 @@ void mptcp_data_ready(struct sock *sk, struct sock *ssk)
int sk_rbuf, ssk_rbuf;
bool wake;
+ /* The peer can send data while we are shutting down this
+ * subflow at msk destruction time, but we must avoid enqueuing
+ * more data to the msk receive queue
+ */
+ if (unlikely(subflow->disposable))
+ return;
+
/* move_skbs_to_msk below can legitly clear the data_avail flag,
* but we will need later to properly woke the reader, cache its
* value
@@ -2118,6 +2125,8 @@ void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,
sock_orphan(ssk);
}
+ subflow->disposable = 1;
+
/* if ssk hit tcp_done(), tcp_cleanup_ulp() cleared the related ops
* the ssk has been already destroyed, we just need to release the
* reference owned by msk;
@@ -2125,8 +2134,7 @@ void __mptcp_close_ssk(struct sock *sk, struct sock *ssk,
if (!inet_csk(ssk)->icsk_ulp_ops) {
kfree_rcu(subflow, rcu);
} else {
- /* otherwise ask tcp do dispose of ssk and subflow ctx */
- subflow->disposable = 1;
+ /* otherwise ask tcp will dispose of ssk and subflow ctx */
__tcp_close(ssk, 0);
/* close acquired an extra ref */
--
2.26.2
1 year, 7 months
[PATCH mptcp-next 0/3] mptcp: add fastclose option
by Florian Westphal
This series adds receive side support for fastclose processing.
First patch is needed to avoid UAF after enabling option processing
for tcp resets. Second patch calls mptcp option parsing also for
reset patckets so fastclose-on-tcp-reset is handled.
Last patch adds fastclose handling.
I've submitted a pull request vs. packetdrill to add test cases for
this: https://github.com/multipath-tcp/packetdrill/pull/25
Those are the three test cases i posted earlier to this list plus
a 4th test to also cover the 'two subflows closed via fastclose+reset' case.
I would send the fastclose tx side next.
I plan to hold the MPTCP reset patches back for the time being until
netlink + mptcpd are aware of its existence.
include/net/tcp.h | 2 +-
net/ipv4/tcp_input.c | 13 ++++++++-----
net/ipv4/tcp_minisocks.c | 2 +-
net/mptcp/options.c | 15 +++++++++++++++
net/mptcp/protocol.c | 33 +++++++++++++++++++++++++++++++++
net/mptcp/protocol.h | 4 ++++
net/mptcp/subflow.c | 7 ++++++-
7 files changed, 68 insertions(+), 8 deletions(-)
1 year, 7 months
[PATCH net] mptcp: fix NULL ptr dereference on bad MPJ
by Paolo Abeni
If an msk listener receives an MPJ carrying an invalid token, it
will zero the request socket msk entry. That should later
cause fallback and subflow reset - as per RFC - at
subflow_syn_recv_sock() time due to failing hmac validation.
Since commit 4cf8b7e48a09 ("subflow: introduce and use
mptcp_can_accept_new_subflow()"), we unconditionally dereference
- in mptcp_can_accept_new_subflow - the subflow request msk
before performing hmac validation. In the above scenario we
hit a NULL ptr dereference.
Address the issue doing the hmac validation earlier.
Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()")
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
net/mptcp/subflow.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index ac4a1fe3550b..953906e40742 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -543,9 +543,8 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
fallback = true;
} else if (subflow_req->mp_join) {
mptcp_get_options(skb, &mp_opt);
- if (!mp_opt.mp_join ||
- !mptcp_can_accept_new_subflow(subflow_req->msk) ||
- !subflow_hmac_valid(req, &mp_opt)) {
+ if (!mp_opt.mp_join || !subflow_hmac_valid(req, &mp_opt) ||
+ !mptcp_can_accept_new_subflow(subflow_req->msk)) {
SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC);
fallback = true;
}
--
2.26.2
1 year, 7 months
[MPTCP][PATCH v4 mptcp-next 0/2] drop rm_addr_signal flag and more
by Geliang Tang
v4:
- add the current add_addr/rm_addr value for pm_warn
v3:
- use pr_warn
v2:
- use pr_err instead of WARN_ON_ONCE
Geliang Tang (2):
mptcp: drop rm_addr_signal flag
mptcp: rename add_addr_signal and mptcp_add_addr_status
net/mptcp/pm.c | 26 +++++++++++++++++++-------
net/mptcp/pm_netlink.c | 4 ++--
net/mptcp/protocol.h | 16 ++++++++--------
3 files changed, 29 insertions(+), 17 deletions(-)
--
2.26.2
1 year, 7 months
[PATCH net-next] mptcp: put reference in mptcp timeout timer
by Florian Westphal
On close this timer might be scheduled. mptcp uses sk_reset_timer for
this, so the a reference on the mptcp socket is taken.
This causes a refcount leak which can for example be reproduced
with 'mp_join_server_v4.pkt' from the mptcp-packetdrill repo.
The leak has nothing to do with join requests, v1_mp_capable_bind_no_cs.pkt
works too when replacing the last ack mpcapable to v1 instead of v0.
unreferenced object 0xffff888109bba040 (size 2744):
comm "packetdrill", [..]
backtrace:
[..] sk_prot_alloc.isra.0+0x2b/0xc0
[..] sk_clone_lock+0x2f/0x740
[..] mptcp_sk_clone+0x33/0x1a0
[..] subflow_syn_recv_sock+0x2b1/0x690 [..]
Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
Cc: Paolo Abeni <pabeni(a)redhat.com>
Cc: Davide Caratti <dcaratti(a)redhat.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 4b7794835fea..dc979571f561 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -1710,6 +1710,7 @@ static void mptcp_timeout_timer(struct timer_list *t)
struct sock *sk = from_timer(sk, t, sk_timer);
mptcp_schedule_work(sk);
+ sock_put(sk);
}
/* Find an idle subflow. Return NULL if there is unacked data at tcp
--
2.26.2
1 year, 7 months
