summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorMatthieu Baerts (NGI0) <matttbe@kernel.org>2025-02-24 19:11:51 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2025-03-07 16:45:47 +0100
commit3d7e7ef8fa1aa8094ca9972cc2eff6b3c68e203a (patch)
tree770cd8669d3832f7bc4d4cc130c99faee7f60958 /include
parenta05da2be18aae7e82572f8d795f41bb49f5dfc7d (diff)
downloadlinux-3d7e7ef8fa1aa8094ca9972cc2eff6b3c68e203a.tar.gz
linux-3d7e7ef8fa1aa8094ca9972cc2eff6b3c68e203a.tar.bz2
linux-3d7e7ef8fa1aa8094ca9972cc2eff6b3c68e203a.zip
mptcp: reset when MPTCP opts are dropped after join
commit 8668860b0ad32a13fcd6c94a0995b7aa7638c9ef upstream. Before this patch, if the checksum was not used, the subflow was only reset if map_data_len was != 0. If there were no MPTCP options or an invalid mapping, map_data_len was not set to the data len, and then the subflow was not reset as it should have been, leaving the MPTCP connection in a wrong fallback mode. This map_data_len condition has been introduced to handle the reception of the infinite mapping. Instead, a new dedicated mapping error could have been returned and treated as a special case. However, the commit 31bf11de146c ("mptcp: introduce MAPPING_BAD_CSUM") has been introduced by Paolo Abeni soon after, and backported later on to stable. It better handle the csum case, and it means the exception for valid_csum_seen in subflow_can_fallback(), plus this one for the infinite mapping in subflow_check_data_avail(), are no longer needed. In other words, the code can be simplified there: a fallback should only be done if msk->allow_infinite_fallback is set. This boolean is set to false once MPTCP-specific operations acting on the whole MPTCP connection vs the initial path have been done, e.g. a second path has been created, or an MPTCP re-injection -- yes, possible even with a single subflow. The subflow_can_fallback() helper can then be dropped, and replaced by this single condition. This also makes the code clearer: a fallback should only be done if it is possible to do so. While at it, no need to set map_data_len to 0 in get_mapping_status() for the infinite mapping case: it will be set to skb->len just after, at the end of subflow_check_data_avail(), and not read in between. Fixes: f8d4bcacff3b ("mptcp: infinite mapping receiving") Cc: stable@vger.kernel.org Reported-by: Chester A. Unal <chester.a.unal@xpedite-tech.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/544 Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Tested-by: Chester A. Unal <chester.a.unal@xpedite-tech.com> Link: https://patch.msgid.link/20250224-net-mptcp-misc-fixes-v1-2-f550f636b435@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions