[MPTCP][PATCH v7 mptcp-next 0/5] Add REMOVE_ADDR support
by Geliang Tang
v7:
- add RM_ADDR mib
- update RM_ADDR selftests test case
v6:
- rename lookup_anno_list_by_saddr to remove_anno_list_by_saddr as
Paolo suggested.
- add msk socket lock when traverse msk->conn_list as Paolo suggested.
- Since the first three patches in v5 have been merged to export
branch, drop them from this patchset.
- add remove addr and subflow selftest test case.
- this patchset is against mptcp_net-next's export branch.
v5:
- merge mptcp_nl_remove_subflow() and mptcp_nl_remove_addr()
- add cond_resched
- reduce the indentation level in mptcp_pm_nl_rm_addr_received
v4:
- update mptcp_subflow_shutdown()'s args.
- add rm_id check to make sure we don't shutdown the first subflow.
- add conn_list empty check.
- move anno_list to mptcp_pm_data.
- add a new patch 'mptcp: add remove subflow support'.
v3:
- fix memory leak and lock issue in v2.
- drop alist in v2.
- fix mptcp_subflow_shutdown's arguments.
- bzero remote in mptcp_pm_create_subflow_or_signal_addr.
- add more commit message.
Geliang Tang (5):
mptcp: remove addr and subflow in PM netlink
mptcp: add RM_ADDR mib
selftests: mptcp: drop first flag in do_rnd_write
selftests: mptcp: add remove addr and subflow test case
selftests: mptcp: add RM_ADDR mib check function
net/mptcp/mib.c | 1 +
net/mptcp/mib.h | 1 +
net/mptcp/options.c | 2 +
net/mptcp/pm.c | 7 +-
net/mptcp/pm_netlink.c | 87 ++++++++++++++++++-
net/mptcp/protocol.c | 2 +
net/mptcp/protocol.h | 2 +
.../selftests/net/mptcp/mptcp_connect.c | 7 +-
.../testing/selftests/net/mptcp/mptcp_join.sh | 67 ++++++++++++++
9 files changed, 166 insertions(+), 10 deletions(-)
--
2.17.1
1 week, 4 days
[MPTCP][PATCH v8 mptcp-next 0/8] Add REMOVE_ADDR support
by Geliang Tang
v8:
- drop anno_list in v7.
We don't need to add a new list, conn_list is enough for the signal
address and local subflow.
- fix local_id and remote_id issues.
The RM_ADDR logic uses an address id to identify the removing
address, so we must make sure the subflow's local_id and remote_id be
set properly.
- fix mptcp_pm_nl_rm_addr_received logic issue
- update selftests
v7:
- add RM_ADDR mib
- update RM_ADDR selftests test case
v6:
- rename lookup_anno_list_by_saddr to remove_anno_list_by_saddr as
Paolo suggested.
- add msk socket lock when traverse msk->conn_list as Paolo suggested.
- Since the first three patches in v5 have been merged to export
branch, drop them from this patchset.
- add remove addr and subflow selftest test case.
- this patchset is against mptcp_net-next's export branch.
v5:
- merge mptcp_nl_remove_subflow() and mptcp_nl_remove_addr()
- add cond_resched
- reduce the indentation level in mptcp_pm_nl_rm_addr_received
v4:
- update mptcp_subflow_shutdown()'s args.
- add rm_id check to make sure we don't shutdown the first subflow.
- add conn_list empty check.
- move anno_list to mptcp_pm_data.
- add a new patch 'mptcp: add remove subflow support'.
v3:
- fix memory leak and lock issue in v2.
- drop alist in v2.
- fix mptcp_subflow_shutdown's arguments.
- bzero remote in mptcp_pm_create_subflow_or_signal_addr.
- add more commit message.
Geliang Tang (8):
mptcp: remove addr and subflow in PM netlink
mptcp: fix mptcp_pm_nl_rm_addr_received logic issue
mptcp: implementing mptcp_pm_remove_subflow
mptcp: fix every subflow's local_id is zero
mptcp: fix subflow's remote_id is zero issue
mptcp: add RM_ADDR related mibs
selftests: mptcp: add remove cfg in mptcp_connect
selftests: mptcp: add remove addr and subflow test cases
net/mptcp/mib.c | 2 +
net/mptcp/mib.h | 2 +
net/mptcp/pm.c | 25 ++-
net/mptcp/pm_netlink.c | 105 +++++++++++--
net/mptcp/protocol.c | 4 +
net/mptcp/protocol.h | 5 +-
net/mptcp/subflow.c | 8 +-
.../selftests/net/mptcp/mptcp_connect.c | 18 ++-
.../testing/selftests/net/mptcp/mptcp_join.sh | 142 +++++++++++++++++-
9 files changed, 288 insertions(+), 23 deletions(-)
--
2.17.1
1 week, 4 days
[MPTCP][PATCH v7 mptcp-next 0/4] add ADD_ADDR echo flag support
by Geliang Tang
v7:
- add accept_subflow re-check
v6:
- add "drop re-check mechanism for PM's flags"
v5:
- move READ_ONCE(msk->pm.add_addr_echo) into mptcp_pm_add_addr_signal
- move mptcp_pm_announce_addr into mptcp_pm_nl_add_addr_received and
mptcp_pm_add_addr_received
v4:
- Just updated some log messages in mptcp_join.sh
v3:
- move add_addr_echo into mptcp_pm_announce_addr()
- check return value of mptcp_pm_add_add_received
- hold lock for add_addr_echo writing
v2:
- add ADD_ADDR mibs
- add selftests for ADD_ADDR
v1:
- mptcp: send out ADD_ADDR with echo flag
Geliang Tang (4):
mptcp: send out ADD_ADDR with echo flag
mptcp: add ADD_ADDR related mibs
selftests: mptcp: add ADD_ADDR mibs check function
mptcp: add accept_subflow re-check
net/mptcp/mib.c | 2 +
net/mptcp/mib.h | 2 +
net/mptcp/options.c | 34 +++++++++-----
net/mptcp/pm.c | 28 ++++++------
net/mptcp/pm_netlink.c | 4 +-
net/mptcp/protocol.h | 6 ++-
.../testing/selftests/net/mptcp/mptcp_join.sh | 44 +++++++++++++++++++
7 files changed, 92 insertions(+), 28 deletions(-)
--
2.17.1
2 weeks
[PATCH net-next] tcp: propagate MPTCP skb extensions on xmit splits
by Paolo Abeni
When the TCP stack splits a packet on the write queue, the tail
half currently lose the associated skb extensions, and will not
carry the DSM on the wire.
The above does not cause functional problems and is allowed by
the RFC, but interact badly with GRO and RX coalescing, as possible
candidates for aggregation will carry different TCP options.
This change tries to improve the MPTCP behavior, propagating the
skb estensions on split.
Additionally, we must prevent the MPTCP stack from updating the
mapping after the split occour: that will both violate the RFC and
fool the reader.
Signed-off-by: Paolo Abeni <pabeni(a)redhat.com>
---
include/net/mptcp.h | 21 ++++++++++++++++++++-
net/ipv4/tcp_output.c | 3 +++
net/mptcp/protocol.c | 7 +++++--
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/include/net/mptcp.h b/include/net/mptcp.h
index 3525d2822abe..fbf0849632cb 100644
--- a/include/net/mptcp.h
+++ b/include/net/mptcp.h
@@ -29,7 +29,8 @@ struct mptcp_ext {
use_ack:1,
ack64:1,
mpc_map:1,
- __unused:2;
+ frozen:1,
+ __unused:1;
/* one byte hole */
};
@@ -107,6 +108,19 @@ static inline void mptcp_skb_ext_move(struct sk_buff *to,
from->active_extensions = 0;
}
+static inline void mptcp_skb_ext_copy(struct sk_buff *to,
+ struct sk_buff *from)
+{
+ struct mptcp_ext *from_ext;
+
+ from_ext = skb_ext_find(from, SKB_EXT_MPTCP);
+ if (!from_ext)
+ return;
+
+ skb_ext_copy(to, from);
+ from_ext->frozen = 1;
+}
+
static inline bool mptcp_ext_matches(const struct mptcp_ext *to_ext,
const struct mptcp_ext *from_ext)
{
@@ -195,6 +209,11 @@ static inline void mptcp_skb_ext_move(struct sk_buff *to,
{
}
+static inline void mptcp_skb_ext_copy(struct sk_buff *to,
+ struct sk_buff *from)
+{
+}
+
static inline bool mptcp_skb_can_collapse(const struct sk_buff *to,
const struct sk_buff *from)
{
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 85ff417bda7f..c66f5bd5f64f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1411,6 +1411,7 @@ int tcp_fragment(struct sock *sk, enum tcp_queue tcp_queue,
if (!buff)
return -ENOMEM; /* We'll just try again later. */
skb_copy_decrypted(buff, skb);
+ mptcp_skb_ext_copy(buff, skb);
sk_wmem_queued_add(sk, buff->truesize);
sk_mem_charge(sk, buff->truesize);
@@ -1966,6 +1967,7 @@ static int tso_fragment(struct sock *sk, struct sk_buff *skb, unsigned int len,
if (unlikely(!buff))
return -ENOMEM;
skb_copy_decrypted(buff, skb);
+ mptcp_skb_ext_copy(buff, skb);
sk_wmem_queued_add(sk, buff->truesize);
sk_mem_charge(sk, buff->truesize);
@@ -2236,6 +2238,7 @@ static int tcp_mtu_probe(struct sock *sk)
skb = tcp_send_head(sk);
skb_copy_decrypted(nskb, skb);
+ mptcp_skb_ext_copy(nskb, skb);
TCP_SKB_CB(nskb)->seq = TCP_SKB_CB(skb)->seq;
TCP_SKB_CB(nskb)->end_seq = TCP_SKB_CB(skb)->seq + probe_size;
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 1fd80f8c7baa..198dcd7b2bd6 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -752,8 +752,11 @@ static bool mptcp_skb_can_collapse_to(u64 write_seq,
if (!tcp_skb_can_collapse_to(skb))
return false;
- /* can collapse only if MPTCP level sequence is in order */
- return mpext && mpext->data_seq + mpext->data_len == write_seq;
+ /* can collapse only if MPTCP level sequence is in order and this
+ * mapping has not been xmitted yet
+ */
+ return mpext && mpext->data_seq + mpext->data_len == write_seq &&
+ !mpext->frozen;
}
static bool mptcp_frag_can_collapse_to(const struct mptcp_sock *msk,
--
2.26.2
2 weeks, 3 days
[PATCH net-next] mptcp: Remove unused macro MPTCP_SAME_STATE
by YueHaibing
There is no caller in tree any more.
Signed-off-by: YueHaibing <yuehaibing(a)huawei.com>
---
net/mptcp/protocol.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 1aad411a0e46..e6216c4f308c 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -24,8 +24,6 @@
#include "protocol.h"
#include "mib.h"
-#define MPTCP_SAME_STATE TCP_MAX_STATES
-
#if IS_ENABLED(CONFIG_MPTCP_IPV6)
struct mptcp6_sock {
struct mptcp_sock msk;
--
2.17.1
2 weeks, 3 days
Amazonセキュリティ警告: サインインが検出されました
by Amazon.co.jp
サインインが検出されました
お客様いつもをご利用いただき、ありがとうございます。新しいデバイスからお客様のアカウントへのサインインが検出されました。
日時 [CURRENT_DATE] [CURRENT_TIME] Japan Standard Time
デバイス Google Chrome Windows (デスクトップ)
付近 Tokyo, Japan
これがお客様ご自身による操作だった場合、このメッセージは無視してください。
ご本人の操作ではない場合、以下のIPアドレスをクリックして、ID情報を更新してください。
支払方法の情報を更新する
注意：本通知メールは送信専用アドレスで送信しております。返信いただいても受信できませんのでご了承下さい。このメッセージは[RECEIVER_ADDRESS] に送信されました。
2 weeks, 3 days
URGENT BUSINESS PROPOSAL
by Miss.Aisha Gaddafi
--
Dearest One,
I am Miss Aisha Gaddafi, one of the daughters of the embattled
president of Libya, I am currently residing in one of the African
Countries, unfortunately as a refugee. At the meantime, my family is
the target of Western nations led by Nato who wants to destroy my
father at all costs. Our investments and bank accounts in several
countries are their targets to freeze.
I have been commissioned to contact an interested foreign
investor/partner who will be able to take
absolute control of part of the vast cash available to private account
with my late brother who was killed by NATO air strike, for a possible
investment in your country.
If this transaction interest you, you don’t have to disclose it to any
body because of what is going with my entire family, if the united
nation happens to know this account, they will freezing it as they
freeze others so keep this transaction for yourself only until we
finalize it.
I want to transfer this money into your account immediately for onward
investment in your country because I don’t want the united nation to
know about this account.
Therefore if you are capable of running an establishment and can
maintain the high level of secrecy required in this project, kindly
respond with the following information for details of the
project.Please
1. Your full names and address
2. Your private telephone and fax numbers
3. Your private email address
4. Age and profession
Best Regard
Miss.Aisha Gaddafi
2 weeks, 4 days
Dear I Need An Investment Partner
by aishiag85＠gmail.com
Dear I Need An Investment Partner
Assalamu Alaikum Wa Rahmatullahi Wa Barakatuh
Dear Friend,
I came across your e-mail contact prior a private search while in need of your assistance. I am Aisha Al-Qaddafi, the only biological Daughter of Former President of Libya Col. Muammar Al-Qaddafi. Am a single Mother and a Widow with three Children.
I have investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00 ) and i need a trusted investment Manager/Partner because of my current refugee status, however, I am interested in you for investment project assistance in your country, may be from there, we can build business relationship in the nearest future.
I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project on my behalf kindly reply urgent to enable me provide you more information about the investment funds.
Your Urgent Reply Will Be AppreciatedBest RegardsMrs Aisha Al-Qaddafi
2 weeks, 4 days
Amazon.co.jp アカウント所有権の証明（名前、その他個人情報）の確認
by Amazon.co.jp
平素は Amazon.co.jp をご利用いただき、誠にありがとうございます。
お客様のアカウントで異常なアクティビティが検出されたためAmazon アカウントを停止させていただいております。アカウントにログインして画面の指示に従うことで、アカウントのロックを解除していただけます。
Amazon ログイン
請求先情報の確認が完了するまで、お客様のアカウントへのアクセスを停止させていただきますので、ご了承ください。
異常なログインIP：211.29.17.218
何卒、よろしくお願い申し上げます。
Amazon.co.jpのまたのご利用をお待ちしております。
2 weeks, 4 days
ご贈与した金額がお客様のアカウントのAmazonギフト券残高に登録されました
by Amazon.co.jp
客様
ご贈与した金額がお客様のアカウントのAmazonギフト券残高に登録されました 、個人情報を更新してご使用ください
詳細
注文番号 # 503-9355619-3707859
ご注文内容
￥50000 チャージ金額
合計チャージ金額:
￥50000
注文日:
2020/08/27
ギフト券残高をチェック
Amazon.co.jp のまたのご利用をお待ちしております。
Amazon.co.jp
このEメールアドレスは配信専用です。このメッセージに返信しないようお願いいたします。
2 weeks, 5 days
