* Re: [PATCH net-next v2] tcp: up initial rmem to 128KB and SYN rwin to around 64KB
From: Eric Dumazet @ 2018-10-01 22:20 UTC (permalink / raw)
To: Yuchung Cheng
Cc: David Miller, netdev, Neal Cardwell, Wei Wang,
Soheil Hassas Yeganeh
In-Reply-To: <CAK6E8=dCC+5bP9gUrM6E42d9iYr2HNznQ74vhM=3xoD9ms90rA@mail.gmail.com>
On Mon, Oct 1, 2018 at 3:18 PM Yuchung Cheng <ycheng@google.com> wrote:
> Hi David: thanks for taking this patch - I didn't notice this earlier
> but it seems patch v1 was applied instead of v2? should I submit a
> v2-v1-diff patch?
Yes, please, send an additional patch.
^ permalink raw reply
* [PATCH 1/6] netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: David Ahern <dsahern@gmail.com>
For starters, the bridge netfilter code registers operations that
are invoked any time nh_hook is called. Specifically, ip_sabotage_in
watches for nested calls for NF_INET_PRE_ROUTING when a bridge is in
the stack.
Packet wise, the bridge netfilter hook runs first. br_nf_pre_routing
allocates nf_bridge, sets in_prerouting to 1 and calls NF_HOOK for
NF_INET_PRE_ROUTING. It's finish function, br_nf_pre_routing_finish,
then resets in_prerouting flag to 0 and the packet continues up the
stack. The packet eventually makes it to the VRF driver and it invokes
nf_hook for NF_INET_PRE_ROUTING in case any rules have been added against
the vrf device.
Because of the registered operations the call to nf_hook causes
ip_sabotage_in to be invoked. That function sees the nf_bridge on the
skb and that in_prerouting is not set. Thinking it is an invalid nested
call it steals (drops) the packet.
Update ip_sabotage_in to recognize that the bridge or one of its upper
devices (e.g., vlan) can be enslaved to a VRF (L3 master device) and
allow the packet to go through the nf_hook a second time.
Fixes: 73e20b761acf ("net: vrf: Add support for PREROUTING rules on vrf device")
Reported-by: D'Souza, Nelson <ndsouza@ciena.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/bridge/br_netfilter_hooks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index 6e0dc6bcd32a..37278dc280eb 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -835,7 +835,8 @@ static unsigned int ip_sabotage_in(void *priv,
struct sk_buff *skb,
const struct nf_hook_state *state)
{
- if (skb->nf_bridge && !skb->nf_bridge->in_prerouting) {
+ if (skb->nf_bridge && !skb->nf_bridge->in_prerouting &&
+ !netif_is_l3_master(skb->dev)) {
state->okfn(state->net, state->sk, skb);
return NF_STOLEN;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 0/6] Netfilter fixes for net
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter fixes for your net tree:
1) Skip ip_sabotage_in() for packet making into the VRF driver,
otherwise packets are dropped, from David Ahern.
2) Clang compilation warning uncovering typo in the
nft_validate_register_store() call from nft_osf, from Stefan Agner.
3) Double sizeof netlink message length calculations in ctnetlink,
from zhong jiang.
4) Missing rb_erase() on batch full in rbtree garbage collector,
from Taehee Yoo.
5) Calm down compilation warning in nf_hook(), from Florian Westphal.
6) Missing check for non-null sk in xt_socket before validating
netns procedence, from Flavio Leitner.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Thanks.
----------------------------------------------------------------
The following changes since commit 56ce3c5a50f4d8cc95361b1ec7f152006c6320d8:
smc: generic netlink family should be __ro_after_init (2018-09-20 07:49:55 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to 40e4f26e6a14fc1496eabb8b0004a547303114e6:
netfilter: xt_socket: check sk before checking for netns. (2018-09-28 14:47:41 +0200)
----------------------------------------------------------------
David Ahern (1):
netfilter: bridge: Don't sabotage nf_hook calls from an l3mdev
Flavio Leitner (1):
netfilter: xt_socket: check sk before checking for netns.
Florian Westphal (1):
netfilter: avoid erronous array bounds warning
Stefan Agner (1):
netfilter: nft_osf: use enum nft_data_types for nft_validate_register_store
Taehee Yoo (1):
netfilter: nft_set_rbtree: add missing rb_erase() in GC routine
zhong jiang (1):
netfilter: conntrack: get rid of double sizeof
include/linux/netfilter.h | 2 ++
net/bridge/br_netfilter_hooks.c | 3 ++-
net/netfilter/nf_conntrack_proto_tcp.c | 4 ++--
net/netfilter/nft_osf.c | 2 +-
net/netfilter/nft_set_rbtree.c | 28 ++++++++++++++--------------
net/netfilter/xt_socket.c | 4 ++--
6 files changed, 23 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH 4/6] netfilter: nft_set_rbtree: add missing rb_erase() in GC routine
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: Taehee Yoo <ap420073@gmail.com>
The nft_set_gc_batch_check() checks whether gc buffer is full.
If gc buffer is full, gc buffer is released by
the nft_set_gc_batch_complete() internally.
In case of rbtree, the rb_erase() should be called before calling the
nft_set_gc_batch_complete(). therefore the rb_erase() should
be called before calling the nft_set_gc_batch_check() too.
test commands:
table ip filter {
set set1 {
type ipv4_addr; flags interval, timeout;
gc-interval 10s;
timeout 1s;
elements = {
1-2,
3-4,
5-6,
...
10000-10001,
}
}
}
%nft -f test.nft
splat looks like:
[ 430.273885] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ 430.282158] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 430.283116] CPU: 1 PID: 190 Comm: kworker/1:2 Tainted: G B 4.18.0+ #7
[ 430.283116] Workqueue: events_power_efficient nft_rbtree_gc [nf_tables_set]
[ 430.313559] RIP: 0010:rb_next+0x81/0x130
[ 430.313559] Code: 08 49 bd 00 00 00 00 00 fc ff df 48 bb 00 00 00 00 00 fc ff df 48 85 c0 75 05 eb 58 48 89 d4
[ 430.313559] RSP: 0018:ffff88010cdb7680 EFLAGS: 00010207
[ 430.313559] RAX: 0000000000b84854 RBX: dffffc0000000000 RCX: ffffffff83f01973
[ 430.313559] RDX: 000000000017090c RSI: 0000000000000008 RDI: 0000000000b84864
[ 430.313559] RBP: ffff8801060d4588 R08: fffffbfff09bc349 R09: fffffbfff09bc349
[ 430.313559] R10: 0000000000000001 R11: fffffbfff09bc348 R12: ffff880100f081a8
[ 430.313559] R13: dffffc0000000000 R14: ffff880100ff8688 R15: dffffc0000000000
[ 430.313559] FS: 0000000000000000(0000) GS:ffff88011b400000(0000) knlGS:0000000000000000
[ 430.313559] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 430.313559] CR2: 0000000001551008 CR3: 000000005dc16000 CR4: 00000000001006e0
[ 430.313559] Call Trace:
[ 430.313559] nft_rbtree_gc+0x112/0x5c0 [nf_tables_set]
[ 430.313559] process_one_work+0xc13/0x1ec0
[ 430.313559] ? _raw_spin_unlock_irq+0x29/0x40
[ 430.313559] ? pwq_dec_nr_in_flight+0x3c0/0x3c0
[ 430.313559] ? set_load_weight+0x270/0x270
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __switch_to_asm+0x40/0x70
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __switch_to_asm+0x40/0x70
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __switch_to_asm+0x40/0x70
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __switch_to_asm+0x40/0x70
[ 430.313559] ? __switch_to_asm+0x34/0x70
[ 430.313559] ? __schedule+0x6d3/0x1f50
[ 430.313559] ? find_held_lock+0x39/0x1c0
[ 430.313559] ? __sched_text_start+0x8/0x8
[ 430.313559] ? cyc2ns_read_end+0x10/0x10
[ 430.313559] ? save_trace+0x300/0x300
[ 430.313559] ? sched_clock_local+0xd4/0x140
[ 430.313559] ? find_held_lock+0x39/0x1c0
[ 430.313559] ? worker_thread+0x353/0x1120
[ 430.313559] ? worker_thread+0x353/0x1120
[ 430.313559] ? lock_contended+0xe70/0xe70
[ 430.313559] ? __lock_acquire+0x4500/0x4500
[ 430.535635] ? do_raw_spin_unlock+0xa5/0x330
[ 430.535635] ? do_raw_spin_trylock+0x101/0x1a0
[ 430.535635] ? do_raw_spin_lock+0x1f0/0x1f0
[ 430.535635] ? _raw_spin_lock_irq+0x10/0x70
[ 430.535635] worker_thread+0x15d/0x1120
[ ... ]
Fixes: 8d8540c4f5e0 ("netfilter: nft_set_rbtree: add timeout support")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_set_rbtree.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 55e2d9215c0d..0e5ec126f6ad 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -355,12 +355,11 @@ static void nft_rbtree_walk(const struct nft_ctx *ctx,
static void nft_rbtree_gc(struct work_struct *work)
{
+ struct nft_rbtree_elem *rbe, *rbe_end = NULL, *rbe_prev = NULL;
struct nft_set_gc_batch *gcb = NULL;
- struct rb_node *node, *prev = NULL;
- struct nft_rbtree_elem *rbe;
struct nft_rbtree *priv;
+ struct rb_node *node;
struct nft_set *set;
- int i;
priv = container_of(work, struct nft_rbtree, gc_work.work);
set = nft_set_container_of(priv);
@@ -371,7 +370,7 @@ static void nft_rbtree_gc(struct work_struct *work)
rbe = rb_entry(node, struct nft_rbtree_elem, node);
if (nft_rbtree_interval_end(rbe)) {
- prev = node;
+ rbe_end = rbe;
continue;
}
if (!nft_set_elem_expired(&rbe->ext))
@@ -379,29 +378,30 @@ static void nft_rbtree_gc(struct work_struct *work)
if (nft_set_elem_mark_busy(&rbe->ext))
continue;
+ if (rbe_prev) {
+ rb_erase(&rbe_prev->node, &priv->root);
+ rbe_prev = NULL;
+ }
gcb = nft_set_gc_batch_check(set, gcb, GFP_ATOMIC);
if (!gcb)
break;
atomic_dec(&set->nelems);
nft_set_gc_batch_add(gcb, rbe);
+ rbe_prev = rbe;
- if (prev) {
- rbe = rb_entry(prev, struct nft_rbtree_elem, node);
+ if (rbe_end) {
atomic_dec(&set->nelems);
- nft_set_gc_batch_add(gcb, rbe);
- prev = NULL;
+ nft_set_gc_batch_add(gcb, rbe_end);
+ rb_erase(&rbe_end->node, &priv->root);
+ rbe_end = NULL;
}
node = rb_next(node);
if (!node)
break;
}
- if (gcb) {
- for (i = 0; i < gcb->head.cnt; i++) {
- rbe = gcb->elems[i];
- rb_erase(&rbe->node, &priv->root);
- }
- }
+ if (rbe_prev)
+ rb_erase(&rbe_prev->node, &priv->root);
write_seqcount_end(&priv->count);
write_unlock_bh(&priv->lock);
--
2.11.0
^ permalink raw reply related
* [PATCH 5/6] netfilter: avoid erronous array bounds warning
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
Unfortunately some versions of gcc emit following warning:
$ make net/xfrm/xfrm_output.o
linux/compiler.h:252:20: warning: array subscript is above array bounds [-Warray-bounds]
hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
^~~~~~~~~~~~~~~~~~~~~
xfrm_output_resume passes skb_dst(skb)->ops->family as its 'pf' arg so compiler
can't know that we'll never access hooks_arp[].
(NFPROTO_IPV4 or NFPROTO_IPV6 are only possible cases).
Avoid this by adding an explicit WARN_ON_ONCE() check.
This patch has no effect if the family is a compile-time constant as gcc
will remove the switch() construct entirely.
Reported-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
include/linux/netfilter.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index 07efffd0c759..bbe99d2b28b4 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -215,6 +215,8 @@ static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
break;
case NFPROTO_ARP:
#ifdef CONFIG_NETFILTER_FAMILY_ARP
+ if (WARN_ON_ONCE(hook >= ARRAY_SIZE(net->nf.hooks_arp)))
+ break;
hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
#endif
break;
--
2.11.0
^ permalink raw reply related
* [PATCH 2/6] netfilter: nft_osf: use enum nft_data_types for nft_validate_register_store
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: Stefan Agner <stefan@agner.ch>
The function nft_validate_register_store requires a struct of type
struct nft_data_types. NFTA_DATA_VALUE is of type enum
nft_verdict_attributes. Pass the correct enum type.
This fixes a warning seen with Clang:
net/netfilter/nft_osf.c:52:8: warning: implicit conversion from
enumeration type 'enum nft_data_attributes' to different enumeration
type 'enum nft_data_types' [-Wenum-conversion]
NFTA_DATA_VALUE, NFT_OSF_MAXGENRELEN);
^~~~~~~~~~~~~~~
Fixes: b96af92d6eaf ("netfilter: nf_tables: implement Passive OS fingerprint module in nft_osf")
Link: https://github.com/ClangBuiltLinux/linux/issues/103
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nft_osf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nft_osf.c b/net/netfilter/nft_osf.c
index 5af74b37f423..a35fb59ace73 100644
--- a/net/netfilter/nft_osf.c
+++ b/net/netfilter/nft_osf.c
@@ -49,7 +49,7 @@ static int nft_osf_init(const struct nft_ctx *ctx,
priv->dreg = nft_parse_register(tb[NFTA_OSF_DREG]);
err = nft_validate_register_store(ctx, priv->dreg, NULL,
- NFTA_DATA_VALUE, NFT_OSF_MAXGENRELEN);
+ NFT_DATA_VALUE, NFT_OSF_MAXGENRELEN);
if (err < 0)
return err;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/6] netfilter: conntrack: get rid of double sizeof
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: zhong jiang <zhongjiang@huawei.com>
sizeof(sizeof()) is quite strange and does not seem to be what
is wanted here.
The issue is detected with the help of Coccinelle.
Fixes: 39215846740a ("netfilter: conntrack: remove nlattr_size pointer from l4proto trackers")
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nf_conntrack_proto_tcp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index b4bdf9eda7b7..247b89784a6f 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -1213,8 +1213,8 @@ static const struct nla_policy tcp_nla_policy[CTA_PROTOINFO_TCP_MAX+1] = {
#define TCP_NLATTR_SIZE ( \
NLA_ALIGN(NLA_HDRLEN + 1) + \
NLA_ALIGN(NLA_HDRLEN + 1) + \
- NLA_ALIGN(NLA_HDRLEN + sizeof(sizeof(struct nf_ct_tcp_flags))) + \
- NLA_ALIGN(NLA_HDRLEN + sizeof(sizeof(struct nf_ct_tcp_flags))))
+ NLA_ALIGN(NLA_HDRLEN + sizeof(struct nf_ct_tcp_flags)) + \
+ NLA_ALIGN(NLA_HDRLEN + sizeof(struct nf_ct_tcp_flags)))
static int nlattr_to_tcp(struct nlattr *cda[], struct nf_conn *ct)
{
--
2.11.0
^ permalink raw reply related
* [PATCH 6/6] netfilter: xt_socket: check sk before checking for netns.
From: Pablo Neira Ayuso @ 2018-10-01 22:37 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: Flavio Leitner <fbl@redhat.com>
Only check for the network namespace if the socket is available.
Fixes: f564650106a6 ("netfilter: check if the socket netns is correct.")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/xt_socket.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 0472f3472842..ada144e5645b 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -56,7 +56,7 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
- if (!net_eq(xt_net(par), sock_net(sk)))
+ if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
if (!sk)
@@ -117,7 +117,7 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct xt_action_param *par)
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
- if (!net_eq(xt_net(par), sock_net(sk)))
+ if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
if (!sk)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 0/6] Netfilter fixes for net
From: David Miller @ 2018-10-01 22:41 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20181001223745.29010-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 2 Oct 2018 00:37:39 +0200
> The following patchset contains Netfilter fixes for your net tree:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks.
^ permalink raw reply
* [PATCH net-next] tcp: start receiver buffer autotuning sooner
From: Yuchung Cheng @ 2018-10-01 22:42 UTC (permalink / raw)
To: davem, edumazet; +Cc: netdev, ncardwell, weiwan, soheil, Yuchung Cheng
Previously receiver buffer auto-tuning starts after receiving
one advertised window amount of data. After the initial receiver
buffer was raised by patch a337531b942b ("tcp: up initial rmem to
128KB and SYN rwin to around 64KB"), the reciver buffer may take
too long to start raising. To address this issue, this patch lowers
the initial bytes expected to receive roughly the expected sender's
initial window.
Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
---
net/ipv4/tcp_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7a59f6a96212..bf1aac315490 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -438,7 +438,7 @@ void tcp_init_buffer_space(struct sock *sk)
if (!(sk->sk_userlocks & SOCK_SNDBUF_LOCK))
tcp_sndbuf_expand(sk);
- tp->rcvq_space.space = tp->rcv_wnd;
+ tp->rcvq_space.space = min_t(u32, tp->rcv_wnd, TCP_INIT_CWND * tp->advmss);
tcp_mstamp_refresh(tp);
tp->rcvq_space.time = tp->tcp_mstamp;
tp->rcvq_space.seq = tp->copied_seq;
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* Re: [PATCH net] tcp/dccp: fix lockdep issue when SYN is backlogged
From: David Miller @ 2018-10-01 22:43 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet
In-Reply-To: <20181001220226.252453-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Mon, 1 Oct 2018 15:02:26 -0700
> In normal SYN processing, packets are handled without listener
> lock and in RCU protected ingress path.
>
> But syzkaller is known to be able to trick us and SYN
> packets might be processed in process context, after being
> queued into socket backlog.
>
> In commit 06f877d613be ("tcp/dccp: fix other lockdep splats
> accessing ireq_opt") I made a very stupid fix, that happened
> to work mostly because of the regular path being RCU protected.
>
> Really the thing protecting ireq->ireq_opt is RCU read lock,
> and the pseudo request refcnt is not relevant.
>
> This patch extends what I did in commit 449809a66c1d ("tcp/dccp:
> block BH for SYN processing") by adding an extra rcu_read_{lock|unlock}
> pair in the paths that might be taken when processing SYN from
> socket backlog (thus possibly in process context)
>
> Fixes: 06f877d613be ("tcp/dccp: fix other lockdep splats accessing ireq_opt")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [net-next 0/8][pull request] 100GbE Intel Wired LAN Driver Updates 2018-10-01
From: David Miller @ 2018-10-01 22:44 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20181001211431.14325-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 1 Oct 2018 14:14:23 -0700
> This series contains updates to ice driver only.
>
> Anirudh provides several changes to "prep" the driver for upcoming
> features. Specifically, the functions that are used for PF VSI/netdev
> setup will also be used in SR-IOV support and to allow the reuse of
> these functions, code needs to move.
>
> Dave provides the only other change in the series, updates the driver to
> protect the reset patch in its entirety. This is done by adding the
> various bit checks to determine if a reset is scheduled/initiated and
> whether it came from the software or firmware.
>
> The following are changes since commit 804fe108fc92e591ddfe9447e7fb4691ed16daee:
> openvswitch: Use correct reply values in datapath and vport ops
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [Potential Spoof] Re: [PATCH v2] net/ncsi: Add NCSI OEM command support
From: Vijay Khemka @ 2018-10-01 22:45 UTC (permalink / raw)
To: Justin . Lee1 @ Dell . com, joel @ jms . id . au,
linux-aspeed @ lists . ozlabs . org,
openbmc @ lists . ozlabs . org, Sai Dasari,
netdev @ vger . kernel . org, christian @ cmd . nu,
Samuel Mendoza-Jonas
On 9/28/18, 6:21 PM, "Linux-aspeed on behalf of Vijay Khemka" <linux-aspeed-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of vijaykhemka@fb.com> wrote:
> On 9/28/18, 6:07 PM, "Vijay Khemka" <vijaykhemka@fb.com> wrote:
> This patch adds OEM commands and response handling. It also defines OEM
> command and response structure as per NCSI specification along with its
> handlers.
>
> ncsi_cmd_handler_oem: This is a generic command request handler for OEM
> commands
> ncsi_rsp_handler_oem: This is a generic response handler for OEM commands
This is a generic patch for OEM command handling, There will be another patch
following this to handle specific OEM commands for each vendor. Currently I have
defined 2 vendor/manufacturer id below in internal.h, more can be added here for
other vendors. I have not defined ncsi_rsp_oem_handler in this patch as they are
NULL, but there will be a defined handlers for each vendor in next patch.
Sam, Joel, Justin, please review this patch. I have 2 more patch coming for Broadcom and Mellanox.
^ permalink raw reply
* Re: [PATCH net-next] tcp: start receiver buffer autotuning sooner
From: David Miller @ 2018-10-01 22:46 UTC (permalink / raw)
To: ycheng; +Cc: edumazet, netdev, ncardwell, weiwan, soheil
In-Reply-To: <20181001224232.39939-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Mon, 1 Oct 2018 15:42:32 -0700
> Previously receiver buffer auto-tuning starts after receiving
> one advertised window amount of data. After the initial receiver
> buffer was raised by patch a337531b942b ("tcp: up initial rmem to
> 128KB and SYN rwin to around 64KB"), the reciver buffer may take
> too long to start raising. To address this issue, this patch lowers
> the initial bytes expected to receive roughly the expected sender's
> initial window.
>
> Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Wei Wang <weiwan@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Applied, sorry for applying v1 instead of v2 the the rmem increasing patch.
:-/
^ permalink raw reply
* Re: [PATCH] Revert "openvswitch: Fix template leak in error cases."
From: Joe Stringer @ 2018-10-01 22:46 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netfilter-devel, netdev, ovs dev, pravin shelar
In-Reply-To: <20180928175534.13590-1-fbl@redhat.com>
On Fri, 28 Sep 2018 at 10:55, Flavio Leitner <fbl@redhat.com> wrote:
>
> This reverts commit 90c7afc96cbbd77f44094b5b651261968e97de67.
>
> When the commit was merged, the code used nf_ct_put() to free
> the entry, but later on commit 76644232e612 ("openvswitch: Free
> tmpl with tmpl_free.") replaced that with nf_ct_tmpl_free which
> is a more appropriate. Now the original problem is removed.
>
> Then 44d6e2f27328 ("net: Replace NF_CT_ASSERT() with WARN_ON().")
> replaced a debug assert with a WARN_ON() which is trigged now.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
> ---
Thanks for the cleanup.
Acked-by: Joe Stringer <joe@ovn.org>
^ permalink raw reply
* Re: [pull request][net-next 00/13] Mellanox, mlx5e updates 2018-10-01
From: David Miller @ 2018-10-01 22:49 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20181001185701.2944-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 1 Oct 2018 11:56:48 -0700
> The following pull request includes updates to mlx5e ethernet netdevice
> driver, for more information please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH net-next] tcp: start receiver buffer autotuning sooner
From: Yuchung Cheng @ 2018-10-01 23:07 UTC (permalink / raw)
To: David Miller
Cc: Eric Dumazet, netdev, Neal Cardwell, Wei Wang,
Soheil Hassas Yeganeh
In-Reply-To: <20181001.154600.398152617755232823.davem@davemloft.net>
On Mon, Oct 1, 2018 at 3:46 PM, David Miller <davem@davemloft.net> wrote:
> From: Yuchung Cheng <ycheng@google.com>
> Date: Mon, 1 Oct 2018 15:42:32 -0700
>
>> Previously receiver buffer auto-tuning starts after receiving
>> one advertised window amount of data. After the initial receiver
>> buffer was raised by patch a337531b942b ("tcp: up initial rmem to
>> 128KB and SYN rwin to around 64KB"), the reciver buffer may take
>> too long to start raising. To address this issue, this patch lowers
>> the initial bytes expected to receive roughly the expected sender's
>> initial window.
>>
>> Fixes: a337531b942b ("tcp: up initial rmem to 128KB and SYN rwin to around 64KB")
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>> Signed-off-by: Wei Wang <weiwan@google.com>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
>
> Applied, sorry for applying v1 instead of v2 the the rmem increasing patch.
> :-/
No problem thanks for the fast response!
^ permalink raw reply
* Re: [PATCH net-next] net: nixge: Address compiler warnings when building for i386
From: David Miller @ 2018-10-02 5:49 UTC (permalink / raw)
To: mdf
Cc: linux-kernel, netdev, keescook, moritz.fischer, f.fainelli,
alex.williams, arnd
In-Reply-To: <20180927194851.3042-1-mdf@kernel.org>
From: Moritz Fischer <mdf@kernel.org>
Date: Thu, 27 Sep 2018 12:48:51 -0700
> Address compiler warning reported by kbuild autobuilders
> when building for i386 as a result of dma_addr_t size on
> different architectures.
>
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
>
> Fixes: 7e8d5755be0e ("net: nixge: Add support for 64-bit platforms")
> Signed-off-by: Moritz Fischer <mdf@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH net] r8169: Enable MSI-X on RTL8106e
From: David Miller @ 2018-10-02 5:51 UTC (permalink / raw)
To: jian-hong
Cc: hkallweit1, nic_swsd, netdev, linux-kernel, kai.heng.feng, linux
In-Reply-To: <20180927040948.11891-1-jian-hong@endlessm.com>
From: Jian-Hong Pan <jian-hong@endlessm.com>
Date: Thu, 27 Sep 2018 12:09:48 +0800
> However, there is a commit which resolves the drivers getting nothing in
> PCI BAR=4 after system resumes. It is 04cb3ae895d7 "PCI: Reprogram
> bridge prefetch registers on resume" by Daniel Drake.
I don't see this upstream yet.
^ permalink raw reply
* Re: [PATCH net-next 0/7] Support of Flow Director in HNS3 Ethernet Driver for HiP08 Rev2 SoC
From: David Miller @ 2018-10-02 5:58 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20181001114647.15504-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Mon, 1 Oct 2018 12:46:40 +0100
> This patch-set adds the support of FD(Flow Director) in the HNS3 PF driver
> for HiP08 Rev2(0x21) SoC of Hisilicon. FD can be used in filtering the flows
> and deciding to drop the flow or forward it to paricular queue.
>
> Configuration consists of rules with input keys and actions. The rules are
> stored in TCAM.
Series applied.
^ permalink raw reply
* Re: [PATCH v2 net-next 7/8] net: ethernet: xgbe: expand PHY_GBIT_FEAUTRES
From: Andrew Lunn @ 2018-10-01 23:23 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: David Miller, netdev, Florian Fainelli, Maxime Chevallier
In-Reply-To: <a387133e-7887-e7a3-4f70-b97a45ccbe07@cogentembedded.com>
On Sun, Sep 30, 2018 at 11:41:00AM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 9/30/2018 12:04 AM, Andrew Lunn wrote:
>
> >The macro PHY_GBIT_FEAUTRES needs to change into a bitmap in order to
> >support link_modes. Remove its use from xgde by replacing it with its
> >definition.
> >
> >Probably, the current behavior is wrong. It probably should be
> >ANDing not assigning.
>
> ORing, maybe?
Hi Sergei
It is hard to know what was intended here.
By assigning these speeds, if the PHY does not actually support 1Gbps,
that information is going to be overwritten. So it should really be
ANDing with that the MAC supports. ORing would have the same problem.
This assignment is also clearing out an TP, AUI, BNC bits which might
be set.
Since i don't really know what the intention is here, i'm just going
to leave it alone.
>
> >Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >---
> >v2
> >Remove unneeded ()
>
> Really? :-)
I did not say all unneeded :-)
I will remove some more.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Ard Biesheuvel @ 2018-10-02 6:04 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Herbert Xu, Eric Biggers, LKML, Netdev, Linux Crypto Mailing List,
David Miller, Greg Kroah-Hartman
In-Reply-To: <CAHmME9piX1kbUhOBcUKVdecr45EjxuruxYuMTepfXVvRrkVmyg@mail.gmail.com>
On 2 October 2018 at 05:45, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Herbert,
>
> On Tue, Oct 2, 2018 at 5:39 AM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>> > I would also strongly prefer that all crypto work is taken through
>> > Herbert's tree, so we have a coherent view of it before it goes
>> > upstream.
>>
>> I agree. I don't have any problems with the zinc code living in
>> its own git tree. But any upstream merges should definitely go
>> through the crypto tree because the inherent ties between the two
>> code-base.
>
> I can send you pull requests then if there are development cycles when
> there are in fact relations between the two trees. I'll update the
> commit message describing Zinc to include this.
>
Can you explain why you it is so important to you that your changes
remain outside the crypto tree?
Also, I still think the name Zinc (zinc is not crypto/) is needlessly
divisive and condescending, and unsaying it (in v2 and up) doesn't
really work on the Internet (especially since you are still repeating
it in your conference talk.)
^ permalink raw reply
* RE: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
From: Madalin-cristian Bucur @ 2018-10-02 6:07 UTC (permalink / raw)
To: Leo Li
Cc: Roy Pledge, Claudiu Manoil, Catalin Marinas, Scott Wood,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linuxppc-dev, lkml, netdev@vger.kernel.org
In-Reply-To: <CADRPPNQgGAYTCmppyxPwQnnC433QLm21D5iq_4EvSj0LrsAxGQ@mail.gmail.com>
> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Tuesday, October 2, 2018 12:50 AM
> To: Madalin-cristian Bucur <madalin.bucur@nxp.com>
> Cc: Roy Pledge <roy.pledge@nxp.com>; Claudiu Manoil
> <claudiu.manoil@nxp.com>; Catalin Marinas <catalin.marinas@arm.com>; Scott
> Wood <oss@buserror.net>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; linuxppc-dev
> <linuxppc-dev@lists.ozlabs.org>; lkml <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v2 5/5] soc/fsl_qbman: export coalesce change API
>
> On Fri, Sep 28, 2018 at 3:45 AM Madalin Bucur <madalin.bucur@nxp.com>
> wrote:
> >
> > Export the API required to control the QMan portal interrupt coalescing
> > settings.
>
> These are new APIs not just old APIs being exported. What is the user
> of these APIs? Is the user being submitted? We cannot have APIs in
> kernel that has no users.
Hi,
These are new APIs that will be used in the DPAA Ethernet driver.
Changes for the DPAA QBMan and DPAA Ethernet follow different paths upstream
so the Ethernet driver patch that makes use of these APIs will be sent when
these changes reach the net-next/master tree.
Regards,
Madalin
^ permalink raw reply
* Re: [PATCH net-next] hv_netvsc: Fix rndis_per_packet_info internal field initialization
From: David Miller @ 2018-10-02 6:15 UTC (permalink / raw)
To: haiyangz, haiyangz
Cc: netdev, kys, sthemmin, olaf, vkuznets, devel, linux-kernel
In-Reply-To: <20180928144123.11926-1-haiyangz@linuxonhyperv.com>
From: Haiyang Zhang <haiyangz@linuxonhyperv.com>
Date: Fri, 28 Sep 2018 14:41:23 +0000
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The RSC feature -- a bit field "internal" was added here with total
> size unchanged:
> struct rndis_per_packet_info {
> u32 size;
> u32 type:31;
> u32 internal:1;
> u32 ppi_offset;
> };
>
> On TX path, we put rndis msg into skb head room, which is not zeroed
> before passing to us. We do not use the "internal" field in TX path,
> but it may impact older hosts which use the entire 32 bits as "type".
>
> To fix the bug, this patch sets the field "internal" to zero.
>
> Fixes: c8e4eff4675f ("hv_netvsc: Add support for LRO/RSC in the vSwitch")
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] selftests/tls: Fix recv(MSG_PEEK) & splice() test cases
From: David Miller @ 2018-10-02 6:19 UTC (permalink / raw)
To: vakul.garg
Cc: netdev, linux-kselftest, linux-kernel, shuah, davejwatson,
doronrk
In-Reply-To: <20180928161808.10363-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Fri, 28 Sep 2018 21:48:08 +0530
> TLS test cases splice_from_pipe, send_and_splice &
> recv_peek_multiple_records expect to receive a given nummber of bytes
> and then compare them against the number of bytes which were sent.
> Therefore, system call recv() must not return before receiving the
> requested number of bytes, otherwise the subsequent memcmp() fails.
> This patch passes MSG_WAITALL flag to recv() so that it does not return
> prematurely before requested number of bytes are copied to receive
> buffer.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox