From: Shaohua Li
Generally we do a preload before doing idr allocation. This also help
improve the allocation success rate in memory pressure.
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Shaohua Li
---
kernel/bpf/syscall.c | 4
1 file changed, 4 insertions(+)
diff --git
On Tue, Aug 15, 2017 at 07:08:31AM -0700, Tom Herbert wrote:
> On Mon, Aug 14, 2017 at 7:52 PM, Shaohua Li wrote:
> > On Fri, Aug 11, 2017 at 06:00:20PM -0700, Tom Herbert wrote:
> >> On Thu, Aug 10, 2017 at 12:13 PM, Shaohua Li wrote:
> >> > On Thu, Aug 10, 2017 at
On Tue, Aug 15, 2017 at 05:15:46PM -0700, Tom Herbert wrote:
> On Tue, Aug 15, 2017 at 3:42 PM, Shaohua Li wrote:
> > On Tue, Aug 15, 2017 at 07:08:31AM -0700, Tom Herbert wrote:
> >> On Mon, Aug 14, 2017 at 7:52 PM, Shaohua Li wrote:
> >> > On Fri, Aug 11, 2017 at
From: Shaohua Li
ipv6_pinfo.autoflowlabel is set in sock creation. Later if we change
sysctl.ip6.auto_flowlabels, the ipv6_pinfo.autoflowlabel isn't changed,
so the sock will keep the old behavior in terms of auto flowlabel. Reset
packet is suffering from this problem, because reset packs
From: Shaohua Li
ipv6_pinfo.autoflowlabel is set in sock creation. Later if we change
sysctl.ip6.auto_flowlabels, the ipv6_pinfo.autoflowlabel isn't changed,
so the sock will keep the old behavior in terms of auto flowlabel. Reset
packet is suffering from this problem, because reset packs
From: Shaohua Li
sysctl.ip6.auto_flowlabels is default 1. In our hosts, we set it to 2.
If sockopt doesn't set autoflowlabel, outcome packets from the hosts are
supposed to not include flowlabel. This is true for normal packet, but
not for reset packet.
The reason is ipv6_pinfo.autoflowlab
From: Shaohua Li
We are using sk_txhash to calculate flowlabel, but sk_txhash isn't
always available, for example, in inet_timewait_sock. This causes
problem for reset packet, which will have a different flowlabel. This
causes our router doesn't correctly close tcp connection. We
From: Shaohua Li
Hi,
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
From: Shaohua Li
Reset packet doesn't use user configured flowlabel, instead, it always
uses 0. This will cause inconsistency for flowlabel. tw sock already
records flowlabel info, so we can directly use it.
Cc: Martin KaFai Lau
Cc: Eric Dumazet
Cc: Florent Fourcot
Cc: Cong Wang
Cc
From: Shaohua Li
We are using sk_txhash to calculate flowlabel, but sk_txhash isn't
always available, for example, in inet_timewait_sock. This causes
problem for reset packet, which will have a different flowlabel. This
causes our router doesn't correctly close tcp connection. We
From: Shaohua Li
Hi,
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
From: Shaohua Li
Reset packet doesn't use user configured flowlabel, instead, it always
uses 0. This will cause inconsistency for flowlabel. tw sock already
records flowlabel info, so we can directly use it.
Cc: Martin KaFai Lau
Cc: Eric Dumazet
Cc: Florent Fourcot
Cc: Cong Wang
Cc
From: Shaohua Li
We are using sk_txhash to calculate flowlabel, but sk_txhash isn't
always available, for example, in inet_timewait_sock. This causes
problem for reset packet, which will have a different flowlabel. This
causes our router doesn't correctly close tcp connection. We
From: Shaohua Li
Hi,
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
From: Shaohua Li
Reset packet doesn't use user configured flowlabel, instead, it always
uses 0. This will cause inconsistency for flowlabel. tw sock already
records flowlabel info, so we can directly use it.
Cc: Martin KaFai Lau
Cc: Eric Dumazet
Cc: Florent Fourcot
Cc: Cong Wang
Cc
From: Shaohua Li
Currently if there is negative routing, we change sock's txhash, so the
sock will have a different flowlabel and route to different path.
According to Tom, we'd better to have option to enable this, because some
routers require flowlabel consistent. By default, w
On Wed, Nov 08, 2017 at 09:44:51AM -0800, Tom Herbert wrote:
> On Fri, Aug 18, 2017 at 3:27 PM, David Miller wrote:
> > From: Martin KaFai Lau
> > Date: Fri, 18 Aug 2017 13:51:36 -0700
> >
> >> It seems like that middle box specifically drops TCP_RST if it
> >> does not know anything about this f
On Tue, Nov 14, 2017 at 11:13:10AM -0800, Tom Herbert wrote:
> On Tue, Nov 14, 2017 at 10:24 AM, Shaohua Li wrote:
> > On Wed, Nov 08, 2017 at 09:44:51AM -0800, Tom Herbert wrote:
> >> On Fri, Aug 18, 2017 at 3:27 PM, David Miller wrote:
> >> > From: Martin KaFai
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
From: Shaohua Li
Currently tcp_v6_send_reset ignores user defined flowlabel, so the reset
packet doesn't include the flowlabel info.
Signed-off-by: Shaohua Li
---
net/ipv6/tcp_ipv6.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/tcp_ipv
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
On Mon, Jul 17, 2017 at 01:51:51AM -0700, Eric Dumazet wrote:
> On Thu, 2017-07-13 at 10:56 -0700, Shaohua Li wrote:
> > From: Shaohua Li
> >
> > Please see below tcpdump output:
>
> > The tcp reset packet has a different flowlabel, which causes our router
&
On Mon, Jul 17, 2017 at 09:02:57PM -0700, Eric Dumazet wrote:
> On Mon, 2017-07-17 at 14:53 -0700, Shaohua Li wrote:
> > On Mon, Jul 17, 2017 at 01:51:51AM -0700, Eric Dumazet wrote:
> > > On Thu, 2017-07-13 at 10:56 -0700, Shaohua Li wrote:
> > > > From: Shaohua L
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
On Mon, Jul 24, 2017 at 04:12:53PM -0700, Cong Wang wrote:
> On Mon, Jul 24, 2017 at 1:34 PM, David Miller wrote:
> > From: Shaohua Li
> > Date: Tue, 18 Jul 2017 12:03:37 -0700
> >
> >> + /* Since this is being sent on the wire obfuscate hash a bit
> >&g
On Mon, Jul 24, 2017 at 01:34:55PM -0700, David Miller wrote:
> From: Shaohua Li
> Date: Tue, 18 Jul 2017 12:03:37 -0700
>
> > + /* Since this is being sent on the wire obfuscate hash a bit
> > +* to minimize possbility that any useful information to an
> > +
From: Shaohua Li
According to David Miller, the rotation doesn't really help avoid
security problem, so delte it.
Suggested-by: David Miller
Signed-off-by: Shaohua Li
---
include/net/ipv6.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
From: Shaohua Li
In a syn flooding test, the fib6_table rwlock is a significant
bottleneck. While converting the rwlock to rcu sounds straighforward,
but is very challenging if it's possible. A percpu spinlock is quite
trival for this problem since updating the routing table is a rare
even
On Mon, Jul 31, 2017 at 11:10:38AM -0700, Cong Wang wrote:
> On Mon, Jul 31, 2017 at 10:08 AM, Shaohua Li wrote:
> > +/* Like ip6_make_flowlabel, but already has hash */
> > +static inline __be32 ip6_make_flowlabel_from_hash(
On Mon, Jul 31, 2017 at 11:30:53AM -0700, Eric Dumazet wrote:
> On Mon, 2017-07-31 at 10:18 -0700, Shaohua Li wrote:
> > From: Shaohua Li
> >
> > In a syn flooding test, the fib6_table rwlock is a significant
> > bottleneck. While converting the rwlock to rcu sounds
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
From: Shaohua Li
According to David Miller, the rotation doesn't really help avoid
security problem, so delte it.
Suggested-by: David Miller
Signed-off-by: Shaohua Li
---
include/net/ipv6.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
On Mon, Jul 31, 2017 at 03:35:02PM -0700, Cong Wang wrote:
> On Mon, Jul 31, 2017 at 3:19 PM, Shaohua Li wrote:
> > static inline __be32 ip6_make_flowlabel(struct net *net, struct sk_buff
> > *skb,
> > __be32 flow
On Mon, Jul 31, 2017 at 04:10:07PM -0700, Stephen Hemminger wrote:
> On Mon, 31 Jul 2017 10:18:57 -0700
> Shaohua Li wrote:
>
> > From: Shaohua Li
> >
> > In a syn flooding test, the fib6_table rwlock is a significant
> > bottleneck. While converting the rw
On Tue, Aug 01, 2017 at 02:17:58PM -0700, Cong Wang wrote:
> On Mon, Jul 31, 2017 at 4:00 PM, Shaohua Li wrote:
> > On Mon, Jul 31, 2017 at 03:35:02PM -0700, Cong Wang wrote:
> >> On Mon, Jul 31, 2017 at 3:19 PM, Shaohua Li wrote:
> >> > static inline __be32 ip6_
From: Shaohua Li
In a syn flooding test, the fib6_table rwlock is a significant
bottleneck. While converting the rwlock to rcu sounds straighforward,
but is very challenging if it's possible. A percpu spinlock (lglock has
been removed from kernel, so I added a simple implementation her
On Mon, Jul 31, 2017 at 03:19:21PM -0700, Shaohua Li wrote:
> From: Shaohua Li
>
> Please see below tcpdump output:
> 21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
> length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.:
On Wed, Aug 09, 2017 at 09:40:08AM -0700, Tom Herbert wrote:
> On Mon, Jul 31, 2017 at 3:19 PM, Shaohua Li wrote:
> > From: Shaohua Li
> >
> > Please see below tcpdump output:
> > 21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6)
> > paylo
On Thu, Aug 10, 2017 at 11:30:51AM -0700, Tom Herbert wrote:
> On Thu, Aug 10, 2017 at 9:30 AM, Shaohua Li wrote:
> > On Wed, Aug 09, 2017 at 09:40:08AM -0700, Tom Herbert wrote:
> >> On Mon, Jul 31, 2017 at 3:19 PM, Shaohua Li wrote:
> >> > From: Shaohua Li
On Fri, Aug 11, 2017 at 06:00:20PM -0700, Tom Herbert wrote:
> On Thu, Aug 10, 2017 at 12:13 PM, Shaohua Li wrote:
> > On Thu, Aug 10, 2017 at 11:30:51AM -0700, Tom Herbert wrote:
> >> On Thu, Aug 10, 2017 at 9:30 AM, Shaohua Li wrote:
> >> > On Wed, Aug 09, 2017 at
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
From: Shaohua Li
Please see below tcpdump output:
21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload
length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.: Flags
[S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options
[mss
From: Shaohua Li
According to David Miller, the rotation doesn't really help avoid
security problem, so delte it.
Suggested-by: David Miller
Signed-off-by: Shaohua Li
---
include/net/ipv6.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
L
On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
put_cpu_var takes the percpu data, not the data returned from
get_cpu_var.
This doesn't change the behavior.
Cc: Tejun Heo
Cc: Alexei Starovoitov
Signed-off-by: Shaohua Li
---
kernel/bpf/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/core.c b/kerne
put_cpu_var takes the percpu data, not the data returned from
get_cpu_var.
This doesn't change the behavior.
Cc: Tejun Heo
Signed-off-by: Shaohua Li
---
lib/random32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/random32.c b/lib/random32.c
index a3
ill fallback
to order-0 immediately.
The mellanox driver does similar thing, if this is accepted, we must fix
the driver too.
Cc: Eric Dumazet
Signed-off-by: Shaohua Li
---
net/core/sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 2
On Thu, Jun 11, 2015 at 02:22:13PM -0700, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 17:16 -0400, Chris Mason wrote:
> > On 06/11/2015 04:48 PM, Eric Dumazet wrote:
> > > On Thu, 2015-06-11 at 13:24 -0700, Shaohua Li wrote:
> > >> We saw excessive
On Thu, Jun 11, 2015 at 02:56:26PM -0700, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 14:45 -0700, Shaohua Li wrote:
>
> > This is exactly what the patch try to do. Atomic 32k allocation will
> > fail with memory pressure, kswapd is waken up to do compaction and we
> > f
On Thu, Jun 11, 2015 at 03:53:04PM -0700, Eric Dumazet wrote:
> On Thu, 2015-06-11 at 15:27 -0700, Shaohua Li wrote:
> > We saw excessive direct memory compaction triggered by skb_page_frag_refill.
> > This causes performance issues and add latency. Commit 5640f7685831e0
> > i
zet
Cc: Chris Mason
Cc: Debabrata Banerjee
Signed-off-by: Shaohua Li
---
net/core/skbuff.c | 2 +-
net/core/sock.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3cfff2a..41ec022 100644
--- a/net/core/skbuff.c
+++ b/net/core
-mm&m=143406665720428&w=2
Cc: Amir Vadai
Cc: Ido Shamay
Cc: Eric Dumazet
Signed-off-by: Shaohua Li
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/
On Fri, Jun 12, 2015 at 10:05:42AM -0700, Alexander Duyck wrote:
> On 06/12/2015 09:50 AM, Shaohua Li wrote:
> >High order page allocation can cause direct memory compaction and harm
> >performance. The patch makes the high order page allocation don't wait,
> >so
56 matches
Mail list logo
