[PATCH net-next 2/5] drivers: replace dev->trans_start accesses with dev_trans_start

inux-r...@vger.kernel.org Signed-off-by: Florian Westphal --- Checkpatch complains about Lines > 80 but I find line break more ugly. drivers/infiniband/ulp/ipoib/ipoib_main.c | 2 +- drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- drivers/net/ethernet/intel/igb/igb_main.c

[PATCH net-next 1/5] dmfe: kill DEVICE define

use net_device directly. Compile tested, objdiff shows no changes. Cc: linux-par...@vger.kernel.org Signed-off-by: Florian Westphal --- drivers/net/ethernet/dec/tulip/dmfe.c | 39 --- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/drivers/net

[PATCH net-next 3/5] netdevice: add helper to update trans_start

low us to change the helper so that it updates the trans_stamp of netdev queue 0 instead. Signed-off-by: Florian Westphal <f...@strlen.de> --- include/linux/netdevice.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index f218

[PATCH net-next 3/5] netdevice: add helper to update trans_start

low us to change the helper so that it updates the trans_stamp of netdev queue 0 instead. Signed-off-by: Florian Westphal --- include/linux/netdevice.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index f218259..798f285

[PATCH net-next 0/5] net: remove trans_start from struct net_device

We currently have two instances for trans_start, once in net_device and once in netdev_queue. This series removes trans_start from net_device. Updates to dev->trans_start are replaced with updates to netdev queue 0. This series is compile-tested only. Replacement is done in 3 steps: 1. Replace

[PATCH net-next 0/5] net: remove trans_start from struct net_device

We currently have two instances for trans_start, once in net_device and once in netdev_queue. This series removes trans_start from net_device. Updates to dev->trans_start are replaced with updates to netdev queue 0. This series is compile-tested only. Replacement is done in 3 steps: 1. Replace

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

Francois Romieu <rom...@fr.zoreil.com> wrote: > Florian Westphal <f...@strlen.de> : > [...] > > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > > index d0084d4..a3200ea 100644 > >

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

Francois Romieu wrote: > Florian Westphal : > [...] > > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > > index d0084d4..a3200ea 100644 > > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c

[PATCH net-next 2/6] atl1c: remove private tx lock

AFAICS this is safe: the lock is only used in the .ndo_start_xmit function and this driver does not set LLTX. Gets rid of TX_LOCKED return value, followup patches will remove it. Cc: Jay Cliburn <jclib...@gmail.com> Cc: Chris Snook <chris.sn...@gmail.com> Signed-off-by: Florian

[PATCH net-next 6/6] net: remove NETDEV_TX_LOCKED support

No more users in the tree, remove NETDEV_TX_LOCKED support. Adds another hole in softnet_stats struct, but better than keeping the unused collision counter around. Signed-off-by: Florian Westphal <f...@strlen.de> --- Documentation/networking/netdev-features.txt | 10 - Documen

[PATCH net-next 2/6] atl1c: remove private tx lock

AFAICS this is safe: the lock is only used in the .ndo_start_xmit function and this driver does not set LLTX. Gets rid of TX_LOCKED return value, followup patches will remove it. Cc: Jay Cliburn Cc: Chris Snook Signed-off-by: Florian Westphal --- drivers/net/ethernet/atheros/atl1c/atl1c.h

[PATCH net-next 6/6] net: remove NETDEV_TX_LOCKED support

No more users in the tree, remove NETDEV_TX_LOCKED support. Adds another hole in softnet_stats struct, but better than keeping the unused collision counter around. Signed-off-by: Florian Westphal --- Documentation/networking/netdev-features.txt | 10 - Documentation/networking

[PATCH net-next 5/6] drivers: net: remove NETDEV_TX_LOCKED

replace the trylock by a full spin_lock and remove TX_LOCKED return value. Followup patch will remove TX_LOCKED from the kernel. Cc: Jon Mason <jdma...@kudzu.us> Cc: Andy Gospodarek <a...@greyhouse.net> Signed-off-by: Florian Westphal <f...@strlen.de> --- drivers/net/ethernet/

[PATCH net-next 0/6] net: core: remove TX_LOCKED support

Not that many users left, lets kill it. TX_LOCKED was meant to be used by LLTX drivers when spin_trylock() failed. Stack then re-queued if collisions happened on different cpus or free'd the skb to prevent deadlocks. Most of the driver removal patches fall into one of three categories: 1.

[PATCH net-next 5/6] drivers: net: remove NETDEV_TX_LOCKED

replace the trylock by a full spin_lock and remove TX_LOCKED return value. Followup patch will remove TX_LOCKED from the kernel. Cc: Jon Mason Cc: Andy Gospodarek Signed-off-by: Florian Westphal --- drivers/net/ethernet/chelsio/cxgb/sge.c | 3 +-- drivers/net/ethernet/neterion

[PATCH net-next 0/6] net: core: remove TX_LOCKED support

Not that many users left, lets kill it. TX_LOCKED was meant to be used by LLTX drivers when spin_trylock() failed. Stack then re-queued if collisions happened on different cpus or free'd the skb to prevent deadlocks. Most of the driver removal patches fall into one of three categories: 1.

[PATCH net-next 4/6] drivers: net: use NETDEV_TX_OK instead of NETDEV_TX_LOCKED

sai...@alumni.ethz.ch> Signed-off-by: Florian Westphal <f...@strlen.de> --- checkpatch chokes on this one, tulip uses spaces, not tabs... drivers/net/ethernet/amd/7990.c| 8 +--- drivers/net/ethernet/amd/a2065.c | 7 +++ drivers/net/ethernet/dec/tulip/de4x5.c | 7 +--

[PATCH net-next 3/6] atle1: remove LLTX support and TX_UNLOCKED

; Signed-off-by: Florian Westphal <f...@strlen.de> --- drivers/net/ethernet/atheros/atl1e/atl1e.h | 1 - drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 12 +--- 2 files changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e.h b/dr

[PATCH net-next 1/6] RDMA/nes: remove use of NETDEV_TX_LOCKED

ndo_start_xmit never returns it to stack, but nes_nic_send helper used it if skb could not be queued to hardware. Switch to bool instead. Cc: <linux-r...@vger.kernel.org> Signed-off-by: Florian Westphal <f...@strlen.de> --- drivers/infiniband/hw/nes/nes_nic.c | 13 + 1

[PATCH net-next 4/6] drivers: net: use NETDEV_TX_OK instead of NETDEV_TX_LOCKED

-by: Florian Westphal --- checkpatch chokes on this one, tulip uses spaces, not tabs... drivers/net/ethernet/amd/7990.c| 8 +--- drivers/net/ethernet/amd/a2065.c | 7 +++ drivers/net/ethernet/dec/tulip/de4x5.c | 7 +-- drivers/net/hamradio/baycom_epp.c | 6

[PATCH net-next 3/6] atle1: remove LLTX support and TX_UNLOCKED

similar to atl1c: lock is only used in ndo_start_xmit, but we also advertised LLTX, so remove that as well and let core stack handle tx locking. Allows to remove the TX_LOCKED return value from the driver. Cc: Jay Cliburn Cc: Chris Snook Signed-off-by: Florian Westphal --- drivers/net

[PATCH net-next 1/6] RDMA/nes: remove use of NETDEV_TX_LOCKED

ndo_start_xmit never returns it to stack, but nes_nic_send helper used it if skb could not be queued to hardware. Switch to bool instead. Cc: Signed-off-by: Florian Westphal --- drivers/infiniband/hw/nes/nes_nic.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git

Re: userns, netns, and quick physical memory consumption by unprivileged user

Yuriy M. Kaminskiy wrote: > BTW, all those hash/conntrack/etc default sizes was calculated from > physical memory size in assumption there will be only *one* instance of > those tables. Obviously, introduction of network namespaces (and > especially unprivileged user-ns) thrown

Re: userns, netns, and quick physical memory consumption by unprivileged user

Yuriy M. Kaminskiy wrote: > BTW, all those hash/conntrack/etc default sizes was calculated from > physical memory size in assumption there will be only *one* instance of > those tables. Obviously, introduction of network namespaces (and > especially unprivileged user-ns) thrown this assumption in

Re: [PATCH] netfilter: nft_ct: define nft_ct_get_eval_counter() only when needed

Eric Biggers wrote: > This eliminates an "unused function" compiler warning when > CONFIG_NF_CONNTRACK_LABELS is not defined. > > Signed-off-by: Eric Biggers The nft_ct_get_eval_counter call should've been unconditional. The #endif placement is wrong:

Re: [PATCH] netfilter: nft_ct: define nft_ct_get_eval_counter() only when needed

Eric Biggers wrote: > This eliminates an "unused function" compiler warning when > CONFIG_NF_CONNTRACK_LABELS is not defined. > > Signed-off-by: Eric Biggers The nft_ct_get_eval_counter call should've been unconditional. The #endif placement is wrong:

Re: [PATCH net-next] netfilter: nf_conntrack: remove the unneed check for *bucket

Weidong Wang wrote: > In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size, > so remove the check > @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct > nf_conn *i, void *data), > lockp = _conntrack_locks[*bucket % CONNTRACK_LOCKS]; >

Re: [PATCH net-next] netfilter: nf_conntrack: remove the unneed check for *bucket

Weidong Wang wrote: > In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size, > so remove the check > @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(struct > nf_conn *i, void *data), > lockp = _conntrack_locks[*bucket %

Re: net: GPF in netlink_getsockbyportid

Daniel Borkmann wrote: > On 01/23/2016 08:25 PM, Florian Westphal wrote: > >Dmitry Vyukov wrote: > > > >[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] > > > >>The following program causes GPF in netlink_getsockbyportid: [..] > >CONFIG_

Re: net: GPF in netlink_getsockbyportid

Dmitry Vyukov wrote: [ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] > The following program causes GPF in netlink_getsockbyportid: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include > #include > #include > #include > #include > > int

Re: net: GPF in netlink_getsockbyportid

Dmitry Vyukov wrote: [ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] > The following program causes GPF in netlink_getsockbyportid: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include > #include > #include > #include >

Re: net: GPF in netlink_getsockbyportid

Daniel Borkmann <dan...@iogearbox.net> wrote: > On 01/23/2016 08:25 PM, Florian Westphal wrote: > >Dmitry Vyukov <dvyu...@google.com> wrote: > > > >[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ] > > > >>The followi

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

Florian Westphal wrote: > Thadeu Lima de Souza Cascardo wrote: > > On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote: [ skb_gso_segment uses skb->cb[], causes oops if ip_fragment is invoked on segmented skbs ] > > I have hit this as well, this fixes it

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

Thadeu Lima de Souza Cascardo wrote: > On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote: > > On Wed, Jan 6, 2016 at 10:59 PM, Cong Wang wrote: > > > On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov > > > wrote: > > >> Looks like this happens because

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

Thadeu Lima de Souza Cascardo wrote: > On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote: > > On Wed, Jan 6, 2016 at 10:59 PM, Cong Wang wrote: > > > On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov > >

Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation

Florian Westphal <f...@strlen.de> wrote: > Thadeu Lima de Souza Cascardo <casca...@redhat.com> wrote: > > On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote: [ skb_gso_segment uses skb->cb[], causes oops if ip_fragment is invoked on segmente

[PATCH] connector: bump skb->users before callback invocation

Dmitry reports memleak with syskaller program. Problem is that connector bumps skb usecount but might not invoke callback. So move skb_get to where we invoke the callback. Reported-by: Dmitry Vyukov Signed-off-by: Florian Westphal --- I wonder wth userspace can cram skb->len < NLMSG_

[PATCH] connector: bump skb->users before callback invocation

Dmitry reports memleak with syskaller program. Problem is that connector bumps skb usecount but might not invoke callback. So move skb_get to where we invoke the callback. Reported-by: Dmitry Vyukov <dvyu...@google.com> Signed-off-by: Florian Westphal <f...@strlen.de> --- I wonder w

Re: linux-next: kernel panic in ipv6_defrag

Junxiao Bi wrote: > The following panic happened when I run ocfs2-test on linux-next. Kernel > config is attached. > > [64910.905501] BUG: unable to handle kernel NULL pointer dereference at > (null) > [64910.906466] IP: [] nf_ct_frag6_gather+0x7ad/0x9c0 [..] > ocfs2_stack_o2cb(O)

Re: linux-next: kernel panic in ipv6_defrag

Junxiao Bi wrote: > The following panic happened when I run ocfs2-test on linux-next. Kernel > config is attached. > > [64910.905501] BUG: unable to handle kernel NULL pointer dereference at > (null) > [64910.906466] IP: [] nf_ct_frag6_gather+0x7ad/0x9c0 [..] >

Re: [PATCH] ila: add NETFILTER dependency

Pablo Neira Ayuso wrote: > On Fri, Dec 18, 2015 at 03:37:37PM +0100, Arnd Bergmann wrote: > > The recently added generic ILA translation facility fails to > > build when CONFIG_NETFILTER is disabled: > > > > net/ipv6/ila/ila_xlat.c:229:20: warning: 'struct nf_hook_state' declared > > inside

Re: [PATCH] ila: add NETFILTER dependency

Pablo Neira Ayuso wrote: > On Fri, Dec 18, 2015 at 03:37:37PM +0100, Arnd Bergmann wrote: > > The recently added generic ILA translation facility fails to > > build when CONFIG_NETFILTER is disabled: > > > > net/ipv6/ila/ila_xlat.c:229:20: warning: 'struct nf_hook_state'

Re: next-20151207 - crash in IPv6 code

Valdis Kletnieks wrote: [ CC Pablo ] > Seen this in 2 boots out of two on next-20151207 when IPV6 networking > was available. It was stable when no net was available. Also, next-20161127 > is OK. > Haven't bisected it yet - this ring any bells? Thanks for the report, my fault -- its caused

Re: next-20151207 - crash in IPv6 code

Valdis Kletnieks wrote: [ CC Pablo ] > Seen this in 2 boots out of two on next-20151207 when IPV6 networking > was available. It was stable when no net was available. Also, next-20161127 > is OK. > Haven't bisected it yet - this ring any bells? Thanks for the report,

Re: [PATCH net-next 08/10] hv_netvsc: Don't ask for additional head room in the skb

K. Y. Srinivasan wrote: > The rndis header is 116 bytes big and can be placed in the default > head room that will be available in the skb. Since the netvsc packet > is less than 48 bytes, we can use the skb control buffer > for the netvsc packet. With these changes we don't need to > ask for

Re: [PATCH net-next 08/10] hv_netvsc: Don't ask for additional head room in the skb

K. Y. Srinivasan wrote: > The rndis header is 116 bytes big and can be placed in the default > head room that will be available in the skb. Since the netvsc packet > is less than 48 bytes, we can use the skb control buffer > for the netvsc packet. With these changes we don't

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

Tejun Heo wrote: > On Sat, Nov 21, 2015 at 05:56:06PM +0100, Florian Westphal wrote: > > > +struct xt_cgroup_info_v1 { > > > + __u8has_path; > > > + __u8has_classid; > > > + __u8invert_path; > > > + __u8

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

Tejun Heo wrote: > This patch implements xt_cgroup path match which matches cgroup2 > membership of the associated socket. The match is recursive and > invertible. > > For rationales on introducing another cgroup based match, please refer > to a preceding commit "sock, cgroup: add

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

Tejun Heo wrote: > This patch implements xt_cgroup path match which matches cgroup2 > membership of the associated socket. The match is recursive and > invertible. > > For rationales on introducing another cgroup based match, please refer > to a preceding commit "sock, cgroup:

Re: [PATCH 9/9] netfilter: implement xt_cgroup cgroup2 path match

Tejun Heo <t...@kernel.org> wrote: > On Sat, Nov 21, 2015 at 05:56:06PM +0100, Florian Westphal wrote: > > > +struct xt_cgroup_info_v1 { > > > + __u8has_path; > > > + __u8has_classid; > > > + __u8invert_path; > &g

Re: [netfilter-core] [PATCH] net: netfilter: fix GCC uninitialized warning

Pablo Neira Ayuso wrote: > On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote: > > With x86_64_defconfig: > > GCC thinks that in nfulnl_recv_config flags parameter is not inited but > > it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). > > Suppress this warning: > >

Re: [netfilter-core] [PATCH] net: netfilter: fix GCC uninitialized warning

Pablo Neira Ayuso wrote: > On Fri, Nov 06, 2015 at 09:48:14PM +0300, Dmitry Safonov wrote: > > With x86_64_defconfig: > > GCC thinks that in nfulnl_recv_config flags parameter is not inited but > > it was under the same condition (nfula[NFULA_CFG_FLAGS] == true). > > Suppress

[PATCH] fault-inject: fix inverted interval/probability values in printk

interval displays the probability and vice versa. Fixes: 6adc4a22f20bb ("fault-inject: add ratelimit option") Signed-off-by: Florian Westphal --- lib/fault-inject.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/fault-inject.c b/lib/fault-inject.c index f1cdeb

[PATCH] fault-inject: fix inverted interval/probability values in printk

interval displays the probability and vice versa. Fixes: 6adc4a22f20bb ("fault-inject: add ratelimit option") Signed-off-by: Florian Westphal <f...@strlen.de> --- lib/fault-inject.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/fault-inject.c b/lib/faul

Re: [PATCH 1/1] net sysfs: Print link speed as signed integer

Alexander Stein wrote: > Otherwise 4294967295 (MBit/s) (-1) will be printed when there is no link. > Documentation/ABI/testing/sysfs-class-net does not state if this shall be > signed or unsigned. > > Signed-off-by: Alexander Stein > --- > diff --git a/net/core/net-sysfs.c

Re: [PATCH 1/1] net sysfs: Print link speed as signed integer

Alexander Stein wrote: > Otherwise 4294967295 (MBit/s) (-1) will be printed when there is no link. > Documentation/ABI/testing/sysfs-class-net does not state if this shall be > signed or unsigned. > > Signed-off-by: Alexander Stein

Re: [PATCH] tcp: Use absolute system clock for TCP timestamps

Eric Dumazet wrote: > On Thu, Sep 24, 2015 at 7:14 AM, Jovi Zhangwei wrote: > > From f455dc3958593250909627474100f6cc5c158a5c Mon Sep 17 00:00:00 2001 > > From: Marek Majkowski > > Date: Fri, 11 Sep 2015 06:05:07 -0700 > > Subject: [PATCH] tcp: Use absolute system clock for TCP timestamps > > >

Re: [PATCH] tcp: Use absolute system clock for TCP timestamps

Eric Dumazet wrote: > On Thu, Sep 24, 2015 at 7:14 AM, Jovi Zhangwei wrote: > > From f455dc3958593250909627474100f6cc5c158a5c Mon Sep 17 00:00:00 2001 > > From: Marek Majkowski > > Date: Fri, 11 Sep 2015 06:05:07 -0700 > > Subject:

Re: [PATCH v4] add stealth mode

Matteo Croce wrote: > Add option to disable any reply not related to a listening socket, > like RST/ACK for TCP and ICMP Port-Unreachable for UDP. > Also disables ICMP replies to echo request and timestamp. > The stealth mode can be enabled selectively for a single interface. I think it would

Re: [PATCH v4] add stealth mode

Matteo Croce wrote: > Add option to disable any reply not related to a listening socket, > like RST/ACK for TCP and ICMP Port-Unreachable for UDP. > Also disables ICMP replies to echo request and timestamp. > The stealth mode can be enabled selectively for a single interface.

Re: [PATCH] rhashtable-test: extend to test concurrency

Phil Sutter wrote: > After having tested insertion, lookup, table walk and removal, spawn a > number of threads running operations on the same rhashtable. Each of > them will: [..] > + if (down_interruptible(_sem)) > + pr_err(" thread[%d]: down_interruptible failed\n",

Re: [PATCH] rhashtable-test: extend to test concurrency

Phil Sutter p...@nwl.cc wrote: After having tested insertion, lookup, table walk and removal, spawn a number of threads running operations on the same rhashtable. Each of them will: [..] + if (down_interruptible(startup_sem)) + pr_err( thread[%d]: down_interruptible

Re: [PATCHv2 net-next 4/9] netfilter: connlabels: Export setting connlabel length

Joe Stringer wrote: > Add functions to change connlabel length into nf_conntrack_labels.c so > they may be reused by other modules like OVS and nftables without > needing to jump through xt_match_check() hoops. Looks good, thanks Joe. Acked-by: Florian Westphal -- To unsubscribe from

Re: [PATCHv2 net-next 4/9] netfilter: connlabels: Export setting connlabel length

Joe Stringer joestrin...@nicira.com wrote: Add functions to change connlabel length into nf_conntrack_labels.c so they may be reused by other modules like OVS and nftables without needing to jump through xt_match_check() hoops. Looks good, thanks Joe. Acked-by: Florian Westphal f...@strlen.de

Re: [PATCH net-next 8/9] openvswitch: Allow matching on conntrack label

Joe Stringer wrote: > Allow matching and setting the conntrack label field. As with ct_mark, > this is populated by executing the ct() action, and is a writable field. > The set_field() action may be used to modify the label, which will take > effect on the most recent conntrack entry. > > E.g.:

Re: [PATCH net-next 8/9] openvswitch: Allow matching on conntrack label

Joe Stringer joestrin...@nicira.com wrote: Allow matching and setting the conntrack label field. As with ct_mark, this is populated by executing the ct() action, and is a writable field. The set_field() action may be used to modify the label, which will take effect on the most recent conntrack

Re: nf_conntrack: falling back to vmalloc.

Toralf Förster wrote: > On 07/17/2015 12:10 PM, Florian Westphal wrote: > > Do you run containers? > > No, I just run 4 Gentoo chroot images in parallel - but I do that since > autumn last year. > > Unfortunately I cannot see any correlation to an os/sw upgrade or

Re: nf_conntrack: falling back to vmalloc.

Toralf Förster wrote: > I do run a server with a 64 bit hardened Gentoo Linux (kernel currently > 4.0.8). > Around 12th of July it started to spew those messages into kern.log : > > /var/log/kern.log:Jul 12 15:26:07 tor-relay kernel: [538360.650490] > nf_conntrack: falling back to vmalloc. >

Re: nf_conntrack: falling back to vmalloc.

Toralf Förster toralf.foers...@gmx.de wrote: On 07/17/2015 12:10 PM, Florian Westphal wrote: Do you run containers? No, I just run 4 Gentoo chroot images in parallel - but I do that since autumn last year. Unfortunately I cannot see any correlation to an os/sw upgrade or a config

Re: nf_conntrack: falling back to vmalloc.

Toralf Förster toralf.foers...@gmx.de wrote: I do run a server with a 64 bit hardened Gentoo Linux (kernel currently 4.0.8). Around 12th of July it started to spew those messages into kern.log : /var/log/kern.log:Jul 12 15:26:07 tor-relay kernel: [538360.650490] nf_conntrack: falling back

Re: [PATCH nf-next] netfilter: nf_ct_sctp: minimal multihoming support

Michal Kubecek wrote: > + case SCTP_CID_HEARTBEAT: > + pr_debug("SCTP_CID_HEARTBEAT"); > + i = 9; > + break; > + case SCTP_CID_HEARTBEAT_ACK: > + pr_debug("SCTP_CID_HEARTBEAT_ACK"); > + i = 10; > + break; >

Re: mmap()ed AF_NETLINK: lockdep and sleep-in-atomic warnings

Thomas Graf wrote: > On 07/13/15 at 10:11pm, Cong Wang wrote: > > Caused by: > > > > commit 21e4902aea80ef35afc00ee8d2abdea4f519b7f7 > > Author: Thomas Graf > > Date: Fri Jan 2 23:00:22 2015 +0100 > > > > netlink: Lockless lookup with RCU grace period in socket release > > > >

Re: mmap()ed AF_NETLINK: lockdep and sleep-in-atomic warnings

Thomas Graf tg...@suug.ch wrote: On 07/13/15 at 10:11pm, Cong Wang wrote: Caused by: commit 21e4902aea80ef35afc00ee8d2abdea4f519b7f7 Author: Thomas Graf tg...@suug.ch Date: Fri Jan 2 23:00:22 2015 +0100 netlink: Lockless lookup with RCU grace period in socket release

Re: [PATCH nf-next] netfilter: nf_ct_sctp: minimal multihoming support

Michal Kubecek mkube...@suse.cz wrote: + case SCTP_CID_HEARTBEAT: + pr_debug(SCTP_CID_HEARTBEAT); + i = 9; + break; + case SCTP_CID_HEARTBEAT_ACK: + pr_debug(SCTP_CID_HEARTBEAT_ACK); + i = 10; + break;

Re: [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6

Julien Grall wrote: > On 03/07/15 21:42, Florian Westphal wrote: > > I think it makes more sense to use __in6_dev_get() instead which doesn't > > take a reference. > > __in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on > this code is very limit

Re: [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6

Julien Grall julien.gr...@citrix.com wrote: On 03/07/15 21:42, Florian Westphal wrote: I think it makes more sense to use __in6_dev_get() instead which doesn't take a reference. __in6_dev_get requires to hold rcu_read_lock or RTNL. My knowledge on this code is very limited. Are we sure

Re: [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6

Julien Grall wrote: > The commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd "netfilter: bridge: > forward IPv6 fragmented packets" introduced a new function > br_validate_ipv6 which take a reference on the inet6 device. Although, > the reference is not released at the end. > > This will result to

Re: [PATCH] net/bridge: Add missing in6_dev_put in br_validate_ipv6

Julien Grall julien.gr...@citrix.com wrote: The commit efb6de9b4ba0092b2c55f6a52d16294a8a698edd netfilter: bridge: forward IPv6 fragmented packets introduced a new function br_validate_ipv6 which take a reference on the inet6 device. Although, the reference is not released at the end. This

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

Stephen Rothwell wrote: > After merging the net-next tree, today's linux-next build (i386 defconfig) > produced these warnings: > > In file included from include/net/netfilter/nf_conntrack_tuple.h:13:0, > from include/linux/netfilter/nf_conntrack_dccp.h:28, >

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

Stephen Rothwell s...@canb.auug.org.au wrote: After merging the net-next tree, today's linux-next build (i386 defconfig) produced these warnings: In file included from include/net/netfilter/nf_conntrack_tuple.h:13:0, from include/linux/netfilter/nf_conntrack_dccp.h:28,

Re: [PATCH] netfilter: fix dependency issues between IPv6 defragmentation and ip6tables

liusdu wrote: > On 2015年05月03日 19:07, Florian Westphal wrote: > >Liu Hua wrote: > >>commit f6318e558806c925029dc101f14874be9f9fa78f fix some related issue > >>when ip6tables is enabled. But when IP6_NF_IPTABLES is disabled and > >>NETFILTER_XT_TARGET_TPROXY is

Re: [PATCH] netfilter: fix dependency issues between IPv6 defragmentation and ip6tables

Liu Hua wrote: > commit f6318e558806c925029dc101f14874be9f9fa78f fix some related issue > when ip6tables is enabled. But when IP6_NF_IPTABLES is disabled and > NETFILTER_XT_TARGET_TPROXY is enabled. We will meet build failure with > "net/built-in.o: In function `tproxy_tg_init': >

Re: [PATCH] netfilter: fix dependency issues between IPv6 defragmentation and ip6tables

liusdu liu...@126.com wrote: On 2015年05月03日 19:07, Florian Westphal wrote: Liu Hua sdu@huawei.com wrote: commit f6318e558806c925029dc101f14874be9f9fa78f fix some related issue when ip6tables is enabled. But when IP6_NF_IPTABLES is disabled and NETFILTER_XT_TARGET_TPROXY is enabled. We

Re: [PATCH] netfilter: fix dependency issues between IPv6 defragmentation and ip6tables

Liu Hua sdu@huawei.com wrote: commit f6318e558806c925029dc101f14874be9f9fa78f fix some related issue when ip6tables is enabled. But when IP6_NF_IPTABLES is disabled and NETFILTER_XT_TARGET_TPROXY is enabled. We will meet build failure with net/built-in.o: In function `tproxy_tg_init':

[PATCH] can: use sock_efree instead of own destructor

It is identical to the can destructor. Signed-off-by: Florian Westphal --- include/linux/can/skb.h | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index cc00d15..b6a52a4 100644 --- a/include/linux/can/skb.h +++ b

[PATCH] can: use sock_efree instead of own destructor

It is identical to the can destructor. Signed-off-by: Florian Westphal f...@strlen.de --- include/linux/can/skb.h | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h index cc00d15..b6a52a4 100644 --- a/include/linux/can

Re: iptables problem upgrading kernel from 3.18.8 to 3.19.1

David R wrote: [ CC Pablo & stable@ ] > I've just had an exception to my "uneventful kernel upgrade" monotony. > > My boot scripts failed when setting up the firewall due to this :- > > xt_recent: hitcount (1) is larger than packets to be remembered (1) > for table > > This is a

Re: iptables problem upgrading kernel from 3.18.8 to 3.19.1

David R da...@unsolicited.net wrote: [ CC Pablo stable@ ] I've just had an exception to my uneventful kernel upgrade monotony. My boot scripts failed when setting up the firewall due to this :- xt_recent: hitcount (1) is larger than packets to be remembered (1) for table

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

Pablo Neira Ayuso wrote: > On Fri, Mar 06, 2015 at 11:34:29AM +0100, Imre Palik wrote: > > On 02/26/15 17:34, David Miller wrote: > > > From: Imre Palik > > > Date: Thu, 26 Feb 2015 11:19:25 +0100 > > > > > >> If you are looking for peculiarities in my setup then here they are: > > >> I am on

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

Pablo Neira Ayuso pa...@netfilter.org wrote: On Fri, Mar 06, 2015 at 11:34:29AM +0100, Imre Palik wrote: On 02/26/15 17:34, David Miller wrote: From: Imre Palik im...@amazon.de Date: Thu, 26 Feb 2015 11:19:25 +0100 If you are looking for peculiarities in my setup then here they

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

Imre Palik wrote: > The netfilter code is made with flexibility instead of performance in mind. > So when all we want is to pass packets between different interfaces, the > performance penalty of hitting netfilter code can be considerable, even when > all the firewalling is disabled for the

Re: [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

Imre Palik imrep@gmail.com wrote: The netfilter code is made with flexibility instead of performance in mind. So when all we want is to pass packets between different interfaces, the performance penalty of hitting netfilter code can be considerable, even when all the firewalling is

Re: 1e918876 breaks r8169 (linux-3.18+)

Eric Dumazet wrote: > On Sat, 2015-02-21 at 18:46 +0100, Florian Westphal wrote: > > Eric Dumazet wrote: > > > Hold on. > > > > > > I believe there is one race in the way you access skb->xmit_more _after_ > > > > > > txd->opts1 =

Re: 1e918876 breaks r8169 (linux-3.18+)

Eric Dumazet wrote: > Hold on. > > I believe there is one race in the way you access skb->xmit_more _after_ > > txd->opts1 = cpu_to_le32(status); > > After this point, TX might have completed and TX completion already have > freed skb Hmm, I _thought_ HW would not start xmit of this

Re: 1e918876 breaks r8169 (linux-3.18+)

Tomas Szepe wrote: > > I tried to reproduce this without success so far on my RTL8168d/8111d > > device. > > I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the > > last 5 hours and so far I saw no watchdog tx timeouts. > > > > I'll keep this running for a day or so to see if

Re: 1e918876 breaks r8169 (linux-3.18+)

Tomas Szepe sz...@pinerecords.com wrote: I tried to reproduce this without success so far on my RTL8168d/8111d device. I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the last 5 hours and so far I saw no watchdog tx timeouts. I'll keep this running for a day or so

Re: 1e918876 breaks r8169 (linux-3.18+)

Eric Dumazet eric.duma...@gmail.com wrote: On Sat, 2015-02-21 at 18:46 +0100, Florian Westphal wrote: Eric Dumazet eric.duma...@gmail.com wrote: Hold on. I believe there is one race in the way you access skb-xmit_more _after_ txd-opts1 = cpu_to_le32(status); After

Re: 1e918876 breaks r8169 (linux-3.18+)

Eric Dumazet eric.duma...@gmail.com wrote: Hold on. I believe there is one race in the way you access skb-xmit_more _after_ txd-opts1 = cpu_to_le32(status); After this point, TX might have completed and TX completion already have freed skb Hmm, I _thought_ HW would not start xmit of

Re: [PATCH] bridge: make it possible for packets to traverse the bridge withour hitting netfilter

Imre Palik wrote: > The trouble is that there are some bridges (with low traffic) where I need > netfilter, and some other bridges (carrying lots of traffic), where I don't. > Being able to set things up on a per bridge basis is a powerful thing. > > I only implemented the global switch

Re: [PATCH] bridge: make it possible for packets to traverse the bridge withour hitting netfilter

Imre Palik wrote: > On 02/11/15 23:29, David Miller wrote: > > If I apply this, someone is going to try to submit a patch for every > > damn protocol layer to add a stupid hack like this. > > Actually this is one of those patches. There is already a "stupid hack like > this" for iptables and

<    1   2   3   4   5   6   >