Re: [PATCHv4 net-next 2/2] openvswitch: add erspan version I and II support

On Thu, Jan 18, 2018 at 2:04 PM, William Tu wrote: > The patch adds support for openvswitch to configure erspan > v1 and v2. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr is added > to uapi as a nested attribute to support all ERSPAN v1 and v2's > fields. Note taht Previous

Re: [Patch net-next 1/3] net: introduce helper dev_change_tx_queue_len()

On 01/19/2018 03:09 PM, Cong Wang wrote: > This patch promotes the local change_tx_queue_len() to a core > helper function, dev_change_tx_queue_len(), so that rtnetlink > and net-sysfs could share the code. This also prepares for the > following patch. > > Note, the -EFAULT in the original code

Re: [PATCH net] net/mlx5e: Fix fixpoint divide exception in mlx5e_am_stats_compare

On 01/20/2018 12:10 AM, Sergei Shtylyov wrote: > Hello! > > On 1/19/2018 11:10 PM, Saeed Mahameed wrote: > >> From: Talat Batheesh >> >> Helmut reported a bug about devision by zero while > >    Division. > >> running traffic and doing physical cable pull test. >> >>

[PATCH net V2] net/mlx5e: Fix fixpoint divide exception in mlx5e_am_stats_compare

From: Talat Batheesh Helmut reported a bug about division by zero while running traffic and doing physical cable pull test. When the cable unplugged the ppms become zero, so when dividing the current ppms by the previous ppms in the next dim iteration there is division by

Re: pull-request: bpf-next 2018-01-19

From: Alexei Starovoitov Date: Fri, 19 Jan 2018 21:12:29 -0800 > The following pull-request contains BPF updates for your *net-next* tree. > > The main changes are: > > 1) bpf array map HW offload, from Jakub. > > 2) support for bpf_get_next_key() for LPM map, from Yonghong.

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

> I'm not familiar with MDIO bus but an alternative to GeneriSerialBus > would be to follow what SDIO is doing, e.g have the PHY devices listed > below the MDIO controller and use _ADR to describe their "address" on > that bus. You can see how _ADR applies to SDIO bus from ACPI spec. Hi Mika

Memory corruption with r8169 across several device revisions and kernels

Dear network experts, please redirect me if this is the wrong place. I have reproduced the following issue across three devices with different Realtek card revisions and different Distros (Debian 9, Ubuntu 17.04, Gentoo with kernels 4.9, 4.11.3, 4.14.12). It's safely reproducible with at

Re: net merged into net-next

On Fri, Jan 19, 2018 at 8:02 PM, David Miller wrote: > > Cong, please check my conflict resolution of drivers/net/tun.c, thank > you. It looks good to me except I am not sure about the xdp_rxq_info_unreg() inside tun_cleanup_tx_ring().

backport of "netfilter: nf_tables: fix mismatch in big-endian system" to stable

nftables does not work correctly on big endian systems without this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10596608c4d62cb8c1c2b806debcbd32fe657e71 With nftables v0.8.1 this rule does not work: nft add rule ip foo bar ct state new tcp dport 22

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

On Fri, Jan 19, 2018 at 07:07:29PM +0100, Marcin Wojtas wrote: > Hi Mika, Hi, > 2018-01-18 14:00 GMT+01:00 Andrew Lunn : > >> I CC'ed Mika since he is more familiar with handling these bits of ACPI > >> specs - I wonder whether this is a problem that cropped up on x86 > >>

Re: ipv6_addrconf: WARNING about suspicious RCU usage

Am 20.01.2018 um 20:19 schrieb Ido Schimmel: > On Sat, Jan 20, 2018 at 10:49:03AM -0800, Eric Dumazet wrote: >> On Sat, 2018-01-20 at 15:37 +0200, Ido Schimmel wrote: >>> On Sat, Jan 20, 2018 at 12:57:01PM +0100, Heiner Kallweit wrote: Since some time (didn't bisect it yet) I get the

Re: ipv6_addrconf: WARNING about suspicious RCU usage

On Sat, Jan 20, 2018 at 10:49:03AM -0800, Eric Dumazet wrote: > On Sat, 2018-01-20 at 15:37 +0200, Ido Schimmel wrote: > > On Sat, Jan 20, 2018 at 12:57:01PM +0100, Heiner Kallweit wrote: > > > Since some time (didn't bisect it yet) I get the following warning. > > > Is it a known issue? > > > >

Re: ipv6_addrconf: WARNING about suspicious RCU usage

On Sat, 2018-01-20 at 15:37 +0200, Ido Schimmel wrote: > On Sat, Jan 20, 2018 at 12:57:01PM +0100, Heiner Kallweit wrote: > > Since some time (didn't bisect it yet) I get the following warning. > > Is it a known issue? > > [...] > > > [86220.126999] BUG: sleeping function called from invalid

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

On Fri, Jan 19, 2018 at 2:55 PM, Benjamin Poirier wrote: > On 2018/01/20 07:45, Benjamin Poirier wrote: > [...] >> > >> > I'm of the mind that we need to cut down on the code thrash. This >> > driver is supposed to have been in a "maintenance" mode for the last >> >

Re: ipv6_addrconf: WARNING about suspicious RCU usage

On Sat, Jan 20, 2018 at 12:57:01PM +0100, Heiner Kallweit wrote: > Since some time (didn't bisect it yet) I get the following warning. > Is it a known issue? [...] > [86220.126999] BUG: sleeping function called from invalid context at > mm/slab.h:420 > [86220.127041] in_atomic(): 1,

Re: KASAN: use-after-free Read in fib6_ifup (2)

On Thu, Jan 18, 2018 at 09:58:01PM -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on net-next commit > 564737f981fb4b4b3266901508bb9b90d9d43de8 > > So far this crash happened 18 times on mmots, net-next. > C reproducer is attached. > syzkaller reproducer is attached. > Raw

ipv6_addrconf: WARNING about suspicious RCU usage

Since some time (didn't bisect it yet) I get the following warning. Is it a known issue? [86220.125562] = [86220.125586] WARNING: suspicious RCU usage [86220.125612] 4.15.0-rc7-next-20180110+ #7 Not tainted [86220.125641] - [86220.125666]

[net-next:master 308/357] gemini.c:undefined reference to `devm_ioremap_resource'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master head: 8565d26bcb2ff6df646e946d2913fcf706d46b66 commit: 4d5ae32f5e1e13f7f36d6439ec3257993b9f5b88 [308/357] net: ethernet: Add a driver for Gemini gigabit ethernet config: um-allyesconfig (attached as .config)

Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

Correct the composition Dear Arnd: 1. Setup an additional memory mapping for clock hardware in user space when establishing vdso-needed memory mapping In arch_setup_additional_pages(), kernel establishes memory mapping for vdso's text and vdata page in user space. In order to make clock

Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper

On Sat, Jan 20, 2018 at 2:54 AM, Jiri Pirko wrote: > Sat, Jan 20, 2018 at 11:33:31AM CET, jakub.kicin...@netronome.com wrote: >>On Sat, Jan 20, 2018 at 2:22 AM, Jiri Pirko wrote: >>> Sat, Jan 20, 2018 at 11:12:25AM CET, jakub.kicin...@netronome.com wrote:

Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

2018-01-18 19:08 GMT+08:00 Arnd Bergmann : > On Mon, Jan 15, 2018 at 6:57 AM, Greentime Hu wrote: >> From: Rick Chen >> >> VDSO needs real-time cycle count to ensure the time accuracy. >> Unlike others, nds32 architecture does not define

Hello dear

Hello dear My name is abudul Ahassan, I work with one of the leading Banks here in Africa. I have a business proposal worth 18$million dollars for more information contact me on my private email I urgently hope to get your response as soon as possible. Yours

Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper

Sat, Jan 20, 2018 at 11:33:31AM CET, jakub.kicin...@netronome.com wrote: >On Sat, Jan 20, 2018 at 2:22 AM, Jiri Pirko wrote: >> Sat, Jan 20, 2018 at 11:12:25AM CET, jakub.kicin...@netronome.com wrote: >>>net/sched/sch_prio.c: if (!tc_can_offload(dev) ||

Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper

On Sat, Jan 20, 2018 at 2:22 AM, Jiri Pirko wrote: > Sat, Jan 20, 2018 at 11:12:25AM CET, jakub.kicin...@netronome.com wrote: >>net/sched/sch_prio.c: if (!tc_can_offload(dev) || >>!dev->netdev_ops->ndo_setup_tc) >>net/sched/sch_prio.c: if (!tc_can_offload(dev) ||

Re: [PATCH net-next v4 5/8] net: sched: add extack support for offload via tc_cls_common_offload

On Sat, Jan 20, 2018 at 12:54 AM, Jiri Pirko wrote: > Sat, Jan 20, 2018 at 02:44:47AM CET, jakub.kicin...@netronome.com wrote: >>From: Quentin Monnet >> >>Add extack support for hardware offload of classifiers. In order >>to achieve this, a pointer

Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper

Sat, Jan 20, 2018 at 11:12:25AM CET, jakub.kicin...@netronome.com wrote: >On Sat, Jan 20, 2018 at 12:59 AM, Jiri Pirko wrote: >> Sat, Jan 20, 2018 at 02:44:48AM CET, jakub.kicin...@netronome.com wrote: >>>From: Quentin Monnet >>> >>>Create a

Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper

On Sat, Jan 20, 2018 at 12:59 AM, Jiri Pirko wrote: > Sat, Jan 20, 2018 at 02:44:48AM CET, jakub.kicin...@netronome.com wrote: >>From: Quentin Monnet >> >>Create a wrapper around tc_can_offload() that takes an additional >>extack pointer argument

[patch iproute2 net-next v12 1/3] tc: introduce tc_qdisc_block_exists helper

From: Jiri Pirko This hepler used qdisc dump to list all qdisc and find if block index in question is used by any of them. That means the block with specified index exists. Signed-off-by: Jiri Pirko --- v11->v12: - fixed return type of

[patch iproute2 net-next v12 0/3] tc: shared block support

From: Jiri Pirko Kernel allows to share all filters between qdiscs with use of shared block. Example: block number 22. "22" is just an identification: $ tc qdisc add dev ens7 ingress_block 22 ingress $ tc qdisc add dev ens8

[patch iproute2 net-next v12 3/3] tc: implement ingress/egress block index attributes for qdiscs

From: Jiri Pirko During qdisc creation it is possible to specify shared block for bot ingress and egress. Pass this values to kernel according to the command line options. Signed-off-by: Jiri Pirko --- man/man8/tc.8 | 6 +- tc/tc_qdisc.c | 36

[patch iproute2 net-next v12 2/3] tc: introduce support for block-handle for filter operations

From: Jiri Pirko So far, qdisc was the only handle that could be used to manipulate filters. Kernel added support for using block to manipulate it. So add the support to use block index to manipulate filters. The magic TCM_IFINDEX_MAGIC_BLOCK indicates the block index is in

Re: [patch iproute2 net-next v11 3/4] tc: introduce support for block-handle for filter operations

Fri, Jan 19, 2018 at 09:51:22PM CET, dsah...@gmail.com wrote: >On 1/17/18 2:48 AM, Jiri Pirko wrote: >> @@ -89,7 +93,21 @@ static int tc_filter_modify(int cmd, unsigned int flags, >> int argc, char **argv, >> NEXT_ARG(); >> if (d[0]) >>

Re: [patch iproute2 net-next v11 2/4] tc: introduce tc_qdisc_block_exists helper

Fri, Jan 19, 2018 at 09:45:57PM CET, dsah...@gmail.com wrote: >On 1/17/18 2:48 AM, Jiri Pirko wrote: >> From: Jiri Pirko >> >> This hepler used qdisc dump to list all qdisc and find if block index in >> question is used by any of them. That means the block with specified >>

Re: [PATCH net-next v4 6/8] net: sched: create tc_can_offload_extack() wrapper

Sat, Jan 20, 2018 at 02:44:48AM CET, jakub.kicin...@netronome.com wrote: >From: Quentin Monnet > >Create a wrapper around tc_can_offload() that takes an additional >extack pointer argument in order to output an error message if TC >offload is disabled on the device.

Re: [PATCH net-next v4 5/8] net: sched: add extack support for offload via tc_cls_common_offload

Sat, Jan 20, 2018 at 02:44:47AM CET, jakub.kicin...@netronome.com wrote: >From: Quentin Monnet > >Add extack support for hardware offload of classifiers. In order >to achieve this, a pointer to a struct netlink_ext_ack is added to the >struct tc_cls_common_offload

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

On 01/20/2018 03:27 AM, Alexei Starovoitov wrote: > On Sat, Jan 20, 2018 at 03:00:37AM +0100, Daniel Borkmann wrote: >> On 01/19/2018 12:43 AM, Eric Leblond wrote: >>> Hello, >>> >>> This patchset rebases the libbpf code on latest bpf-next code and addresses >>> remarks by Daniel. >> >> Ok, I

Re: [PATCH net] net/mlx5e: Fix fixpoint divide exception in mlx5e_am_stats_compare

Hello! On 1/19/2018 11:10 PM, Saeed Mahameed wrote: From: Talat Batheesh Helmut reported a bug about devision by zero while Division. running traffic and doing physical cable pull test. When the cable unplugged the ppms become zero, so when dividing the current