Re: [PATCH] netfilter: nf_conntrack: Add conntrack helper for ESP/IPsec

Cole Dishington wrote: > Introduce changes to add ESP connection tracking helper to netfilter > conntrack. The connection tracking of ESP is based on IPsec SPIs. The > underlying motivation for this patch was to allow multiple VPN ESP > clients to be distinguished when using NAT. > > Added config

Re: linux-next: build failure after merge of the net-next tree

Stephen Rothwell wrote: > net/bridge/netfilter/ebtables.c:1248:33: error: 'struct netns_xt' has no > member named 'tables' > 1248 | list_for_each_entry(t, >xt.tables[NFPROTO_BRIDGE], list) { > | ^ > include/linux/list.h:619:20: note: in definition of macro

Re: [PATCH][next] netfilter: nf_log_bridge: Fix missing assignment of ret on a call to nf_log_register

Colin King wrote: > From: Colin Ian King > > Currently the call to nf_log_register is returning an error code that > is not being assigned to ret and yet ret is being checked. Fix this by > adding in the missing assignment. Thanks for catching this. Acked-by: Florian Westphal

Re: [PATCH 5.10 104/157] mptcp: put subflow sock on connect error

Naresh Kamboju wrote: > On Mon, 22 Mar 2021 at 18:15, Greg Kroah-Hartman > wrote: > > > > From: Florian Westphal > > > > [ Upstream commit f07157792c633b528de5fc1dbe2e4ea54f8e09d4 ] > > > > mptcp_add_pending_subflow() performs a sock_hold() on the subf

Re: [PATCH v3] audit: log nftables configuration change events once per table

Richard Guy Briggs wrote: > nft_commit_notify(net, NETLINK_CB(skb).portid); > nf_tables_gen_notify(net, skb, NFT_MSG_NEWGEN); > nf_tables_commit_release(net); > > + nf_tables_commit_audit_log(, net->nft.base_seq); This meeds to be before nf_tables_commit_release() call,

Re: [PATCH v2 3/3] netfilter: x_tables: Use correct memory barriers.

Mark Tomlinson wrote: > When a new table value was assigned, it was followed by a write memory > barrier. This ensured that all writes before this point would complete > before any writes after this point. However, to determine whether the > rules are unused, the sequence counter is read. To

Re: [PATCH] net: bridge: fix error return code of do_update_counters()

Jia-Ju Bai wrote: > When find_table_lock() returns NULL to t, no error return code of > do_update_counters() is assigned. Its -ENOENT. > t = find_table_lock(net, name, , _mutex); ^ ret is passed to find_table_lock, which passes it to

Re: [PATCH 3/3] netfilter: x_tables: Use correct memory barriers.

Mark Tomlinson wrote: > When a new table value was assigned, it was followed by a write memory > barrier. This ensured that all writes before this point would complete > before any writes after this point. However, to determine whether the > rules are unused, the sequence counter is read. To

Re: [PATCH 2/3] Revert "netfilter: x_tables: Switch synchronization to RCU"

Mark Tomlinson wrote: > This reverts commit cc00bcaa589914096edef7fb87ca5cee4a166b5c. > > This (and the preceding) patch basically re-implemented the RCU > mechanisms of patch 784544739a25. That patch was replaced because of the > performance problems that it created when replacing tables. Now,

Re: [PATCH 1/3] Revert "netfilter: x_tables: Update remaining dereference to RCU"

Mark Tomlinson wrote: > This reverts commit 443d6e86f821a165fae3fc3fc13086d27ac140b1. > > This (and the following) patch basically re-implemented the RCU > mechanisms of patch 784544739a25. That patch was replaced because of the > performance problems that it created when replacing tables. Now,

Re: [PATCH] xfrm: Fix incorrect types in assignment

Yang Li wrote: > Fix the following sparse warnings: > net/xfrm/xfrm_policy.c:1303:22: warning: incorrect type in assignment > (different address spaces) > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > net/xfrm/xfrm_policy.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Richard Guy Briggs wrote: > > If they appear in a batch tehy will be ignored, if the batch consists of > > such non-modifying ops only then nf_tables_commit() returns early > > because the transaction list is empty (nothing to do/change). > > Ok, one little inconvenient question: what about

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Richard Guy Briggs wrote: > Ok, can I get one more clarification on this "hierarchy"? Is it roughly > in the order they appear in nf_tables_commit() after step 3? It appears > it might be mostly already. If it isn't already, would it be reasonable > to re-order them? Would you suggest a

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Richard Guy Briggs wrote: > On 2021-02-18 09:22, Florian Westphal wrote: > > No. There is a hierarchy, e.g. you can't add a chain without first > > adding a table, BUT in case the table was already created by an earlier > > transaction it can also be stand-alone. &g

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Richard Guy Briggs wrote: > On 2021-02-11 23:09, Florian Westphal wrote: > > So, if just a summary is needed a single audit_log_nfcfg() > > after 'step 3' and outside of the list_for_each_entry_safe() is all > > that is needed. > > Ok, so it should not matt

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Richard Guy Briggs wrote: > > > I personally would notify once per transaction. This is easy and quick. > > This was the goal. iptables was atomic. nftables appears to no longer > be so. If I have this wrong, please show how that works. nftables transactions are atomic, either the entire

Re: [v3 net-next 08/10] skbuff: reuse NAPI skb cache on allocation path (__build_skb())

Alexander Lobakin wrote: > we're in such context. This includes: build_skb() (called only > from NIC drivers in NAPI Rx context) and {,__}napi_alloc_skb() > (called from the same place or from kernel network softirq > functions). build_skb is called from sleepable context in drivers/net/tun.c .

Re: [PATCH net-next 3/3] net: core: Namespace-ify sysctl_rmem_max and sysctl_wmem_max

menglong8.d...@gmail.com wrote: > From: Menglong Dong > > For now, sysctl_wmem_max and sysctl_rmem_max are globally unified. > It's not convenient in some case. For example, when we use docker > and try to control the default udp socket receive buffer for each > container. > > For that reason,

Re: [PATCH] netfilter: Fix memleak in nf_nat_init

Dinghao Liu wrote: > When register_pernet_subsys() fails, nf_nat_bysource > should be freed just like when nf_ct_extend_register() > fails. Acked-by: Florian Westphal

Re: [PATCH] selftests: xfrm: fix test return value override issue in xfrm_policy.sh

echo $? > 0 > > This is because the $lret in check_xfrm() is not a local variable. Acked-by: Florian Westphal

Re: kernel BUG at lib/string.c:LINE! (6)

Linus Torvalds wrote: > On Tue, Dec 22, 2020 at 6:44 AM syzbot > wrote: > > > > The issue was bisected to: > > > > commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments") > > That looks unlikely, although possibly some constant folding > improvement might make the fortify code

Re: [PATCH v6 0/3] net, mac80211, kernel: enable KCOV remote coverage collection for 802.11 frame handling

Marco Elver wrote: [..] > v6: > * Revert usage of skb extensions due to potential memory leak. Patch 2/3 is > now > idential to that in v2. > * Patches 1/3 and 3/3 are otherwise identical to v5. The earlier series was already applied to net-next, so you need to rebase on top of net-next and

Re: [PATCH v5 2/3] net: add kcov handle to skb extensions

Ido Schimmel wrote: > On Thu, Oct 29, 2020 at 05:36:19PM +, Aleksandr Nogikh wrote: > > From: Aleksandr Nogikh > > > > Remote KCOV coverage collection enables coverage-guided fuzzing of the > > code that is not reachable during normal system call execution. It is > > especially helpful for

Re: [PATCH 108/141] netfilter: ipt_REJECT: Fix fall-through warnings for Clang

Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. Acked-by: Florian Westphal

Re: [PATCH 015/141] netfilter: Fix fall-through warnings for Clang

Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements instead of just > letting the code fall through to the next case. Acked-by: Florian Westphal Feel free to carry this in next

Re: [PATCH net-next v5] net: linux/skbuff.h: combine SKB_EXTENSIONS + KCOV handling

in the header file. Thanks Randy. Acked-by: Florian Westphal

Re: [PATCH net-next v4] net: linux/skbuff.h: combine SKB_EXTENSIONS + KCOV handling

Randy Dunlap wrote: > On 11/16/20 7:30 AM, Jakub Kicinski wrote: > > On Mon, 16 Nov 2020 15:31:21 +0100 Florian Westphal wrote: > >>>> @@ -4151,12 +4150,11 @@ enum skb_ext_id { > >>>> #if IS_ENABLED(CONFIG_MPTCP) > >>>> SKB_EXT_MPT

Re: [PATCH net-next v4] net: linux/skbuff.h: combine SKB_EXTENSIONS + KCOV handling

Matthieu Baerts wrote: > > --- linux-next-20201113.orig/include/linux/skbuff.h > > +++ linux-next-20201113/include/linux/skbuff.h > > @@ -4137,7 +4137,6 @@ static inline void skb_set_nfct(struct s > > #endif > > } > > -#ifdef CONFIG_SKB_EXTENSIONS > > enum skb_ext_id { > > #if

Re: [PATCH] netfilter: nf_nat: Support fullcone NAT

Paul Menzel wrote: > From: Kiran Kella > > Changes done in the kernel to ensure 3-tuple uniqueness of the conntrack > entries for the fullcone nat functionality. > > * Hashlist is maintained for the 3-tuple unique keys (Protocol/Source > IP/Port) for all the conntrack entries. > > *

Re: [PATCH linux-5.9 1/1] net: netfilter: fix KASAN: slab-out-of-bounds Read in nft_flow_rule_create

Greg KH wrote: [ Trimming CC ] > On Sun, Oct 25, 2020 at 04:31:57PM -0700, Saeed Mirzamohammadi wrote: > > Adding stable. > > What did that do? Its a request to pick up commit 31cc578ae2de19c748af06d859019dced68e325d Author: Saeed Mirzamohammadi Date: Tue Oct 20 13:41:36 2020 +0200

Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register

Francesco Ruggeri wrote: > On Wed, Oct 14, 2020 at 1:23 AM Florian Westphal wrote: > > > > Pablo Neira Ayuso wrote: > > > Legacy would still be flawed though. > > > > Its fine too, new rule blob gets handled (and match/target checkentry > > called) bef

Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register

Pablo Neira Ayuso wrote: > > Yes, we iterate table on re-register and modify the existing entries. > > For iptables-nft, it might be possible to avoid this deregister + > register ct hooks in the same transaction: Maybe add something like > nf_ct_netns_get_all() to bump refcounters by one _iff_

Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register

Jozsef Kadlecsik wrote: > > The "delay unregister" remark was wrt. the "all rules were deleted" > > case, i.e. add a "grace period" rather than acting right away when > > conntrack use count did hit 0. > > Now I understand it, thanks really. The hooks are removed, so conntrack > cannot "see"

Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register

Jozsef Kadlecsik wrote: > > The repro clears all rules, waits 4 seconds, then restores the ruleset. > > using iptables-restore < FOO; sleep 4; iptables-restore < FOO will not > > result in any unregister ops. > > > > We could make kernel defer unregister via some work queue but i don't > > see

Re: [PATCH nf v2] netfilter: conntrack: connection timeout after re-register

Jozsef Kadlecsik wrote: > > Any comments? > > Here is a simple reproducer. The idea is to show that keepalive packets > > in an idle tcp connection will be dropped (and the connection will time > > out) if conntrack hooks are de-registered and then re-registered. The > > reproducer has two

Re: [PATCH v3 1/1] netfilter: nat: add a range check for l3/l4 protonum

Pablo Neira Ayuso wrote: > Hi Will, > > Given this is for -stable maintainers only, I'd suggest: > > 1) Specify what -stable kernel versions this patch applies to. >Explain that this problem is gone since what kernel version. > > 2) Maybe clarify that this is only for stable in the patch

Re: [PATCH] netfilter: nf_conntrack_sip: fix parsing error

Tong Zhang wrote: > ct_sip_parse_numerical_param can only return 0 or 1, but the caller is > checking parsing error using < 0 Reviewed-by: Florian Westphal

Re: [PATCH] net: eliminate meaningless memcpy to data in pskb_carve_inside_nonlinear()

Miaohe Lin wrote: > The skb_shared_info part of the data is assigned in the following loop. Where?

[PATCH nf] netfilter: nft_compat: remove flush counter optimization

("netfilter: nft_compat: make sure xtables destructors have run") Reported-by: kernel test robot Signed-off-by: Florian Westphal --- net/netfilter/nft_compat.c | 37 ++--- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/net/netfilter/nft_comp

Re: [PATCH ghak124 v1] audit: log nftables configuration change events

Richard Guy Briggs wrote: > Well, we are only logging "some change", so is it necessary to log the > generation count to show that? Is the generation count of specific > interest? No, its of no specific interest. I just worded this poorly. If the generation id increments, then something has

Re: [PATCH ghak124 v1] audit: log nftables configuration change events

Richard Guy Briggs wrote: > iptables, ip6tables, arptables and ebtables table registration, > replacement and unregistration configuration events are logged for the > native (legacy) iptables setsockopt api, but not for the > nftables netlink api which is used by the nft-variant of iptables in >

Re: [PATCH] netfilter: nf_osf: avoid passing pointer to local var

Wreturn-local-addr] > net/netfilter/nfnetlink_osf.c:171:16: note: declared here > 171 | struct tcphdr _tcph; > |^ > > I am not sure whether this can happen in practice, but moving the > variable declaration into the callers avoids the problem. LGTM

Re: [PATCH] [netfilter]: Fix skb->csum calculation when netfilter manipulation for NF_NAT_MANIP_SRC\DST is done on IPV6 packet.

Praveen Chaudhary wrote: > Update skb->csum, when netfilter code updates IPV6 SRC\DST address in IPV6 > HEADER due to iptable rule. > > Signed-off-by: Praveen Chaudhary > Signed-off-by: Zhenggen Xu > Signed-off-by: Andy Stracner > --- > include/net/checksum.h | 2 ++ >

Re: [PATCH] netfilter:get_next_corpse():No need to double check the *bucket

wh_...@126.com wrote: > From: Hongbin Wang > > The *bucket is in for loops,it has been checked. > > Signed-off-by: Hongbin Wang > --- > net/netfilter/nf_conntrack_core.c | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/net/netfilter/nf_conntrack_core.c

Re: [PATCH v4 1/2] netfilter: Terminate rule eval if protocol=IPv6 and ipv6 module is disabled

Pablo Neira Ayuso wrote: > On Tue, Sep 03, 2019 at 01:46:50PM -0300, Leonardo Bras wrote: > > On Fri, 2019-08-30 at 22:58 +0200, Florian Westphal wrote: > > > Leonardo Bras wrote: > > > > If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up >

Re: [PATCH v4 1/2] netfilter: Terminate rule eval if protocol=IPv6 and ipv6 module is disabled

luation when packet protocol is IPv6 but the ipv6 module > is not loaded. > > Signed-off-by: Leonardo Bras Acked-by: Florian Westphal

Re: [PATCH v4 2/2] net: br_netfiler_hooks: Drops IPv6 packets if IPv6 module is not loaded

Leonardo Bras wrote: > A kernel panic can happen if a host has disabled IPv6 on boot and have to > process guest packets (coming from a bridge) using it's ip6tables. > > IPv6 packets need to be dropped if the IPv6 module is not loaded. > > Signed-off-by: Leonardo Bras > --- >

Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot

Leonardo Bras wrote: > On Thu, 2019-08-29 at 22:58 +0200, Florian Westphal wrote: > [...] > > 1. add a patch to BREAK in nft_fib_netdev.c for !ipv6_mod_enabled() > [...] > > But this is still needed? I mean, in nft_fib_netdev_eval there are only > 2 functions being

Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot

Leonardo Bras wrote: > On Thu, 2019-08-29 at 17:04 -0300, Leonardo Bras wrote: > > > Thats a good point -- Leonardo, is the > > > "net.bridge.bridge-nf-call-ip6tables" sysctl on? > > > > Running > > # sudo sysctl -a > > I can see: > > net.bridge.bridge-nf-call-ip6tables = 1 > > Also, doing > #

Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot

Leonardo Bras wrote: > > Thats a good point -- Leonardo, is the > > "net.bridge.bridge-nf-call-ip6tables" sysctl on? > > Running > # sudo sysctl -a > I can see: > net.bridge.bridge-nf-call-ip6tables = 1 > > So this packets are sent to host iptables for processing? Yes, this is an hold hack

Re: [PATCH 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot

Leonardo Bras wrote: > If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up > dealing with a IPv6 package, it causes a kernel panic in > fib6_node_lookup_1(), crashing in bad_page_fault. > > The panic is caused by trying to deference a very low address (0x38 > in ppc64le), due

Re: [PATCH] net/netfilter/nf_nat_proto.c - make tables static

6: warning: symbol 'nf_nat_ipv6_ops' was > not declared. Should it be static? > > And in fact they can indeed be static. Acked-by: Florian Westphal Seems i removed the static qualifier when i added inet nat support, but the patch that was merged doesn't use them outside of nf_nat_proto.c. Thanks for fixing this.

Re: [PATCH] netfilter: add include guard to xt_connlabel.h

Masahiro Yamada wrote: > Add a header include guard just in case. Acked-by: Florian Westphal

Re: KASAN: use-after-free Write in xfrm_hash_rebuild

syzbot wrote: > syzbot has bisected this bug to: > > commit 1548bc4e0512700cf757192c106b3a20ab639223 > Author: Florian Westphal > Date: Fri Jan 4 13:17:02 2019 + > > xfrm: policy: delete inexact policies from inexact list on hash rebuild I'm looking at this now.

Re: [PATCH][next] xfrm: fix missing break on AF_INET6 case

Colin King wrote: > From: Colin Ian King > > It appears that there is a missing break statement for the AF_INET6 case > that falls through to the default WARN_ONCE case. I don't think that is > intentional. Fix this by adding in the missing break. Yes, I sent same patch a few minutes ago:

Re: Kernel 5.1 breaks UDP checksums for SIP packets

Marc Haber wrote: > when I update my Firewall from Kernel 5.0 to Kernel 5.1, SIP clients > that connect from the internal network to an external, commercial SIP > service do not work any more. When I trace beyond the NAT, I see that > the outgoing SIP packets have incorrect UDP checksums: I'm a

Re: [PATCH 4.9 41/51] fib_rules: return 0 directly if an exactly same rule exists when NLM_F_EXCL not supplied

Nathan Chancellor wrote: > On Wed, May 15, 2019 at 12:56:16PM +0200, Greg Kroah-Hartman wrote: > > From: Hangbin Liu > > > > [ Upstream commit e9919a24d3022f72bcadc407e73a6ef17093a849 ] [..] > > Fixes: 153380ec4b9 ("fib_rules: Added NLM_F_EXCL support to fib_nl_newrule") > > Reported-by:

Re: [PATCH] selftests : netfilter: Wrote a error and exit code for a command which needed veth kernel module.

shuah wrote: > Would you like me to take this patch through ksleftest tree? Please do, this patch is neither in nf nor nf-next and it looks fine to me.

Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit

Andreas Hartmann wrote: > On 22.04.19 at 20:57 Florian Westphal wrote: > > grep CONNCOUNT ~/your_kernel_conf > > True - it's not in use (it's not even configured) at all. I'm surprised that > it seems to fix the problem anyway. Thats usually the main problem when testing for

Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit

Andreas Hartmann wrote: > > Could you at least tell us how you're using nf_conncount (nf/iptables > > rules)? > > # Generated by iptables-save v1.6.2 on Mon Apr 22 20:19:30 2019 > *filter > :INPUT DROP [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT DROP [4423:248703] > -A INPUT -s 127.0.0.1/32 -d

Re: [PATCH 4.19 13/99] netfilter: nf_conncount: fix argument order to find_next_bit

Andreas Hartmann wrote: > Since 4.19.17, I'm facing problems during streaming of videos I've never seen > before. This means: > > - video from internet stutters although enough data flow can be seen in bmon. > - gpu is locked: > radeon :0a:00.0: ring 0 stalled for more than 14084msec >

Re: [PATCH] selftests : netfilter: Wrote a error and exit code for a command which needed veth kernel module.

nd correct code exit. Looks good to me, thanks for following up on this. Acked-by: Florian Westphal

Re: about selftests/netfilter test related issue

Jeffrin Thalakkottoor wrote: > Error: Unknown device type. Feel free to send a patch that makes it display a more reasonable exit+error here.

Re: about selftests/netfilter test related issue

Jeffrin Thalakkottoor wrote: > i think the script nft_nat.sh is assuming devices eth0 and eth1 No it does not. These are arbitrary names given to veth devices. > Error: Unknown device type. No Veth device support in kernel?

Re: NULL pointer dereference in nft_set_elem_destroy()

Dmitrii Tcvetkov wrote: > After upgrade to 5.0 on XPS 13 9360 I get NULL pointer dereference in > dmesg (attached). Distro is Arch Linux, kernel is built with custom > config (attached), but distro kernel[1] reproduces the issue on the > laptop as well. > > Bisect led me to commit f6ac858589768

Re: Kernel 5.0-rc5 regression with NAT, bisected to: netfilter: nat: remove l4proto->manip_pkt

Florian Westphal wrote: > Sander Eikelenboom wrote: > > L.S., > > > > While trying out a 5.0-RC5 kernel I seem to have stumbled over a regression > > with NAT. > > (using an nftables firewall with NAT and connection tracking). > > > > Unfor

Re: Kernel 5.0-rc5 regression with NAT, bisected to: netfilter: nat: remove l4proto->manip_pkt

c3a6696918 is the first bad commit > commit faec18dbb0405c7d4dda025054511dc3a6696918 > Author: Florian Westphal > Date: Thu Dec 13 16:01:33 2018 +0100 > > netfilter: nat: remove l4proto->manip_pkt Thanks, this is immensely helpful. I think I see the bug, we can't use target

Re: general protection fault in __xfrm_policy_bysel_ctx

Dmitry Vyukov wrote: > > syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit:085c4c7dd2b6 net: lmc: remove -I. header search path > > > git tree: net-next > > > console output: https://syzkaller.appspot.com/x/log.txt?x=12347128c0 > >

Re: general protection fault in __xfrm_policy_bysel_ctx

syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:085c4c7dd2b6 net: lmc: remove -I. header search path > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12347128c0 > kernel config:

Re: [REGRESSION] 5.0-rc2: iptables -nvL consumes 100% of CPU and hogs memory with kernel 5.0-rc2

Michal Kubecek wrote: > > I upgraded to self-compiled 5.0-rc2 today and found the machine to be slow > > after startup. I saw iptables consuming 100% CPU, it only responded to > > SIGKILL. It got restarted several times, probably by some systemd service. > > > > Then I started 'iptables -nvL'

Re: seqcount usage in xt_replace_table()

Peter Zijlstra wrote: > Would using synchronize_rcu() not also mean you can get rid of that > xt_write_recseq*() stuff entirely? No, because those are used to synchronize with cpus that read the ruleset counters, see net/ipv4/netfilter/ip_tables.c:get_counters(). > Anyway, synchronize_rcu()

Re: seqcount usage in xt_replace_table()

Peter Zijlstra wrote: > /* >* Ensure contents of newinfo are visible before assigning to >* private. >*/ > smp_wmb(); > table->private = newinfo; > > we have: > > smp_store_release(>private, newinfo); > > But what store does that second smp_wmb()

Re: seqcount usage in xt_replace_table()

Anatol Pomozov wrote: > Or maybe xt_replace_table() can be enhanced? When I hear that > something waits until an event happens on all CPUs I think about > wait_event() function. Would it be better for xt_replace_table() to > introduce an atomic counter that is decremented by CPUs, and the main >

Re: [PATCH] netfilter: account ebt_table_info to kmemcg

Michal Hocko wrote: > On Fri 28-12-18 17:55:24, Shakeel Butt wrote: > > The [ip,ip6,arp]_tables use x_tables_info internally and the underlying > > memory is already accounted to kmemcg. Do the same for ebtables. The > > syzbot, by using setsockopt(EBT_SO_SET_ENTRIES), was able to OOM the > >

Re: KASAN: use-after-free Write in __xfrm_policy_unlink

syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit:ce28bb445388 Merge git://git.kernel.org/pub/scm/linux/kern.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=1673fb1b40 > kernel config:

[PATCH net-next] staging: octeon: fix build failure with XFRM enabled

quot;) Signed-off-by: Florian Westphal --- Greg, David: The patch will not break build for a tree that lacks the 'Fixes' commit, so this can also go in via staging tree. OTOH, net-next build is broken for mips/octeon, so I think in this case net-next might make more sense? diff --git a/dr

Re: linux-next: Tree for Dec 21

Guenter Roeck wrote: > mips:cavium_octeon_defconfig [4] > git bisect bad 4165079ba328dd47262a2183049d3591f0a750b1 > # first bad commit: [4165079ba328dd47262a2183049d3591f0a750b1] net: switch > secpath to use skb extension infrastructure Indeed, sorry. staging/octeon needs a small fix.

Re: INFO: rcu detected stall in pfkey_sendmsg

Dmitry Vyukov wrote: > On Wed, Dec 19, 2018 at 7:37 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:a26d94bff4d5 net: bridge: remove unneeded variable 'err' > > git tree: net-next > > console output:

Re: INFO: rcu detected stall in xfrm_hash_rebuild

Christophe Gouault wrote: > The main use cases I have encountered and tried to address with the > hash-based lookup were network operator use cases: > - a lot of dynamic /32 <=> /32 policies (protecting GTP tunnels) > - or a lot of dynamic policies with the same prefix lengths (e.g. /16 <=> /24)

Re: INFO: rcu detected stall in xfrm_hash_rebuild

Wolfgang Walter wrote: [ CCing Christophe ] > Am Montag, 10. Dezember 2018, 09:58:56 schrieb David Miller: > > From: Florian Westphal > > Date: Mon, 10 Dec 2018 13:47:24 +0100 > > > > > After recent tree conversion, we could probably make the exact policies &

Re: WARNING in xfrm_policy_inexact_gc_tree

syzbot wrote: > > HEAD commit:74c4a24df7ca Add linux-next specific files for 20181207 > git tree: linux-next > console output: https://syzkaller.appspot.com/x/log.txt?x=17bbea7d40 > kernel config: https://syzkaller.appspot.com/x/.config?x=6e9413388bf37bed > dashboard link:

Re: INFO: rcu detected stall in xfrm_hash_rebuild

syzbot wrote: > Hello, > > syzbot found the following crash on: [..] > Workqueue: events xfrm_hash_rebuild Ignoring this report for a second -- I think it makes sense to see if we can just remove the entire hash table rebuild/resize code. After recent tree conversion, we could probably make

Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

Wolfgang Walter wrote: > thanks to the fix from Steffen Klassert I could now run 4.14.69 + his patch > and 4.18.7 + his patch without oopsing immediately. > > But I found that those kernels perform very bad. They perform so bad that > they > are unusable for our router with about 3000 ipsec

Re: Regression: kernel 4.14 an later very slow with many ipsec tunnels

Wolfgang Walter wrote: > thanks to the fix from Steffen Klassert I could now run 4.14.69 + his patch > and 4.18.7 + his patch without oopsing immediately. > > But I found that those kernels perform very bad. They perform so bad that > they > are unusable for our router with about 3000 ipsec

Re: [PATCH] netlink: fix memory leak of dump

Pablo Neira Ayuso wrote: > > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c > > --- a/net/netfilter/nf_tables_api.c > > +++ b/net/netfilter/nf_tables_api.c > > @@ -5010,6 +5013,22 @@ nft_obj_filter_alloc(const struct nlattr * const > > nla[]) > > return filter; >

Re: [PATCH] netlink: fix memory leak of dump

Pablo Neira Ayuso wrote: > > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c > > --- a/net/netfilter/nf_tables_api.c > > +++ b/net/netfilter/nf_tables_api.c > > @@ -5010,6 +5013,22 @@ nft_obj_filter_alloc(const struct nlattr * const > > nla[]) > > return filter; >

Re: linux-next: build warning after merge of the netfilter-next tree

Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Tue, May 8, 2018 at 9:17 AM, Florian Westphal <f...@strlen.de> wrote: > > Stephen Rothwell <s...@canb.auug.org.au> wrote: > >> On Mon, 7 May 2018 10:55:19 +1000 Stephen Rothwell <s...@canb.auug.org.au>

Re: linux-next: build warning after merge of the netfilter-next tree

Geert Uytterhoeven wrote: > On Tue, May 8, 2018 at 9:17 AM, Florian Westphal wrote: > > Stephen Rothwell wrote: > >> On Mon, 7 May 2018 10:55:19 +1000 Stephen Rothwell > >> wrote: > >> > > >> > After merging the netfilter-next tree, t

[PATCH nf-next] netfilter: fix fallout from xt/nf osf separation

version). tested via allmodconfig build + make headers_check. Reported-by: Stephen Rothwell <s...@canb.auug.org.au> Fixes: bfb15f2a95cb ("netfilter: extract Passive OS fingerprint infrastructure from xt_osf") Signed-off-by: Florian Westphal <f...@strlen.de> --- include/li

[PATCH nf-next] netfilter: fix fallout from xt/nf osf separation

version). tested via allmodconfig build + make headers_check. Reported-by: Stephen Rothwell Fixes: bfb15f2a95cb ("netfilter: extract Passive OS fingerprint infrastructure from xt_osf") Signed-off-by: Florian Westphal --- include/linux/netfilter/nf_osf.h | 6 ++ include/uapi/linux

Re: linux-next: build warning after merge of the netfilter-next tree

Stephen Rothwell wrote: > On Mon, 7 May 2018 10:55:19 +1000 Stephen Rothwell > wrote: > > > > After merging the netfilter-next tree, today's linux-next build (x86_64 > > allmodconfig) produced this warning: > > > >

Re: linux-next: build warning after merge of the netfilter-next tree

Stephen Rothwell wrote: > On Mon, 7 May 2018 10:55:19 +1000 Stephen Rothwell > wrote: > > > > After merging the netfilter-next tree, today's linux-next build (x86_64 > > allmodconfig) produced this warning: > > > > ./usr/include/linux/netfilter/nf_osf.h:25: found __[us]{8,16,32,64} type > >

Re: [nf-next] netfilter: extend SRH match to support matching previous, next and last SID

Ahmed Abdelsalam wrote: > > > @@ -50,6 +62,12 @@ struct ip6t_srh { > > > __u8segs_left; > > > __u8last_entry; > > > __u16 tag; > > > + struct in6_addr psid_addr; > > > + struct in6_addr nsid_addr;

Re: [nf-next] netfilter: extend SRH match to support matching previous, next and last SID

Ahmed Abdelsalam wrote: > > > @@ -50,6 +62,12 @@ struct ip6t_srh { > > > __u8segs_left; > > > __u8last_entry; > > > __u16 tag; > > > + struct in6_addr psid_addr; > > > + struct in6_addr nsid_addr; > > > + struct

Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

valdis.kletni...@vt.edu wrote: > (Resending because I haven't heard anything) [ ip6tables broken ] Sorry, did not see this email before. I'll investigate asap, thanks for the detailed report.

Re: linux-next: ip6tables *broken* - last base chain position %u doesn't match underflow %u (hook %u

valdis.kletni...@vt.edu wrote: > (Resending because I haven't heard anything) [ ip6tables broken ] Sorry, did not see this email before. I'll investigate asap, thanks for the detailed report.

Re: [PATCH AUTOSEL for 4.15 070/124] netfilter: core: only allow one nat hook per hook point

Sasha Levin <alexander.le...@microsoft.com> wrote: > From: Florian Westphal <f...@strlen.de> > > [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ] This patch is broken and a fix is not in any tree yet.

Re: [PATCH AUTOSEL for 4.15 070/124] netfilter: core: only allow one nat hook per hook point

Sasha Levin wrote: > From: Florian Westphal > > [ Upstream commit f92b40a8b2645af38bd6814651c59c1e690db53d ] This patch is broken and a fix is not in any tree yet.

Re: [PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

Arushi Singhal wrote: > On Mon, Mar 12, 2018 at 2:17 AM, Pablo Neira Ayuso > wrote: > > > Hi Joe, > > > > On Sun, Mar 11, 2018 at 12:52:41PM -0700, Joe Perches wrote: > > > On Mon, 2018-03-12 at 01:11 +0530, Arushi Singhal wrote: > > > >

Re: [PATCH v2] net: netfilter: Replace printk() with appropriate pr_*() macro

Arushi Singhal wrote: > On Mon, Mar 12, 2018 at 2:17 AM, Pablo Neira Ayuso > wrote: > > > Hi Joe, > > > > On Sun, Mar 11, 2018 at 12:52:41PM -0700, Joe Perches wrote: > > > On Mon, 2018-03-12 at 01:11 +0530, Arushi Singhal wrote: > > > > Using pr_() is more concise than > > > > printk(KERN_). >

  1   2   3   4   5   6   >