Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

于 2018年2月3日 GMT+08:00 上午6:13:01, Maxime Ripard 写到: >On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote: >> The V3s is just a differently packaged version of the V3 chip, which >has >> a MAC with the same capability with H3. The V3s just doesn't wire out >>

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

于 2018年2月3日 GMT+08:00 下午2:00:33, Julian Calaby 写到: >Hi Icenowy, > >On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng wrote: >> The V3s is just a differently packaged version of the V3 chip, which >has >> a MAC with the same capability with H3. The V3s just

Re: iproute2 4.14.1 tc class add come to kernel-panic

Hello, Hello, Well, not min_qdisc things, but it should be resolved by: commit efbf78973978b0d25af59bc26c8013a942af6e64 Author: Cong Wang Date: Mon Dec 4 10:48:18 2017 -0800 net_sched: get rid of rcu_barrier() in tcf_block_put_ext() Against what

[PATCH bpf] bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y

With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file, tools/testing/selftests/bpf/test_kmod.sh failed like below: [root@localhost bpf]# ./test_kmod.sh sysctl: setting key "net.core.bpf_jit_enable": Invalid argument [ JIT enabled:0 hardened:0 ] [ 132.175681] test_bpf: #297

Re: [linux-sunxi] [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

Hi Icenowy, On Sat, Feb 3, 2018 at 5:04 AM, Icenowy Zheng wrote: > The V3s is just a differently packaged version of the V3 chip, which has > a MAC with the same capability with H3. The V3s just doesn't wire out > the external MII/RMII/RGMII bus. (V3 wired out it). > > Drop the

Re: [PATCH] net: mlx5: remove pointless memcpy

On 02/02/2018 12:26 PM, Arnd Bergmann wrote: > On Fri, Feb 2, 2018 at 8:06 PM, Jason Gunthorpe wrote: >> On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote: >>> gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no >>> sense because the source and

pull-request: bpf 2018-02-02

Hi David, The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) support XDP attach in libbpf, from Eric. 2) minor fixes, from Daniel, Jakub, Yonghong, Alexei. Please consider pulling these changes from:

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

On Wed, Jan 31, 2018 at 05:53:13PM +0100, Daniel Borkmann wrote: > On 01/30/2018 09:50 PM, Eric Leblond wrote: > > Hello Daniel, > > > > No problem with the delay in the answer. I'm doing far worse. > > > > Here is an updated version: > > - add if_link.h in uapi and remove the definition > > -

RE: [PATCH] e1000e: allocate ring descriptors with dma_zalloc_coherent

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Pierre-Yves Kerbrat > Sent: Friday, January 26, 2018 2:24 AM > To: Kirsher, Jeffrey T ; intel-wired- > l...@lists.osuosl.org > Cc: netdev@vger.kernel.org; Marius Gligor

Re: RFC(V3): Audit Kernel Container IDs

On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote: > On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs wrote: > > Containers are a userspace concept. The kernel knows nothing of them. > > > > The Linux audit system needs a way to be able to track the container > >

Re: [PATCH bpf] bpf: fix bpf_prog_array_copy_to_user() issues

On 02/03/2018 12:14 AM, Alexei Starovoitov wrote: > 1. move copy_to_user out of rcu section to fix the following issue: > > ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side > critical section! > stack backtrace: > __dump_stack lib/dump_stack.c:17 [inline] >

Re: [RFC v2 00/14] Generic TCP-option framework and adoption for TCP-SMC and TCP-MD5

Hello, On 01/02/18 - 10:15:46, David Miller wrote: > From: Christoph Paasch > Date: Wed, 31 Jan 2018 16:07:02 -0800 > > > TCP-options like TCP_MD5 and SMC are rather rare use-cases, but their > > implementation is rather intrusive to the TCP-stack. Other, more recent > > TCP

[GIT] Networking

1) The bnx2x can hang if you give it a GSO packet with a segment size which is too big for the hardware, detect and drop in this case. From Daniel Axtens. 2) Fix some overflows and pointer leaks in xtables, from Dmitry Vyukov. 3) Missing RCU locking in igmp, from Eric Dumazet. 4) Fix

Re: [PATCH] igmp: fix unsafe RCU usage in igmpv3_src_addr

On Fri, 02 Feb 2018 14:18:45 -0800 Eric Dumazet wrote: > On Fri, 2018-02-02 at 13:30 -0800, Stephen Hemminger wrote: > > From: Stephen Hemminger > > > > New igmpv3_get_src_addr would sometimes be called in receive path > > without holding RCU

Re: [PATCH net] soreuseport: fix mem leak in reuseport_add_sock()

From: Eric Dumazet Date: Fri, 02 Feb 2018 10:27:27 -0800 > From: Eric Dumazet > > reuseport_add_sock() needs to deal with attaching a socket having > its own sk_reuseport_cb, after a prior > setsockopt(SO_ATTACH_REUSEPORT_?BPF) > > Without this

Re: [PATCH] net: qlge: use memmove instead of skb_copy_to_linear_data

From: Arnd Bergmann Date: Fri, 2 Feb 2018 16:45:44 +0100 > gcc-8 points out that the skb_copy_to_linear_data() argument points to > the skb itself, which makes it run into a problem with overlapping > memcpy arguments: > > In file included from include/linux/ip.h:20, >

Re: [PATCH] net: qed: use correct strncpy() size

From: Arnd Bergmann Date: Fri, 2 Feb 2018 16:44:47 +0100 > passing the strlen() of the source string as the destination > length is pointless, and gcc-8 now warns about it: > > drivers/net/ethernet/qlogic/qed/qed_debug.c: In function 'qed_grc_dump': > include/linux/string.h:253:

Re: [PATCH] net: cxgb4: avoid memcpy beyond end of source buffer

From: Arnd Bergmann Date: Fri, 2 Feb 2018 16:18:37 +0100 > Building with link-time-optimizations revealed that the cxgb4 driver does > a fixed-size memcpy() from a variable-length constant string into the > network interface name: > > In function 'memcpy', > inlined from

Re: [PATCH net 0/2] r8152: fix rx issues

From: Hayes Wang Date: Fri, 2 Feb 2018 16:43:34 +0800 > The two patched are used to fix rx issues. Series applied.

Re: [PATCH net] cls_u32: add missing RCU annotation.

From: Paolo Abeni Date: Fri, 2 Feb 2018 16:02:22 +0100 > In a couple of points of the control path, n->ht_down is currently > accessed without the required RCU annotation. The accesses are > safe, but sparse complaints. Since we already held the > rtnl lock, let use

Re: [PATCH net] nfp: fix TLV offset calculation

From: Jakub Kicinski Date: Thu, 1 Feb 2018 19:41:43 -0800 > From: Edwin Peer > > The data pointer in the config space TLV parser already includes > NFP_NET_CFG_TLV_BASE, it should not be added again. Incorrect > offset values were only

Re: INFO: task hung in bpf_exit_net

On Fri, Dec 22, 2017 at 05:04:37PM -0200, Marcelo Ricardo Leitner wrote: > On Fri, Dec 22, 2017 at 04:28:07PM -0200, Marcelo Ricardo Leitner wrote: > > On Fri, Dec 22, 2017 at 11:58:08AM +0100, Dmitry Vyukov wrote: > > ... > > > > Same with this one, perhaps related to / fixed by: > > > >

Re: [PATCH] ss: introduce switch to print exact value of data rates

On 2/1/18 7:19 AM, Tomasz Torcz wrote: > Introduce -X/--exact switch to disable human-friendly printing > of datarates. With the switch, data is not presented as MBps/Kbps. > > Signed-off-by: Tomasz Torcz > --- > misc/ss.c | 12 ++-- > 1 file changed, 10

Re: [RFC net 1/1] rtnetlink: require unique netns identifier

On 2/2/18 1:51 AM, Christian Brauner wrote: > diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c > index 56af8e41abfc..d0b7ab22eff4 100644 > --- a/net/core/rtnetlink.c > +++ b/net/core/rtnetlink.c > @@ -1951,6 +1951,18 @@ static struct net *rtnl_link_get_net_capable(const > struct sk_buff

RE: [PATCH] igb: Do not call netif_device_detach() when PCIe link goes missing

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Mika Westerberg > Sent: Tuesday, January 23, 2018 2:29 AM > To: Kirsher, Jeffrey T > Cc: Ferenc Boldog ; Nikolay Bogoychev > ; Mika

Re: RFC(V3): Audit Kernel Container IDs

On Fri, Feb 2, 2018 at 5:19 PM, Simo Sorce wrote: > On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote: >> On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs wrote: >> > On 2018-01-09 11:18, Simo Sorce wrote: >> > > On Tue, 2018-01-09 at 07:16 -0500, Richard

[PATCH bpf] bpf: fix bpf_prog_array_copy_to_user() issues

1. move copy_to_user out of rcu section to fix the following issue: ./include/linux/rcupdate.h:302 Illegal context switch in RCU read-side critical section! stack backtrace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 lockdep_rcu_suspicious+0x123/0x170

Re: [PATCH iproute2-next 0/3] ip: Minor code cleanups and improvements

On 1/31/18 1:15 AM, Serhey Popovych wrote: > With this series I want to do some adjustments in header files for ip(8) > as well as some trivial cleanups like variable rename and finally use > addattr_nest()/addattr_nest_end() family instead of open coding nested > attributes handling. > > See

Re: 88e6161 failed create slave phy

On Thu, Jan 25, 2018 at 09:15:16PM +0800, ?? wrote: > hello, I am compiling kernel for 88f6281 with 88e6161 switch for > 4.9.73.but the dsa does not work correctly.I think it is a bug > because 4.4 and 4.14 works fine. Sorry it has taken so long to get around to this. I've done some testing

[RFC bpf-next 2/2] bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID

test_stacktrace_build_id() is added. It accesses tracepoint urandom_read with "dd" and "urandom_read" and gathers stack traces. Then it reads the stack traces from the stackmap. urandom_read is a statically link binary that reads from /dev/urandom. test_stacktrace_build_id() calls readelf to read

[RFC bpf-next 1/2] bpf: extend stackmap to save binary_build_id+offset instead of address

Currently, bpf stackmap store address for each entry in the call trace. To map these addresses to user space files, it is necessary to maintain the mapping from these virtual address to symbols in the binary. Usually, the user space profiler (such as perf) has to scan /proc/pid/maps at the

[RFC bpf-next 0/2] stackmap with build_id+offset

This work follows up discussion at Plumbers'17 on improving addr->sym resolution of user stack traces. The following links have more information of the discussion: http://www.linuxplumbersconf.org/2017/ocw/proposals/4764 https://lwn.net/Articles/734453/ Section "Stack traces and kprobes"

Re: [RFC iproute2-next 00/16] iproute printing enhancements

On Thu, 1 Feb 2018 20:08:37 -0700 David Ahern wrote: > On 2/1/18 6:19 PM, Stephen Hemminger wrote: > > The first group of patches refactor the printout to breakup > > excessively long print_route function and the last few implement > > JSON and color output format for routes.

Re: RFC(V3): Audit Kernel Container IDs

On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote: > On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs wrote: > > On 2018-01-09 11:18, Simo Sorce wrote: > > > On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote: > > > > Containers are a userspace concept. The kernel

Re: [PATCH] igmp: fix unsafe RCU usage in igmpv3_src_addr

On Fri, 2018-02-02 at 13:30 -0800, Stephen Hemminger wrote: > From: Stephen Hemminger > > New igmpv3_get_src_addr would sometimes be called in receive path > without holding RCU lock. Strange, this should have been fixed already ?

Re: [PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

On Sat, Feb 03, 2018 at 02:04:54AM +0800, Icenowy Zheng wrote: > The V3s is just a differently packaged version of the V3 chip, which has > a MAC with the same capability with H3. The V3s just doesn't wire out > the external MII/RMII/RGMII bus. (V3 wired out it). > > Drop the compatible string of

CONTACT DHL OFFICE IMMEDIATELY FOR DELIVERY OF YOUR ATM MASTERCARD

Attention; Beneficiary, This is to official inform you that we have been having meetings for the past three (3) weeks which ended two days ago with MR. JIM YONG KIM the Former world bank president and other seven continent presidents on the congress we treated on solution to scam victim

Re: RFC(V3): Audit Kernel Container IDs

On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs wrote: > Containers are a userspace concept. The kernel knows nothing of them. > > The Linux audit system needs a way to be able to track the container > provenance of events and actions. Audit needs the kernel's help to do >

Re: [PATCH net] cls_u32: add missing RCU annotation.

On Fri, Feb 2, 2018 at 7:02 AM, Paolo Abeni wrote: > In a couple of points of the control path, n->ht_down is currently > accessed without the required RCU annotation. The accesses are > safe, but sparse complaints. Since we already held the > rtnl lock, let use

Re: INFO: trying to register non-static key in pfifo_fast_reset

On Sun, Dec 17, 2017 at 01:56:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 41d8c16909ebda40f7b4982a7f5e2ad102705ade > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: [PATCH net v2] cls_u32: fix use after free in u32_destroy_key()

On Fri, Feb 2, 2018 at 6:30 AM, Paolo Abeni wrote: > The problem is that the htnode is freed before the linked knodes and the > latter will try to access the first at u32_destroy_key() time. > This change addresses the issue using the htnode refcnt to guarantee > the correct

[PATCH] igmp: fix unsafe RCU usage in igmpv3_src_addr

From: Stephen Hemminger New igmpv3_get_src_addr would sometimes be called in receive path without holding RCU lock. [ 378.847402] = [ 378.847403] WARNING: suspicious RCU usage [ 378.847405] 4.15.0-net-next+ #1 Not tainted [ 378.847407]

Re: RFC(V3): Audit Kernel Container IDs

On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs wrote: > On 2018-01-09 11:18, Simo Sorce wrote: >> On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote: >> > Containers are a userspace concept. The kernel knows nothing of them. >> > >> > The Linux audit system needs a

Re: [Intel-wired-lan] Possible read-modify-write bug in ixgbe x550 phy setup

On 2/2/2018 1:08 PM, Tantilov, Emil S wrote: Just FYI - we looked at the reads and confirmed that there is no functional bug in the code because as it happens the CX1/SR bits is the only bits that are read and set and as such we don't lose any data. This of course means that the read is not

Re: [PATCH net] net: igmp: add a missing rcu locking section

Another path has same issue, currently testing this. From 92bf924c9eb7af1eade064583b9073baa03ec9f2 Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Fri, 2 Feb 2018 13:10:11 -0800 Subject: [PATCH] igmp: fix unsafe RCU usage in igmpv3_src_addr Running with lockdep

Re: RFC(V3): Audit Kernel Container IDs

On Tue, Jan 9, 2018 at 11:18 AM, Simo Sorce wrote: > On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote: ... >> Changelog: >> >> (Upstream V3) >> - switch back to u64 (from pmoore, can be expanded to u128 in future if >> need arises without breaking API. u32 was

RE: [Intel-wired-lan] Possible read-modify-write bug in ixgbe x550 phy setup

>-Original Message- >From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On >Behalf Of Tantilov, Emil S >Sent: Thursday, February 01, 2018 4:58 PM >To: Shannon Nelson >Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org >Subject: Re:

Mrs. Nnbeal Yack.

Good day, I will be glad if you will be capable to assist me to secure a sum of ($8.500.000.00 Million dollars) into your bank account for the benefit of both of us. This is a genuine transaction, it just that I can’t operate it alone without the help of a partner in other country. You will be

Re: [PATCH] net: mlx5: remove pointless memcpy

On Fri, Feb 2, 2018 at 8:06 PM, Jason Gunthorpe wrote: > On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote: >> gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no >> sense because the source and destination variables are identical: >> >>

[PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, Feb 02, 2018 at 11:34:56AM -0800, Eric Dumazet wrote: > On Fri, 2018-02-02 at 19:04 +, Roman Gushchin wrote: > > On Fri, Feb 02, 2018 at 10:39:04AM -0800, Eric Dumazet wrote: > > > On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > > > > > > > Idk, how even we can hit it?

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 19:04 +, Roman Gushchin wrote: > On Fri, Feb 02, 2018 at 10:39:04AM -0800, Eric Dumazet wrote: > > On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > > > > > Idk, how even we can hit it? And if so, what scary will happen? > > > > > > If you prefer to have it

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, Feb 02, 2018 at 10:39:04AM -0800, Eric Dumazet wrote: > On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > > > Idk, how even we can hit it? And if so, what scary will happen? > > > > If you prefer to have it there, I definitely can return it, > > but I see no profit so far. >

Re: [PATCH] net: mlx5: remove pointless memcpy

On Fri, Feb 02, 2018 at 04:46:30PM +0100, Arnd Bergmann wrote: > gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no > sense because the source and destination variables are identical: > > drivers/net/ethernet/mellanox/mlx5/core/transobj.c: In function > 'mlx5_core_query_xsrq': >

Re: regression in igb driver from commit 182785335447

- Original Message - > From: "Michal Kubecek" > Sent: Thursday, February 1, 2018 6:47:32 AM Michal, > one of my colleagues observed a regression in recent 4.4.x kernels on > one of test machines with 82575EB NIC (rev 02, 8086:10a7, firmware > version 1.6.5). On boot,

Re: [PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote: > I've got patches pending to replace all that code with > dma_direct_alloc, which will do the right thing. They were > submitted for 4.16, and I will resend them after -rc1. I see, thanks Christoph !

Re: [PATCH net] soreuseport: fix mem leak in reuseport_add_sock()

On Fri, Feb 2, 2018 at 1:27 PM, Eric Dumazet wrote: > From: Eric Dumazet > > reuseport_add_sock() needs to deal with attaching a socket having > its own sk_reuseport_cb, after a prior > setsockopt(SO_ATTACH_REUSEPORT_?BPF) > > Without this fix, not

Re: [PATCH] iommu/vt-d: add NUMA awareness to intel_alloc_coherent()

I've got patches pending to replace all that code with dma_direct_alloc, which will do the right thing. They were submitted for 4.16, and I will resend them after -rc1.

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 18:06 +, Roman Gushchin wrote: > > Idk, how even we can hit it? And if so, what scary will happen? > > If you prefer to have it there, I definitely can return it, > but I see no profit so far. I was simply curious this was not mentioned in the changelog. A revert is

[PATCH net] soreuseport: fix mem leak in reuseport_add_sock()

From: Eric Dumazet reuseport_add_sock() needs to deal with attaching a socket having its own sk_reuseport_cb, after a prior setsockopt(SO_ATTACH_REUSEPORT_?BPF) Without this fix, not only a WARN_ONCE() was issued, but we were also leaking memory. Thanks to sysbot and Eric

[PATCH 0/3] Allwinner V3s EMAC support

The Allwinner V3/V3s SoCs have EMAC similar to the one in H3, but on V3s the external MII is not exported due to packaging. (V3s is eLQFP128; the BGA-packaged V3 exported the external MII bus.) Add support for the EMAC on V3s. The external bus is not added yet, and will be added when adding

[PATCH 2/3] ARM: sun8i: v3s: add V3s EMAC device tree node

The V3/V3s EMAC is just similar to the one in H3 SoC, but as the package of V3s is pin-limited, the external MII/MDIO bus is not wired out. Add V3s EMAC device tree node. As V3s is only capable of using the internal PHY, it's hardcoded in the V3s DTSI file. Signed-off-by: Icenowy Zheng

[PATCH 1/3] net: stmmac: dwmac-sun8i: drop V3s compatible and add V3 one

The V3s is just a differently packaged version of the V3 chip, which has a MAC with the same capability with H3. The V3s just doesn't wire out the external MII/RMII/RGMII bus. (V3 wired out it). Drop the compatible string of V3s in the dwmac-sun8i driver, and add a V3 compatible string, which has

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, Feb 02, 2018 at 09:59:27AM -0800, Eric Dumazet wrote: > On Fri, 2018-02-02 at 16:57 +, Roman Gushchin wrote: > > This patch effectively reverts commit 9f1c2674b328 ("net: memcontrol: > > defer call to mem_cgroup_sk_alloc()"). > > > > Moving mem_cgroup_sk_alloc() to the

[PATCH 3/3] ARM: sun8i: v3s: enable Ethernet port on the Lichee Pi Zero Dock

The Lichee Pi Zero Dock has an Ethernet port connected to the internal PHY of the V3s SoC. Enable it in the device tree. Signed-off-by: Icenowy Zheng --- arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 8 1 file changed, 8 insertions(+) diff --git

Re: [PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

On Fri, 2018-02-02 at 16:57 +, Roman Gushchin wrote: > This patch effectively reverts commit 9f1c2674b328 ("net: memcontrol: > defer call to mem_cgroup_sk_alloc()"). > > Moving mem_cgroup_sk_alloc() to the inet_csk_accept() completely breaks > memcg socket memory accounting, as packets

Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server

On 02/02/2018 06:37 AM, Desnes Augusto Nunes do Rosário wrote: > Hello Tyrel, > > I concur with your observations, but since this patch has already been > merged, I'll address them in another patch. Fair enough. I didn't realize David had already merged it till after I sent my review. -Tyrel

Re: [PATCH net v2] cls_u32: fix use after free in u32_destroy_key()

On 2.2.2018 15:30, Paolo Abeni wrote: > Li Shuang reported an Oops with cls_u32 due to an use-after-free > in u32_destroy_key(). The use-after-free can be triggered with: > > dev=lo > tc qdisc add dev $dev root handle 1: htb default 10 > tc filter add dev $dev parent 1: prio 5 handle 1: protocol

[ANNOUNCE] nftables 0.8.2 release

Hi! The Netfilter project proudly presents: nftables 0.8.2 This release fixes ./configure --with-xtables that enables interaction between iptables-compat [1] and nft, and it also includes a bunch of documentation updates. This release introduces a new explicit option for interval sets,

[PATCH net] Revert "defer call to mem_cgroup_sk_alloc()"

This patch effectively reverts commit 9f1c2674b328 ("net: memcontrol: defer call to mem_cgroup_sk_alloc()"). Moving mem_cgroup_sk_alloc() to the inet_csk_accept() completely breaks memcg socket memory accounting, as packets received before memcg pointer initialization are not accounted and are

RE: [PATCH] net: cxgb4: avoid memcpy beyond end of source buffer

From: Arnd Bergmann > Sent: 02 February 2018 15:19 > > Building with link-time-optimizations revealed that the cxgb4 driver does > a fixed-size memcpy() from a variable-length constant string into the > network interface name: ... > I can see two equally workable solutions: either we use a

[PATCH] mac80211: remove redundant initialization to pointer 'hdr'

From: Colin Ian King The pointer hrd is being initialized with a value that is never read and re-assigned a little later, hence the initialization is redundant and can be removed. Cleans up clang warning: net/mac80211/tx.c:1924:24: warning: Value stored to 'hdr' during

Re: [PATCH net] netfilter: xt_hashlimit: do not allow empty names

On Fri, 2018-02-02 at 12:49 +0100, Pablo Neira Ayuso wrote: > @Eric, I can give it a shot here to this, just let me know. Thanks! Please go ahead Pablo ! Thanks.

[ANNOUNCE] iptables 1.6.2 release

Hi! The Netfilter project proudly presents: iptables 1.6.2 iptables is the userspace command line program used to configure the Linux 2.4.x and later packet filtering ruleset. It is targeted towards system administrators. This update contains accumulated bugfixes, a few new extensions

[PATCH] net: mlx5: remove pointless memcpy

gcc-8 notices that the memcpy in mlx5_core_query_xsrq() makes no sense because the source and destination variables are identical: drivers/net/ethernet/mellanox/mlx5/core/transobj.c: In function 'mlx5_core_query_xsrq': drivers/net/ethernet/mellanox/mlx5/core/transobj.c:347:3: error: 'memcpy'

[PATCH] net: qlge: use memmove instead of skb_copy_to_linear_data

gcc-8 points out that the skb_copy_to_linear_data() argument points to the skb itself, which makes it run into a problem with overlapping memcpy arguments: In file included from include/linux/ip.h:20, from drivers/net/ethernet/qlogic/qlge/qlge_main.c:26:

[PATCH] net: qed: use correct strncpy() size

passing the strlen() of the source string as the destination length is pointless, and gcc-8 now warns about it: drivers/net/ethernet/qlogic/qed/qed_debug.c: In function 'qed_grc_dump': include/linux/string.h:253: error: 'strncpy' specified bound depends on the length of the source argument

Re: [PATCH net-next 2/8] bpf: introduce BPF_PROG_QUERY command

On 2/2/18 6:28 AM, Eric Dumazet wrote: On Mon, 2017-10-02 at 16:48 -0700, Alexei Starovoitov wrote: introduce BPF_PROG_QUERY command to retrieve a set of either attached programs to given cgroup or a set of effective programs that will execute for events within a cgroup ... + +int

[PATCH] cfg80211: fix cfg80211_beacon_dup

gcc-8 warns about some obviously incorrect code: net/mac80211/cfg.c: In function 'cfg80211_beacon_dup': net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict] >From the context, I conclude that we want to copy from beacon into new_beacon, as we

[PATCH] net: cxgb4: avoid memcpy beyond end of source buffer

Building with link-time-optimizations revealed that the cxgb4 driver does a fixed-size memcpy() from a variable-length constant string into the network interface name: In function 'memcpy', inlined from 'cfg_queues_uld.constprop' at drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:335:2,

[PATCH net] cls_u32: add missing RCU annotation.

In a couple of points of the control path, n->ht_down is currently accessed without the required RCU annotation. The accesses are safe, but sparse complaints. Since we already held the rtnl lock, let use rtnl_dereference(). Fixes: a1b7c5fd7fe9 ("net: sched: add cls_u32 offload hooks for netdevs")

Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server

Hello Tyrel, I concur with your observations, but since this patch has already been merged, I'll address them in another patch. Thank you for your review, On 02/01/2018 07:02 PM, Tyrel Datwyler wrote: On 02/01/2018 10:04 AM, Desnes Augusto Nunes do Rosario wrote: Older versions of VIOS

Re: [PATCH, net] ibmvnic: fix firmware version when no firmware level has been provided by the VIOS server

Hello David, Thank you for your review and the heads up about protocol. On 02/01/2018 05:59 PM, David Miller wrote: From: Desnes Augusto Nunes do Rosario Date: Thu, 1 Feb 2018 16:04:30 -0200 Older versions of VIOS servers do not send the firmware level in the

[PATCH net v2] cls_u32: fix use after free in u32_destroy_key()

Li Shuang reported an Oops with cls_u32 due to an use-after-free in u32_destroy_key(). The use-after-free can be triggered with: dev=lo tc qdisc add dev $dev root handle 1: htb default 10 tc filter add dev $dev parent 1: prio 5 handle 1: protocol ip u32 divisor 256 tc filter add dev $dev protocol

Re: [PATCH net-next 2/8] bpf: introduce BPF_PROG_QUERY command

On Mon, 2017-10-02 at 16:48 -0700, Alexei Starovoitov wrote: > introduce BPF_PROG_QUERY command to retrieve a set of either > attached programs to given cgroup or a set of effective programs > that will execute for events within a cgroup > ... > + > +int bpf_prog_array_copy_to_user(struct

Re: [PATCH net] cls_u32: fix use after free in u32_destroy_key()

On Fri, 2018-02-02 at 14:20 +0100, Paolo Abeni wrote: > Li Shuang reported an Oops with cls_u32 due to an use-after-free > in u32_destroy_key(). The use-after-free can be triggered with: > > dev=lo > tc qdisc add dev $dev root handle 1: htb default 10 > tc filter add dev $dev parent 1: prio 5

Re: [PATCH iproute2-next 0/6] ip: Use netlink to walk through network device list

Serhey Popovych wrote: > In this seris I replace /proc/net/dev and /sys/class/net usage for walk > through network device list in iptunnel/ip6tunnel and iptuntap with > netlink dump. > > Following changed since RFC was sent: > > 1) Treat @struct rtnl_link_stats and @struct rtnl_link_stats64 as

[PATCH net] cls_u32: fix use after free in u32_destroy_key()

Li Shuang reported an Oops with cls_u32 due to an use-after-free in u32_destroy_key(). The use-after-free can be triggered with: dev=lo tc qdisc add dev $dev root handle 1: htb default 10 tc filter add dev $dev parent 1: prio 5 handle 1: protocol ip u32 divisor 256 tc filter add dev $dev protocol

[PATCH iproute2-next 5/6] iptunnel/ip6tunnel: Use netlink to walk through tunnels list

Both tunnels use legacy /proc/net/dev interface to get tunnel device and it's statistics. This may cause problems for cases when procfs either not mounted or not unshare(2)d for given network namespace. Use netlink to walk through list of tunnel devices which is network namespace aware and

[PATCH iproute2-next 1/6] ipaddress: Unify print_link_stats() and print_link_stats64()

To show real differences between these two variants adjust whitespace intendation and use print_uint() instead of print_int() as all members in both @struct rtnl_link_stats and @struct rtnl_link_stats64 are unsigned. Signed-off-by: Serhey Popovych --- ip/ipaddress.c |

[PATCH iproute2-next 0/6] ip: Use netlink to walk through network device list

In this seris I replace /proc/net/dev and /sys/class/net usage for walk through network device list in iptunnel/ip6tunnel and iptuntap with netlink dump. Following changed since RFC was sent: 1) Treat @struct rtnl_link_stats and @struct rtnl_link_stats64 as array with __u32 and __u64

[PATCH iproute2-next 6/6] tuntap: Use netlink to walk through tuntap list

It seems bad idea to depend on sysfs being mounted and reflected to the current network namespace. Same applies to procfs. Instead netlink should be used to talk to the kernel and get list of specific network devices among with their parameters. Support for kernel netlink message filtering by

[PATCH iproute2-next 2/6] ip: Introduce get_rtnl_link_stats_rta() to get link statistics

Assume all statistics in ip(8) represented either by IFLA_STATS64 or IFLA_STATS is 64 bit. It is clean that we can store __u32 counters of @struct rtnl_link_stats in __u64 counters in @struct rtnl_link_stats64. New get_rtnl_link_stats_rta() follows __print_link_stats() behaviour on handling of

[PATCH iproute2-next 3/6] tunnel: Split statistic getting and printing

This is first step to move tunnel code to use rtnl dump interface instead of /proc/net/dev read. Make tnl_print_stats() to accept @struct rtnl_link_stats64 parameter, introduce tnl_get_stats() that will parse line from /proc/net/dev into @struct rtnl_link_stats64. Signed-off-by: Serhey Popovych

[PATCH iproute2-next 4/6] iptunnel/ip6tunnel: Code cleanups

Use switch () instead of if () to compare tunnel type to fit into 80 columns and make code more readable. Print "\n" using fputc(). In iptunnel.c abstract tunnel parameters matching code in iptunnel.c into ip_tunnel_parm_match() helper to conform with ip6tunnel.c. In ip6tunnel.c no need to call

RE: [PATCH net-next] r8169: add module param for control of ASPM disable

> -Original Message- > From: Francois Romieu [mailto:rom...@fr.zoreil.com] > Sent: Friday, February 2, 2018 7:27 AM > To: Hau > Cc: netdev@vger.kernel.org; nic_swsd ; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH net-next] r8169: add module

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

On Thu, Feb 01, 2018 at 10:41:27PM +0200, Tommi Rantala wrote: > 2018-02-01 21:23 GMT+02:00 Neil Horman : > > No, I can't say I saw the patch on the list. Can you resend it? > > Here's the patch again, sending from gmail this time. > > The previous mail is now also at

Re: sctp netns "unregister_netdevice: waiting for lo to become free. Usage count = 1"

On 02.02.2018 11:27, Tommi Rantala wrote: > 2018-02-02 1:57 GMT+02:00 Alexey Kodanev : >> For ipv6 part, shouldn't we release 'bdst' there if the previous address >> match is better and we continue to the next iteration? > > Good catch! > On the second thought, I

Re: [PATCH net] netfilter: xt_hashlimit: do not allow empty names

On Fri, Feb 02, 2018 at 01:12:08PM +0100, Jan Engelhardt wrote: > On Friday 2018-02-02 12:55, Pablo Neira Ayuso wrote: > > >On Fri, Feb 02, 2018 at 12:49:38PM +0100, Pablo Neira Ayuso wrote: > >[...] > >> bool net_valid_name(const char *name, size_t len) > >> { > >> ... > >> } > > > >Am I

Re: [PATCH net] netfilter: xt_hashlimit: do not allow empty names

On Friday 2018-02-02 12:55, Pablo Neira Ayuso wrote: >On Fri, Feb 02, 2018 at 12:49:38PM +0100, Pablo Neira Ayuso wrote: >[...] >> bool net_valid_name(const char *name, size_t len) >> { >> ... >> } > >Am I missing anything in all these tricky string handling? Thanks! One will have to

Re: [Patch net] xt_cgroup: initialize info->priv in cgroup_mt_check_v1()

On Wed, Jan 31, 2018 at 03:02:47PM -0800, Cong Wang wrote: > xt_cgroup_info_v1->priv is an internal pointer only used for kernel, > we should not trust what user-space provides. Applied, thanks Cong.

  1   2   >