Re: [tcp] 9d9b1ee0b2: packetdrill.packetdrill/gtests/net/tcp/user_timeout/user-timeout-probe_ipv4-mapped-v6.fail

On Thu, Feb 18, 2021 at 8:33 PM kernel test robot wrote: > > > Greeting, > > FYI, we noticed the following commit (built with gcc-9): > > commit: 9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac ("tcp: fix TCP_USER_TIMEOUT > with zero window") >

Re: [PATCH net] tcp: make TCP_USER_TIMEOUT accurate for zero window probes

On Fri, Jan 22, 2021 at 9:45 PM Enke Chen wrote: > > Hi, Jakub: > > On Fri, Jan 22, 2021 at 06:34:24PM -0800, Jakub Kicinski wrote: > > On Fri, 22 Jan 2021 18:28:23 -0800 Enke Chen wrote: > > > Hi, Jakub: > > > > > > In terms of backporting, this patch should go together with: > > > > > >

Re: [PATCH] Revert "tcp: simplify window probe aborting on USER_TIMEOUT"

On Fri, Jan 8, 2021 at 11:38 PM Enke Chen wrote: > > From: Enke Chen > > This reverts commit 9721e709fa68ef9b860c322b474cfbd1f8285b0f. > > With the commit 9721e709fa68 ("tcp: simplify window probe aborting > on USER_TIMEOUT"), the TCP session does not terminate with > TCP_USER_TIMEOUT when data

Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode

On Wed, Jun 3, 2020 at 9:55 AM Eric Dumazet wrote: > > On Wed, Jun 3, 2020 at 5:02 AM Neal Cardwell wrote: > > > > On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet wrote: > > > > > > On Tue, Jun 2, 2020 at 10:05 PM Jason Xing > > > wrote: > > &g

Re: [PATCH] tcp: fix TCP socks unreleased in BBR mode

On Wed, Jun 3, 2020 at 1:44 AM Eric Dumazet wrote: > > On Tue, Jun 2, 2020 at 10:05 PM Jason Xing wrote: > > > > Hi Eric, > > > > I'm still trying to understand what you're saying before. Would this > > be better as following: > > 1) discard the tcp_internal_pacing() function. > > 2) remove

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte wrote: > > BBR in general will run with lower cwnd than e.g. Cubic or others. > That's a feature and necessary for WAN transfers. Please note that there's no general rule about whether BBR will run with a lower or

Re: TCP and BBR: reproducibly low cwnd and bandwidth

On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte wrote: > > BBR in general will run with lower cwnd than e.g. Cubic or others. > That's a feature and necessary for WAN transfers. Please note that there's no general rule about whether BBR will run with a lower or higher cwnd than CUBIC, Reno,

Re: [PATCH 4.9 00/75] 4.9.74-stable review

On Tue, Jan 2, 2018 at 3:08 PM, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, Jan 02, 2018 at 02:11:25PM -0500, Neal Cardwell wrote: ... >> Thanks, Greg and David. Looks like these 2 patches will cherry-pick >> cleanly if cherry-picked in the following sequence, on

Re: [PATCH 4.9 00/75] 4.9.74-stable review

On Tue, Jan 2, 2018 at 3:08 PM, Greg KH wrote: > On Tue, Jan 02, 2018 at 02:11:25PM -0500, Neal Cardwell wrote: ... >> Thanks, Greg and David. Looks like these 2 patches will cherry-pick >> cleanly if cherry-picked in the following sequence, on top of >> 4.9.74-rc1, which alr

Re: [PATCH 4.9 00/75] 4.9.74-stable review

On Tue, Jan 2, 2018 at 1:32 PM, David Miller <da...@davemloft.net> wrote: > From: Neal Cardwell <ncardw...@google.com> > Date: Tue, 2 Jan 2018 11:57:59 -0500 > >> On Mon, Jan 1, 2018 at 9:31 AM, Greg Kroah-Hartman >> <gre...@linuxfoundation.org> wrote: >

Re: [PATCH 4.9 00/75] 4.9.74-stable review

On Tue, Jan 2, 2018 at 1:32 PM, David Miller wrote: > From: Neal Cardwell > Date: Tue, 2 Jan 2018 11:57:59 -0500 > >> On Mon, Jan 1, 2018 at 9:31 AM, Greg Kroah-Hartman >> wrote: >>> This is the start of the stable review cycle for the 4.9.74 release. >>&

Re: [PATCH 4.9 00/75] 4.9.74-stable review

On Mon, Jan 1, 2018 at 9:31 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.74 release. > There are 75 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied,

Re: [PATCH 4.9 00/75] 4.9.74-stable review

On Mon, Jan 1, 2018 at 9:31 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.74 release. > There are 75 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > >

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

On Tue, Aug 15, 2017 at 9:08 AM, mohamedalrshah wrote: > This commit implements a new TCP congestion control algorithm, namely > Agile-SD. Also, please use a summary line for your patch that is more in keeping with Linux style, using spaces rather than dashes, and

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

On Tue, Aug 15, 2017 at 9:08 AM, mohamedalrshah wrote: > This commit implements a new TCP congestion control algorithm, namely > Agile-SD. Also, please use a summary line for your patch that is more in keeping with Linux style, using spaces rather than dashes, and leading with tcp: or

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

On Tue, Aug 15, 2017 at 9:08 AM, mohamedalrshah wrote: > + > +/* Agile-SD Parameters */ > +struct agilesdtcp { > + u32 loss_cwnd; /* congestion window at last loss.*/ Please rebase your change on top of the latest net-next changes and update this

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

On Tue, Aug 15, 2017 at 9:08 AM, mohamedalrshah wrote: > + > +/* Agile-SD Parameters */ > +struct agilesdtcp { > + u32 loss_cwnd; /* congestion window at last loss.*/ Please rebase your change on top of the latest net-next changes and update this module to use the latest

Re: linux-next: manual merge of the net-next tree with the net tree

On Sun, Aug 6, 2017 at 10:01 PM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > net/ipv4/tcp_output.c > > between commit: > > a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO > should

Re: linux-next: manual merge of the net-next tree with the net tree

On Sun, Aug 6, 2017 at 10:01 PM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > net/ipv4/tcp_output.c > > between commit: > > a2815817ffa6 ("tcp: enable xmit timer fix by having TLP use time when RTO > should fire") > > from the net

Re: [PATCH] ipv6: initialize treq->txhash in cookie_v6_check()

On Fri, Jul 14, 2017 at 1:35 PM, Alexander Potapenko <gli...@google.com> wrote: > On Fri, Jul 14, 2017 at 7:04 PM, Neal Cardwell <ncardw...@google.com> wrote: >> On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko <gli...@google.com> >> wrote: >>>

Re: [PATCH] ipv6: initialize treq->txhash in cookie_v6_check()

On Fri, Jul 14, 2017 at 1:35 PM, Alexander Potapenko wrote: > On Fri, Jul 14, 2017 at 7:04 PM, Neal Cardwell wrote: >> On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko >> wrote: >>> KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(), >>&

Re: [PATCH] ipv6: initialize treq->txhash in cookie_v6_check()

On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko wrote: > KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(), > which originated from the TCP request socket created in > cookie_v6_check(): ... > --- a/net/ipv6/syncookies.c > +++ b/net/ipv6/syncookies.c >

Re: [PATCH] ipv6: initialize treq->txhash in cookie_v6_check()

On Fri, Jul 14, 2017 at 12:54 PM, Alexander Potapenko wrote: > KMSAN reported use of uninitialized memory in skb_set_hash_from_sk(), > which originated from the TCP request socket created in > cookie_v6_check(): ... > --- a/net/ipv6/syncookies.c > +++ b/net/ipv6/syncookies.c > @@ -216,6 +216,7 @@

Re: Get amount of fast retransmissions from TCP info

On Wed, May 3, 2017 at 3:47 PM, Lars Erik Storbukås wrote: > I also want to count the amount of ECN signals received. Do anyone > have any input on where to place an ECN signal count? > > Is any of these locations a logical place to increase the ECN counter > (which I've

Re: Get amount of fast retransmissions from TCP info

On Wed, May 3, 2017 at 3:47 PM, Lars Erik Storbukås wrote: > I also want to count the amount of ECN signals received. Do anyone > have any input on where to place an ECN signal count? > > Is any of these locations a logical place to increase the ECN counter > (which I've created in tcp_sock)?

Re: Get amount of fast retransmissions from TCP info

" On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås <storbukas@gmail.com> wrote: > 2017-04-24 21:42 GMT+02:00 Neal Cardwell <ncardw...@google.com>: >> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås >> <storbukas@gmail.com> wrote: >>>

Re: Get amount of fast retransmissions from TCP info

" On Mon, Apr 24, 2017 at 4:20 PM, Lars Erik Storbukås wrote: > 2017-04-24 21:42 GMT+02:00 Neal Cardwell : >> On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås >> wrote: >>> I'm trying to get amount of congestion events in TCP caused by >>> DUPACK's

Re: Get amount of fast retransmissions from TCP info

On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås wrote: > I'm trying to get amount of congestion events in TCP caused by > DUPACK's (fast retransmissions), and can't seem to find any variable > in the TCP info struct which hold that value. There are three > variables

Re: Get amount of fast retransmissions from TCP info

On Mon, Apr 24, 2017 at 3:11 PM, Lars Erik Storbukås wrote: > I'm trying to get amount of congestion events in TCP caused by > DUPACK's (fast retransmissions), and can't seem to find any variable > in the TCP info struct which hold that value. There are three > variables in the TCP info struct

Re: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

On Fri, Oct 23, 2015 at 4:50 PM, Bendik Rønning Opstad wrote: >@@ -2409,6 +2412,15 @@ static int do_tcp_setsockopt(struct sock *sk, int level, ... > + case TCP_RDB: > + if (val < 0 || val > 1) { > + err = -EINVAL; > + } else { > +

Re: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

On Fri, Oct 23, 2015 at 4:50 PM, Bendik Rønning Opstad wrote: >@@ -2409,6 +2412,15 @@ static int do_tcp_setsockopt(struct sock *sk, int level, ... > + case TCP_RDB: > + if (val < 0 || val > 1) { > + err = -EINVAL; > + }

Re: [PATCH] tcp: Restore RFC5961-compliant behavior for SYN packets

. > > The challenge ACK is sent unconditionally and is rate-limited, so the > original vulnerability is not reintroduced by this patch. > > Signed-off-by: Calvin Owens Acked-by: Neal Cardwell neal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] tcp: Restore RFC5961-compliant behavior for SYN packets

-by: Calvin Owens calvinow...@fb.com Acked-by: Neal Cardwell ncardw...@google.com neal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: [PATCH v3] tcp: Add a TCP_FASTOPEN socket option to get a max backlog on its listner

On Wed, Apr 16, 2014 at 12:25 PM, Kenjiro Nakayama wrote: > This patch adds a TCP_FASTOPEN socket option to get a max backlog on its > listener to getsockopt(). > > Signed-off-by: Kenjiro Nakayama > --- > net/ipv4/tcp.c | 8 > 1 file changed, 8 insertions(+) Ac

Re: [PATCH v3] tcp: Add a TCP_FASTOPEN socket option to get a max backlog on its listner

, 8 insertions(+) Acked-by: Neal Cardwell ncardw...@google.com Seems fine to me. Thanks, Kenjiro. neal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ipv4: Add option to get TCP_FASTOPEN to getsockopt()

On Tue, Apr 15, 2014 at 8:35 AM, Kenjiro Nakayama wrote: > Hi, Please omit the "Hi," at the top of the patch description, so the top of the email can be used directly as a git commit description. > TCP_FASTOPEN option can be set via setsockopt(), but the value cannot be > gotten via

Re: [PATCH v2] ipv4: Add option to get TCP_FASTOPEN to getsockopt()

On Tue, Apr 15, 2014 at 8:35 AM, Kenjiro Nakayama nakayamakenj...@gmail.com wrote: Hi, Please omit the Hi, at the top of the patch description, so the top of the email can be used directly as a git commit description. TCP_FASTOPEN option can be set via setsockopt(), but the value cannot be

Re: [PATCH] ipv4: Add option to get TCP_FASTOPEN to getsockopt()

On Mon, Apr 14, 2014 at 1:39 PM, Kenjiro Nakayama wrote: > TCP_FASTOPEN option can be set via setsockopt(), but the value cannot be > gotten via getsockopt(). This patch adds the option to getsockopt(). > > Sighned-off-by: Kenjiro Nakayama > > Add option to get TCP_FASTOPEN to

Re: [PATCH] ipv4: Add option to get TCP_FASTOPEN to getsockopt()

On Mon, Apr 14, 2014 at 1:39 PM, Kenjiro Nakayama nakayamakenj...@gmail.com wrote: TCP_FASTOPEN option can be set via setsockopt(), but the value cannot be gotten via getsockopt(). This patch adds the option to getsockopt(). Sighned-off-by: Kenjiro Nakayama nakayamakenj...@gmail.com

Re: [PATCH v2 3/4] net: make tcp_cleanup_rbuf private

On Thu, Jan 9, 2014 at 3:16 PM, Dan Williams wrote: > net_dma was the only external user so this can become local to tcp.c > again. ... > -void tcp_cleanup_rbuf(struct sock *sk, int copied) > +static void cleanup_rbuf(struct sock *sk, int copied) I would vote to keep the tcp_ prefix. In the TCP

Re: [PATCH v2 3/4] net: make tcp_cleanup_rbuf private

On Thu, Jan 9, 2014 at 3:16 PM, Dan Williams dan.j.willi...@intel.com wrote: net_dma was the only external user so this can become local to tcp.c again. ... -void tcp_cleanup_rbuf(struct sock *sk, int copied) +static void cleanup_rbuf(struct sock *sk, int copied) I would vote to keep the tcp_

Re: PROBLEM: IPv6 TCP-Connections resetting

On Fri, Apr 5, 2013 at 11:48 AM, Tetja Rediske wrote: > I tracked it down with 'git bisect' to commit: > > 093d04d42fa094f6740bb188f0ad0c215ff61e2c ... Thanks for the detailed report! > 11:52:04.634656 IP6 fe80::92e2:baff:fe00:c120 > 2a00:1828:1000:1102::2: > ICMP6, redirect,

Re: PROBLEM: IPv6 TCP-Connections resetting

On Fri, Apr 5, 2013 at 11:48 AM, Tetja Rediske te...@tetja.de wrote: I tracked it down with 'git bisect' to commit: 093d04d42fa094f6740bb188f0ad0c215ff61e2c ... Thanks for the detailed report! 11:52:04.634656 IP6 fe80::92e2:baff:fe00:c120 2a00:1828:1000:1102::2: ICMP6, redirect,

Re: [PATCH net-next] tcp: add ability to set a timestamp offset

On Tue, Jan 22, 2013 at 3:52 PM, Andrey Vagin wrote: > If a TCP socket will get live-migrated from one box to another the > timestamps (which are typically ON) will get screwed up -- the new > kernel will generate TS values that has nothing to do with what they > were on dump. The solution is to

Re: [PATCH net-next] tcp: add ability to set a timestamp offset

On Tue, Jan 22, 2013 at 3:52 PM, Andrey Vagin ava...@openvz.org wrote: If a TCP socket will get live-migrated from one box to another the timestamps (which are typically ON) will get screwed up -- the new kernel will generate TS values that has nothing to do with what they were on dump. The

Re: 3.8-rc2/rc3 write() blocked on CLOSE_WAIT TCP socket

ag > set) added a regression on the handling of RST messages. > > RST should be allowed to come even without ACK bit set. We validate > the RST by checking the exact sequence, as requested by RFC 793 and > 5961 3.2, in tcp_validate_incoming() > > Reported-by: Eric Wong >

Re: 3.8-rc2/rc3 write() blocked on CLOSE_WAIT TCP socket

messages. RST should be allowed to come even without ACK bit set. We validate the RST by checking the exact sequence, as requested by RFC 793 and 5961 3.2, in tcp_validate_incoming() Reported-by: Eric Wong normalper...@yhbt.net Signed-off-by: Eric Dumazet eduma...@google.com Acked-by: Neal

Re: [PATCH] tun: don't zeroize sock->file on detach

On Tue, Aug 21, 2012 at 12:04 PM, Stanislav Kinsbursky wrote: > 10.08.2012 03:16, David Miller пишет: > >> From: Stanislav Kinsbursky >> Date: Thu, 09 Aug 2012 16:50:40 +0400 >> >>> This is a fix for bug, introduced in 3.4 kernel by commit >>> 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which,

Re: BUG: unable to handle kernel paging request at 00010016

On Mon, Aug 20, 2012 at 8:05 PM, Dave Haywood wrote: > Bisected to: > > 5d299f3d3c8a2fbc732b1bf03af36333ccec3130 is the first bad commit > > commit 5d299f3d3c8a2fbc732b1bf03af36333ccec3130 > > Author: Eric Dumazet > > Date: Mon Aug 6 05:09:33 2012 + > > net: ipv6: fix TCP early demux

Re: BUG: unable to handle kernel paging request at 00010016

On Mon, Aug 20, 2012 at 8:05 PM, Dave Haywood t...@oak.selfip.net wrote: Bisected to: 5d299f3d3c8a2fbc732b1bf03af36333ccec3130 is the first bad commit commit 5d299f3d3c8a2fbc732b1bf03af36333ccec3130 Author: Eric Dumazet eduma...@google.com Date: Mon Aug 6 05:09:33 2012 + net:

Re: [PATCH] tun: don't zeroize sock-file on detach

On Tue, Aug 21, 2012 at 12:04 PM, Stanislav Kinsbursky skinsbur...@parallels.com wrote: 10.08.2012 03:16, David Miller пишет: From: Stanislav Kinsbursky skinsbur...@parallels.com Date: Thu, 09 Aug 2012 16:50:40 +0400 This is a fix for bug, introduced in 3.4 kernel by commit