in-kernel PM: closed subflows before RM_ADDR will not decrement add_addr_accepted
#498
Comments
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Dec 11, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]>
MPTCPimporter
pushed a commit
that referenced
this issue
Dec 11, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: #498 Signed-off-by: Gang Yan <[email protected]> Message-Id: <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Dec 11, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Dec 11, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Dec 11, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Dec 11, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Dec 12, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
|
Hi Matt, I assigned this issue to myself since my colleague Gang Yan is looking at it. |
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Dec 12, 2024
This patch fixes an issue where an invalid address is announce as a signal, the 'add_addr_accepted' is incorrectly added several times when 'retransmit ADD_ADDR'. So we need to update this variable when the connection is removed from conn_list by mptcp_worker. So that the available address can be added in time. In fact, the 'add_addr_accepted' is only declined when 'RM_ADDR' by now, so when subflows are getting closed from the other peer, the new signal is not accepted as well. We noticed there have exist some problems related to this.I think this patch effectively resolves them. Closes: multipath-tcp/mptcp_net-next#498 Signed-off-by: Gang Yan <[email protected]> Signed-off-by: NipaLocal <nipa@local>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(Linked to #496 - maybe can be marked as fixed once this modification is in place if we are OK to take this direction)
If subflows are removed from the list of subflows (closed from the other peer, error, never established, etc.) before receiving a
RM_ADDR, theRM_ADDRwill not decrement theadd_addr_acceptedcounter if there is no other subflows using the remote ID from theRM_ADDR.In other words, when subflows are getting closed, the in-kernel PM might need to do some extra actions, like decrementing the
add_addr_acceptedcounter if there is no other subflows using the remote ID of the ones getting removed.The text was updated successfully, but these errors were encountered: