Compliment
by Mrs Chantal
Compliment of the day to you. I am Mrs.CHANTAL I am sending this brief
letter to solicit your partnership to transfer $13.5 Million US
Dollars.I shall send you more information and procedures when I receive
positive response From you. Please send me a message in My private
email address is ( mrschantal066(a)gmail.com )
Best Regards
MrS.Chantal
9 months
[mptcp] df1036da90: kernel-selftests.net/mptcp.mptcp_join.sh.fail
by kernel test robot
Greeting,
FYI, we noticed the following commit (built with gcc-7):
commit: df1036da90108b1a9969721beab34f4c76228bcc ("mptcp: fix splat when incoming connection is never accepted before exit/close")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: kernel-selftests
with following parameters:
group: kselftests-mptcp
test-description: The kernel contains a set of "self tests" under the tools/testing/selftests/ directory. These are intended to be small unit tests to exercise individual code paths in the kernel.
test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <rong.a.chen(a)intel.com>
# selftests: net/mptcp: mptcp_join.sh
# Created /tmp/tmp.tJp80eCxLb (size 1 KB) containing data sent by client
# Created /tmp/tmp.D33y0DtjVU (size 1 KB) containing data sent by server
# no JOIN syn[ ok ] - synack[ ok ] - ack[ ok ]
# single subflow, limited by client syn[ ok ] - synack[ ok ] - ack[ ok ]
# single subflow, limited by server syn[ ok ] - synack[ ok ] - ack[ ok ]
# single subflow syn[ ok ] - synack[ ok ] - ack[ ok ]
# multiple subflows syn[fail] got 1 JOIN[s] syn expected 2
# - synack[fail] got 1 JOIN[s] synack expected 2
# - ack[fail] got 0 JOIN[s] ack expected 2
# Server ns stats
# MPTcpExtMPCapableSYNRX 1 0.0
# MPTcpExtMPCapableACKRX 1 0.0
# MPTcpExtMPJoinSynRx 1 0.0
# Client ns stats
# MPTcpExtMPJoinSynAckRx 1 0.0
# multiple subflows, limited by server syn[ ok ] - synack[ ok ] - ack[ ok ]
# unused signal address syn[ ok ] - synack[ ok ] - ack[ ok ]
# signal address syn[ ok ] - synack[ ok ] - ack[ ok ]
# subflow and signal syn[ ok ] - synack[ ok ] - ack[ ok ]
# multiple subflows and signal syn[ ok ] - synack[ ok ] - ack[ ok ]
not ok 3 selftests: net/mptcp: mptcp_join.sh # exit=1
To reproduce:
# build kernel
cd linux
cp config-5.7.0-rc1-00171-gdf1036da90108 .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Rong Chen
9 months
[PATCH] mptcp: attempt skb coalescing when moving skbs to mptcp rx queue
by Florian Westphal
We can try to coalesce the skbs we take from the subflows rx queue
with the tail of the mptcp rx queue.
If successful, the skb head can be discarded early.
We can also free the skb extensions, we do not access them after
this so no need to hold on to them.
Only caveat: do not built too fat skbs. They are only free'd once
userspace has read all data.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index d868b3d921fd..ab4a712b2529 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -144,12 +144,34 @@ static void __mptcp_move_skb(struct mptcp_sock *msk, struct sock *ssk,
unsigned int offset, size_t copy_len)
{
struct sock *sk = (struct sock *)msk;
+ struct sk_buff *tail;
__skb_unlink(skb, &ssk->sk_receive_queue);
- skb_set_owner_r(skb, sk);
- __skb_queue_tail(&sk->sk_receive_queue, skb);
+ skb_ext_reset(skb);
+ skb_orphan(skb);
msk->ack_seq += copy_len;
+
+ tail = skb_peek_tail(&sk->sk_receive_queue);
+ if (offset == 0 && tail) {
+ bool fragstolen;
+ int delta;
+
+ /* don't coalesce when tail is already fat.
+ * skbs are only free'd once all of the data was
+ * copied to userspace.
+ */
+ if (tail->len < GSO_MAX_SIZE &&
+ skb_try_coalesce(tail, skb, &fragstolen, &delta)) {
+ kfree_skb_partial(skb, fragstolen);
+ atomic_add(delta, &sk->sk_rmem_alloc);
+ sk_mem_charge(sk, delta);
+ return;
+ }
+ }
+
+ skb_set_owner_r(skb, sk);
+ __skb_queue_tail(&sk->sk_receive_queue, skb);
MPTCP_SKB_CB(skb)->offset = offset;
}
--
2.26.2
9 months
Good day,
by Caroline Edward
Good day,
Am Caroline Edward, a staff Sergeant in the US Army presently serving in Syria as a combat instructor, I sincerely apologize for intruding into your privacy, this might come as a surprise to you, but nothing is more distressing to me at this time as i find myself forced by events beyond my control, i have summoned courage to contact you. Am 45 years old lady, am a widow and I had a son who is now 16 years of age.
Some money in various currencies where discovered in barrels at a farm house in the middle East during a rescue operation in Iraq War,and it was agreed by Staff Sergeant Kenneth Buff and myself that some part of these money be shared between both of us, I was given a total of ($5 Million US Dollars) as my own share , I kept this money in a consignment for a long while with a security Company which i declared and deposit as my personal effects and it has been secured and protected for years now with the diplomatic Delivery Service.
Now, the WAR in Iraq is over, and all possible problems that could have emanated from the shared money has been totally cleaned up and all file closed, all what was discovered in the Middle East is no more discussed, am now ready to retire from active services, but, i need a trustworthy person that can help me take possession of this funds and keep it safe while i work on my relief letters to join you so that we could discuss possible business partnership together with the money.
But I tell you what! No compensation can make up for the risk we are taken with our lives.You can confirm the genuineness of the findings by clicking on this web site: http://news.bbc.co.uk/2/hi/middle_east/2988455.stm
I’m seeking your kind assistance to move the sum of US$5 Million Dollars to you as far as I can be assured that the money will be safe in your care until I complete my service here in (SYRIA) before the end of the month. The most important thing is; “Can I Trust you”?,As an officers on ACTIVE DUTY am not allowed access to money, therefore, i have declared the content of the consignment as personal effect that i would like to be delivered to a friend. You will be rewarded with 30% of this funds for your help, all that i required is your trust between us till the money get to you.
Sincerely,
Sgt. Caroline Edward.
Email: mrs.carolineedward(a)gmail.com
9 months
[PATCH v3 mptcp-next 1/2] mptcp: adjust tcp rcvspace after moving skbs from ssk to sk queue
by Florian Westphal
TCP does tcp rcvbuf tuning when copying packets to userspace, e.g. in
tcp_read_sock(). In case of mptcp, that function is only rarely used
(when discarding retransmitted duplicate data).
Instead, skbs are moved from the tcp rx queue to the mptcp socket rx
queue.
Adjust subflow rcvbuf when we do so, its the last spot where we can
adjust the ssk rcvbuf -- later we only have the mptcp-level socket.
This greatly improves performance on mptcp bulk transfers.
Signed-off-by: Florian Westphal <fw(a)strlen.de>
---
net/mptcp/protocol.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index ba9d3d5c625f..dbb86cbb9e77 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -248,6 +248,9 @@ static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk,
*bytes = moved;
+ if (moved)
+ tcp_rcv_space_adjust(ssk);
+
return done;
}
@@ -1263,6 +1266,7 @@ static int mptcp_init_sock(struct sock *sk)
return ret;
sk_sockets_allocated_inc(sk);
+ sk->sk_rcvbuf = sock_net(sk)->ipv4.sysctl_tcp_rmem[1];
sk->sk_sndbuf = sock_net(sk)->ipv4.sysctl_tcp_wmem[2];
return 0;
--
2.26.2
9 months
[PATCH v2 mptcp-next 0/2] mptcp: adjust tcp rcvbuf size
by Florian Westphal
This is a v2 of the patch I sent to netdev previously.
No change. The second patch is new: It makes sure we track/use the
largest rcvbuf size of a subflow.
Futhermore, msk rcvbuf tracking is only done from the recvmsg path.
i.e., if userspace never calls recvmsg, the msk socket rcvbuffer won't
be adjusted.
This still provides the same benefits as 1/2 while preventing unbounded
growth to tcp_rmem[2].
9 months
general protection fault in sock_recvmsg
by syzbot
Hello,
syzbot found the following crash on:
HEAD commit: caffb99b Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15a74441100000
kernel config: https://syzkaller.appspot.com/x/.config?x=c33c7f7c5471fd39
dashboard link: https://syzkaller.appspot.com/bug?extid=d7cface3f90b13edf5b0
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141034ba100000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=119cd016100000
The bug was bisected to:
commit 263e1201a2c324b60b15ecda5de9ebf1e7293e31
Author: Paolo Abeni <pabeni(a)redhat.com>
Date: Thu Apr 30 13:01:51 2020 +0000
mptcp: consolidate synack processing.
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=119d8626100000
final crash: https://syzkaller.appspot.com/x/report.txt?x=139d8626100000
console output: https://syzkaller.appspot.com/x/log.txt?x=159d8626100000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+d7cface3f90b13edf5b0(a)syzkaller.appspotmail.com
Fixes: 263e1201a2c3 ("mptcp: consolidate synack processing.")
general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
CPU: 1 PID: 7226 Comm: syz-executor523 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:sock_recvmsg_nosec net/socket.c:886 [inline]
RIP: 0010:sock_recvmsg+0x92/0x110 net/socket.c:904
Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 44 89 6c 24 04 e8 53 18 1d fb 4d 8d 6f 20 4c 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 ef e8 20 12 5b fb bd a0 00 00 00 49 03 6d
RSP: 0018:ffffc90001077b98 EFLAGS: 00010202
RAX: 0000000000000004 RBX: ffffc90001077dc0 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffff86565e59 R09: ffffed10115afeaa
R10: ffffed10115afeaa R11: 0000000000000000 R12: 1ffff9200020efbc
R13: 0000000000000020 R14: ffffc90001077de0 R15: 0000000000000000
FS: 00007fc6a3abe700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004d0050 CR3: 00000000969f0000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
mptcp_recvmsg+0x18d5/0x19b0 net/mptcp/protocol.c:891
inet_recvmsg+0xf6/0x1d0 net/ipv4/af_inet.c:838
sock_recvmsg_nosec net/socket.c:886 [inline]
sock_recvmsg net/socket.c:904 [inline]
__sys_recvfrom+0x2f3/0x470 net/socket.c:2057
__do_sys_recvfrom net/socket.c:2075 [inline]
__se_sys_recvfrom net/socket.c:2071 [inline]
__x64_sys_recvfrom+0xda/0xf0 net/socket.c:2071
do_syscall_64+0xf3/0x1b0 arch/x86/entry/common.c:295
entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x448ef9
Code: e8 cc 14 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 9b 0c fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fc6a3abdda8 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
RAX: ffffffffffffffda RBX: 00000000006dec28 RCX: 0000000000448ef9
RDX: 0000000000001000 RSI: 00000000200004c0 RDI: 0000000000000003
RBP: 00000000006dec20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000040000000 R11: 0000000000000246 R12: 00000000006dec2c
R13: 00007ffe4730174f R14: 00007fc6a3abe9c0 R15: 00000000006dec2c
Modules linked in:
---[ end trace 097bdf143c3a60db ]---
RIP: 0010:sock_recvmsg_nosec net/socket.c:886 [inline]
RIP: 0010:sock_recvmsg+0x92/0x110 net/socket.c:904
Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 44 89 6c 24 04 e8 53 18 1d fb 4d 8d 6f 20 4c 89 e8 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 ef e8 20 12 5b fb bd a0 00 00 00 49 03 6d
RSP: 0018:ffffc90001077b98 EFLAGS: 00010202
RAX: 0000000000000004 RBX: ffffc90001077dc0 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffff86565e59 R09: ffffed10115afeaa
R10: ffffed10115afeaa R11: 0000000000000000 R12: 1ffff9200020efbc
R13: 0000000000000020 R14: ffffc90001077de0 R15: 0000000000000000
FS: 00007fc6a3abe700(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004d0050 CR3: 00000000969f0000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller(a)googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
9 months
mptcp@lists.01.org Covid/Pay/2020/ Covid Relief Fund
by Covid Relief Fund
mptcp(a)lists.01.org Covid/Pay/2020/ Covid Relief Fund
The world banks is making available $400,000 via the
International Monetary fund as financial support aid for
individuals globally.This is due to the current global corona
virus pandemic.
Your email is selected in a category ''A'' beneficiary program.To
claim the funds ,provide your full name with this code
Covid/Pay/2020/ to the email address provided below..
Stay safe.
Andrew Tweedie
Finance Department Director
International Monetary Fund(IMF)
CORONA RELIEF FUND.
TEL:+1 917 382 1952
covidofficeincc(a)barid.com
9 months, 1 week
