Re: [PATCH v3 00/10] New network driver for Amiga X-Surf 100 (m68k)

On Wed, Apr 18, 2018 at 05:10:45PM +1200, Michael Schmitz wrote: > All, > > just noticed belatedly that the Makefile hunk of patch 9 does no > longer apply cleanly in 4.17-rc1, sorry. My series was based on 4.16. > I'll resend that one, OK? Hi Michael You should be based on DaveM net-next tree:

Re: [RFC PATCH] net: bridge: multicast querier per VLAN support

On Wed, Apr 18, 2018 at 04:14:26PM +0300, Nikolay Aleksandrov wrote: > We want to avoid sysfs in general, all of networking config and stats > are moving to netlink. It is better controlled and structured for such > changes, also provides nice interfaces for automatic type checks etc. Aha,

Re: [PATCH RFC net-next 00/11] udp gso

On (04/18/18 06:35), Eric Dumazet wrote: > > There is no change at all. > > This will only be used as a mechanism to send X packets of same size. > > So instead of X system calls , one system call. > > One traversal of some expensive part of the host stack. > > The content on the wire should

Re: [PATCH net-next] team: account for oper state

On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote: > Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote: > >Account for operational state when determining port linkup state, > >as per Documentation/networking/operstates.txt. > > Could you please point me to the exact

Re: [PATCH bpf-next v4 07/10] bpf: btf: Add pretty print support to the basic arraymap

Hi Martin, first of all great work on the set! One issue that puzzled me while digesting it further below. On 04/17/2018 10:42 PM, Martin KaFai Lau wrote: > This patch adds pretty print support to the basic arraymap. > Support for other bpf maps can be added later. > > This patch adds new attrs

Re: [PATCH bpf-next v3 8/8] bpf: add documentation for eBPF helpers (58-64)

On Wed, 18 Apr 2018 15:09:41 +0100 Quentin Monnet wrote: > 2018-04-18 15:34 UTC+0200 ~ Jesper Dangaard Brouer > > On Tue, 17 Apr 2018 15:34:38 +0100 > > Quentin Monnet wrote: > > > >> diff --git

Re: [PATCH net-next 0/5] virtio-net: Add SCTP checksum offload support

On Tue, Apr 17, 2018 at 04:35:18PM -0400, Vlad Yasevich wrote: > On 04/02/2018 10:47 AM, Marcelo Ricardo Leitner wrote: > > On Mon, Apr 02, 2018 at 09:40:01AM -0400, Vladislav Yasevich wrote: > >> Now that we have SCTP offload capabilities in the kernel, we can add > >> them to virtio as well.

Re: [PATCH net-next] team: account for oper state

Wed, Apr 18, 2018 at 03:35:49PM CEST, gwil...@vyatta.att-mail.com wrote: >On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote: >> Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote: >> >Account for operational state when determining port linkup state, >> >as per

Re: [PATCH bpf-next v3 8/8] bpf: add documentation for eBPF helpers (58-64)

2018-04-18 15:34 UTC+0200 ~ Jesper Dangaard Brouer > On Tue, 17 Apr 2018 15:34:38 +0100 > Quentin Monnet wrote: > >> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >> index 350459c583de..3d329538498f 100644 >> ---

Re: SRIOV switchdev mode BoF minutes

On Tue, Apr 17, 2018 at 04:19:15PM -0700, Jakub Kicinski wrote: > On Tue, 17 Apr 2018 10:47:00 -0400, Andy Gospodarek wrote: > > There is also a school of thought that the VF reps could be > > pre-allocated on the SmartNIC so that any application processing that > > traffic would sit idle when no

[PATCH net-next 2/2] netns: isolate seqnums to use per-netns locks

Now that it's possible to have a different set of uevents in different network namespaces, per-network namespace uevent sequence numbers are introduced. This increases performance as locking is now restricted to the network namespace affected by the uevent rather than locking everything. Since

[PATCH net-next 1/2] netns: restrict uevents

commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") enabled sending hotplug events into all network namespaces back in 2010. Over time the set of uevents that get sent into all network namespaces has shrunk a little. We have now reached the point where hotplug events

[PATCH net-next 0/2] netns: uevent performance tweaks

Hey, This series deals with a bunch of performance improvements when sending out uevents that have been extensively discussed here: https://lkml.org/lkml/2018/4/10/592 - Only record uevent sockets from network namespaces owned by the initial user namespace in the global uevent socket list.

Re: [PATCH RFC net-next 00/11] udp gso

On Wed, Apr 18, 2018 at 9:59 AM, Willem de Bruijn wrote: >> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT >> just be automatically determined in the stack from the pmtu? Whats >> the motivation for the socket option for this? also AIUI

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

Rahul Lakkireddy writes: > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote: >> Hi Rahul, >> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote: >> > On production servers running variety of workloads over time, kernel >> > panic can happen

Re: [PATCH 1/6] rhashtable: remove outdated comments about grow_decision etc

On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote: > grow_decision and shink_decision no longer exist, so remove > the remaining references to them. > > Signed-off-by: NeilBrown Acked-by: Herbert Xu -- Email: Herbert Xu

Re: [PATCH 2/6] rhashtable: remove incorrect comment on r{hl, hash}table_walk_enter()

On Wed, Apr 18, 2018 at 04:47:01PM +1000, NeilBrown wrote: > Neither rhashtable_walk_enter() or rhltable_walk_enter() sleep, so > remove the comments which suggest that they do. > > Signed-off-by: NeilBrown > --- > include/linux/rhashtable.h |3 --- > lib/rhashtable.c

[PATCH] net: don't use kvzalloc for DMA memory

The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc fails (later patches change it to kvzalloc). The problem with this is that if the vzalloc function is actually used, virtio_net doesn't work (because it expects that the extra memory should be accessible with DMA-API and

Re: [PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

Pawel Dembicki writes: > This modem is embedded on dlink dwr-960 router. > The oem configuration states: > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 > D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=1435 ProdID=d191

Re: [PATCH net-next 2/2] openvswitch: Support conntrack zone limit

On 4/17/2018 5:30 PM, Yi-Hung Wei wrote: s/to commit/from committing/ s/entry/entries/ Thanks, will fix that in both patches in v2. I think this is a great idea but I suggest porting to the iproute2 package so everyone can use it. Then git rid of the OVS specific prefixes. Presuming of

Re: [PATCH net-next v4 0/3] kernel: add support to collect hardware logs in crash recovery kernel

On Wednesday, April 04/18/18, 2018 at 19:58:01 +0530, Eric W. Biederman wrote: > Rahul Lakkireddy writes: > > > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote: > >> Hi Rahul, > >> On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote: > >> > On

Re: [PATCH 6/6] rhashtable: add rhashtable_walk_prev()

On Wed, Apr 18, 2018 at 04:47:02PM +1000, NeilBrown wrote: > rhashtable_walk_prev() returns the object returned by > the previous rhashtable_walk_next(), providing it is still in the > table (or was during this grace period). > This works even if rhashtable_walk_stop() and rhashtable_talk_start()

Re: [PATCH RFC net-next 00/11] udp gso

On 4/18/2018 6:51 AM, Willem de Bruijn wrote: On Wed, Apr 18, 2018 at 9:47 AM, Sowmini Varadhan wrote: On (04/18/18 06:35), Eric Dumazet wrote: There is no change at all. This will only be used as a mechanism to send X packets of same size. So instead of X

Re: [PATCH net-next] team: account for oper state

On Wed, Apr 18, 2018 at 04:58:22PM +0200, Jiri Pirko wrote: > Wed, Apr 18, 2018 at 03:35:49PM CEST, gwil...@vyatta.att-mail.com wrote: > >On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote: > >> Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote: > >> >Account for

Re: [PATCH net-next] team: account for oper state

On Wed, Apr 18, 2018 at 04:33:12PM +0100, George Wilkie wrote: > On Wed, Apr 18, 2018 at 04:58:22PM +0200, Jiri Pirko wrote: > > Wed, Apr 18, 2018 at 03:35:49PM CEST, gwil...@vyatta.att-mail.com wrote: > > >On Wed, Apr 18, 2018 at 02:56:44PM +0200, Jiri Pirko wrote: > > >> Wed, Apr 18, 2018 at

Re: [PATCH bpf-next v2 03/11] bpf: make mlx4 compatible w/ bpf_xdp_adjust_tail

On 18/04/2018 7:29 AM, Nikita V. Shirokov wrote: w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as well (only "decrease" of pointer's location is going to be supported). changing of this pointer will change packet's size. for mlx4 driver we will just calculate packet's

Re: [PATCH bpf-next v2 00/11] introduction of bpf_xdp_adjust_tail

On 04/18/2018 06:29 AM, Nikita V. Shirokov wrote: > In this patch series i'm add new bpf helper which allow to manupulate > xdp's data_end pointer. right now only "shrinking" (reduce packet's size > by moving pointer) is supported (and i see no use case for "growing"). > Main use case for such

Re: [PATCH] samples/bpf: correct comment in sock_example.c

On 04/17/2018 04:25 AM, Wang Sheng-Hui wrote: > The program run against loopback interace "lo", not "eth0". > Correct the comment. > > Signed-off-by: Wang Sheng-Hui Applied to bpf-next, thanks Wang!

Re: [PATCH net-next] team: account for oper state

Wed, Apr 18, 2018 at 12:29:50PM CEST, gwil...@vyatta.att-mail.com wrote: >Account for operational state when determining port linkup state, >as per Documentation/networking/operstates.txt. Could you please point me to the exact place in the document where this is suggested? > >Signed-off-by:

Re: [Regression] net/phy/micrel.c v4.9.94

On Wed, Apr 18, 2018 at 09:34:16AM +0800, Chris Ruehl wrote: > Hello, > > I like to get your heads up at a regression introduced in 4.9.94 > commitment lead to a kernel ops and make the network unusable on my MX6DL > customized board. > > Race condition resume is called on startup and the phy

Re: [PATCH bpf-next v2 02/11] bpf: make generic xdp compatible w/ bpf_xdp_adjust_tail

On Wed, Apr 18, 2018 at 02:48:18PM +0200, Jesper Dangaard Brouer wrote: > On Tue, 17 Apr 2018 21:29:42 -0700 > "Nikita V. Shirokov" wrote: > > > w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as > > well (only "decrease" of pointer's location is going

[PATCH] net: caif: fix spelling mistake "UKNOWN" -> "UNKNOWN"

From: Colin Ian King Trivial fix to spelling mistake Signed-off-by: Colin Ian King --- net/caif/chnl_net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c index

Re: tcp hang when socket fills up ?

On Wed, 18 Apr 2018, Dominique Martinet wrote: > Jozsef Kadlecsik wrote on Wed, Apr 18, 2018: > > Thanks for the testing! One more line is required, however: we have to get > > the assured bit set for the connection, see the new patch below. > > I think it actually was better before. If I

[RFC PATCH] net: bridge: multicast querier per VLAN support

This RFC patch¹ is an attempt to add multicast querier per VLAN support to a VLAN aware bridge. I'm posting it as RFC for now since non-VLAN aware bridges are not handled, and one of my questions is if that is complexity we need to continue supporting? >From what I understand, multicast

Re: [PATCH net-next 3/3] net: phy: Enable C45 PHYs with vendor specific address space

On Wed, Apr 18, 2018 at 09:38:47AM +, Vicenţiu Galanopulo wrote: > > > > > Having dev-addr stored in devices_addrs, in get_phy_c45_ids(), when > > > probing the identifiers, dev-addr can be extracted from devices_addrs > > > and probed if devices_addrs[current_identifier] is not 0. > > > >

Re: [Regression] net/phy/micrel.c v4.9.94

On Wed, Apr 18, 2018 at 02:56:01PM +0200, Andrew Lunn wrote: > On Wed, Apr 18, 2018 at 09:34:16AM +0800, Chris Ruehl wrote: > > Hello, > > > > I like to get your heads up at a regression introduced in 4.9.94 > > commitment lead to a kernel ops and make the network unusable on my MX6DL > >

[PATCH bpf-next v3 10/11] bpf: adding tests for bpf_xdp_adjust_tail

adding selftests for bpf_xdp_adjust_tail helper. in this synthetic test we are testing that 1) if data_end < data helper will return EINVAL 2) for normal use case packet's length would be reduced. Signed-off-by: Nikita V. Shirokov --- tools/include/uapi/linux/bpf.h

[PATCH bpf-next v3 08/11] bpf: make virtio compatible w/ bpf_xdp_adjust_tail

w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as well (only "decrease" of pointer's location is going to be supported). changing of this pointer will change packet's size. for virtio driver we need to adjust XDP_PASS handling by recalculating length of the packet if it was

[PATCH bpf-next v3 11/11] bpf: add bpf_xdp_adjust_tail sample prog

adding bpf's sample program which is using bpf_xdp_adjust_tail helper by generating ICMPv4 "packet to big" message if ingress packet's size is bigger then 600 bytes Signed-off-by: Nikita V. Shirokov --- samples/bpf/Makefile | 4 +

[PATCH bpf-next v3 04/11] bpf: make bnxt compatible w/ bpf_xdp_adjust_tail

w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as well (only "decrease" of pointer's location is going to be supported). changing of this pointer will change packet's size. for bnxt driver we will just calculate packet's length unconditionally Acked-by: Alexei Starovoitov

[PATCH bpf-next v3 06/11] bpf: make netronome nfp compatible w/ bpf_xdp_adjust_tail

w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as well (only "decrease" of pointer's location is going to be supported). changing of this pointer will change packet's size. for nfp driver we will just calculate packet's length unconditionally Acked-by: Alexei Starovoitov

[PATCH bpf-next v3 01/11] bpf: adding bpf_xdp_adjust_tail helper

Adding new bpf helper which would allow us to manipulate xdp's data_end pointer, and allow us to reduce packet's size indended use case: to generate ICMP messages from XDP context, where such message would contain truncated original packet. Signed-off-by: Nikita V. Shirokov

[PATCH bpf-next v3 00/11] introduction of bpf_xdp_adjust_tail

In this patch series i'm add new bpf helper which allow to manupulate xdp's data_end pointer. right now only "shrinking" (reduce packet's size by moving pointer) is supported (and i see no use case for "growing"). Main use case for such helper is to be able to generate controll (ICMP) messages

[PATCH bpf-next v3 03/11] bpf: make mlx4 compatible w/ bpf_xdp_adjust_tail

w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as well (only "decrease" of pointer's location is going to be supported). changing of this pointer will change packet's size. for mlx4 driver we will just calculate packet's length unconditionally (the same way as it's already

[PATCH bpf-next v3 07/11] bpf: make tun compatible w/ bpf_xdp_adjust_tail

w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as well (only "decrease" of pointer's location is going to be supported). changing of this pointer will change packet's size. for tun driver we need to adjust XDP_PASS handling by recalculating length of the packet if it was

Re: [PATCH RFC net-next 00/11] udp gso

> One thing that was not clear to me about the API: shouldn't UDP_SEGMENT > just be automatically determined in the stack from the pmtu? Whats > the motivation for the socket option for this? also AIUI this can be > either a per-socket or a per-packet option? I decided to let the application

Re: [PATCH RFC net-next 00/11] udp gso

On Tue, 2018-04-17 at 16:00 -0400, Willem de Bruijn wrote: > From: Willem de Bruijn > > Segmentation offload reduces cycles/byte for large packets by > amortizing the cost of protocol stack traversal. > > This patchset implements GSO for UDP. A process can concatenate and >

[PATCH] rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN

From: Colin Ian King Rename several macros that contain mispellings of UNKNOWN Signed-off-by: Colin Ian King --- drivers/net/wireless/ralink/rt2x00/rt2800.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git

Re: [PATCH] rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN

On Wed, Apr 18, 2018 at 12:47:50PM +0100, Colin King wrote: > From: Colin Ian King > > Rename several macros that contain mispellings of UNKNOWN > > Signed-off-by: Colin Ian King Acked-by: Stanislaw Gruszka

Re: [PATCH v3 1/9] net: phy: new Asix Electronics PHY driver

> + > +/** > + * asix_soft_reset - software reset the PHY via BMCR_RESET bit > + * @phydev: target phy_device struct > + * > + * Description: Perform a software PHY reset using the standard > + * BMCR_RESET bit and poll for the reset bit to be cleared. > + * Toggle BMCR_RESET bit off to accomodate

Re: [PATCH RFC net-next 00/11] udp gso

On 04/18/2018 05:31 AM, Sowmini Varadhan wrote: > > I went through the patch set and the code looks fine- it extends existing > infra for TCP/GSO to UDP. > > One thing that was not clear to me about the API: shouldn't UDP_SEGMENT > just be automatically determined in the stack from the pmtu?

Re:Re: [PATCH v3] net: davicom: dm9000: Avoid spinlock recursion during dm9000_timeout routine

Hi, Because the timeout task gets the main spinlock and disable the current cpu's irq, there is no other task on the same cpu can run, and tasks on the other cpus can not enter the dm9000_timeout() again. So in the whole dm9000_timeout() routine, db->timeout_cpu can not be changed by other

Re: [PATCH RFC net-next 00/11] udp gso

On Wed, Apr 18, 2018 at 9:47 AM, Sowmini Varadhan wrote: > On (04/18/18 06:35), Eric Dumazet wrote: >> >> There is no change at all. >> >> This will only be used as a mechanism to send X packets of same size. >> >> So instead of X system calls , one system call. >> >>

Re: tcp hang when socket fills up ?

On Wed, 18 Apr 2018, Dominique Martinet wrote: > Dominique Martinet wrote on Wed, Apr 18, 2018: > > Jozsef Kadlecsik wrote on Wed, Apr 18, 2018: > > > Yes, the state transition is wrong for simultaneous open, because the > > > tcp_conntracks table is not (cannot be) smart enough. Could you

Re: Fw: [Bug 199429] New: smc_shutdown(net/smc/af_smc.c) has a UAF causing null pointer vulnerability.

On 04/18/2018 04:56 AM, Stephen Hemminger wrote: > This may already be fixed. > > Begin forwarded message: > > Date: Wed, 18 Apr 2018 01:52:59 + > From: bugzilla-dae...@bugzilla.kernel.org > To: step...@networkplumber.org > Subject: [Bug 199429] New: smc_shutdown(net/smc/af_smc.c) has a

Re: [Regression] net/phy/micrel.c v4.9.94

> If I look at the patch I think it should call kszphy_config_init() not > _reset() > in the resume function: > > > @@ -715,8 +723,14 @@ static int kszphy_suspend(struct phy_device *phydev) > > static int kszphy_resume(struct phy_device *phydev) > { > + int ret; > + >

Re: [PATCH v2 bpf-next 0/3] Add missing types to bpftool, libbpf

On 04/17/2018 07:28 PM, Andrey Ignatov wrote: > v1->v2: > - add new types to bpftool-cgroup man page; > - add new types to bash completion for bpftool; > - don't add types that should not be in bpftool cgroup. > > Add support for various BPF prog types and attach types that have been > added to

Re: [bpf-next PATCH] samples/bpf: fix xdp_monitor user output for tracepoint exception

On 04/17/2018 04:08 PM, Jesper Dangaard Brouer wrote: > The variable rec_i contains an XDP action code not an error. > Thus, using err2str() was wrong, it should have been action2str(). > > Signed-off-by: Jesper Dangaard Brouer Applied to bpf-next, thanks Jesper!

Re: [PATCH bpf-next v2 02/11] bpf: make generic xdp compatible w/ bpf_xdp_adjust_tail

On Tue, 17 Apr 2018 21:29:42 -0700 "Nikita V. Shirokov" wrote: > w/ bpf_xdp_adjust_tail helper xdp's data_end pointer could be changed as > well (only "decrease" of pointer's location is going to be supported). > changing of this pointer will change packet's size. > for

Re: [RFC PATCH] net: bridge: multicast querier per VLAN support

On Wed, Apr 18, 2018 at 03:31:57PM +0300, Nikolay Aleksandrov wrote: > On 18/04/18 15:07, Joachim Nilsson wrote: > > - First of all, is this patch useful to anyone > Obviously to us as it's based on our patch. :-) > We actually recently discussed what will be needed to make it acceptable to >

Reply

Dear Shaohui, I plead an indulgence if I have invaded your privacy by receiving this mail from me without prior permission.With due respect,I contact you purposely based on the similarities of names between you and my deceased client who was an oil servicing contractor with shell petroleum in West

[PATCHv2 1/1] net/mlx4_core: avoid resetting HCA when accessing an offline device

While a faulty cable is used or HCA firmware error, HCA device will be offline. When the driver is accessing this offline device, the following call trace will pop out. " ... [] dump_stack+0x63/0x81 [] panic+0xcc/0x21b [] mlx4_enter_error_state+0xba/0xf0 [mlx4_core] []

Re: [PATCH bpf-next v3 8/8] bpf: add documentation for eBPF helpers (58-64)

On Tue, 17 Apr 2018 15:34:38 +0100 Quentin Monnet wrote: > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index 350459c583de..3d329538498f 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -1276,6 +1276,50 @@ union

Re: [PATCH RFC net-next 00/11] udp gso

numbers seen from TCP without TSO and GSO. That also has few system calls, but observes per MTU stack traversal. I pushed the branch to my github at https://github.com/wdebruij/linux/tree/udpgso-20180418 and also the version I sent for RFC yesterday at https://github.com/wdebruij/linux/tree/udpgso-rfc-v1

Re: [PATCH bpf-next 2/9] bpf: add bpf_get_stack helper

Hi Yonghong, Thank you for the patch! Yet something to improve: [auto build test ERROR on bpf-next/master] url: https://github.com/0day-ci/linux/commits/Yonghong-Song/bpf-add-bpf_get_stack-helper/20180418-210810 base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master

[RFC net-next PATCH 0/2] bpf: followup avoid leaking info stored in frame data on page reuse

This is a followup to fix commit: 6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on page reuse") Posting as RFC, as I want Daniel to review this before it goes in, as Daniel usually have smarter/brighter ideas of howto solve this in a more optimal manor? --- Jesper Dangaard Brouer

[RFC net-next PATCH 1/2] bpf: avoid clear xdp_frame area again

Avoid clearing xdp_frame area if this was already done by prevous invocations of bpf_xdp_adjust_head. The xdp_adjust_head helper can be called multiple times by the bpf_prog. If increasing the packet header size (with a negative offset), kernel must assume bpf_prog store valuable information

[RFC net-next PATCH 2/2] bpf: disallow XDP data_meta to overlap with xdp_frame area

If combining xdp_adjust_head and xdp_adjust_meta, then it is possible to make data_meta overlap with area used by xdp_frame. And another invocation of xdp_adjust_head can then clear that area, due to clearing of xdp_frame area. The easiest solution I found was to simply not allow

[PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

This modem is embedded on dlink dwr-960 router. The oem configuration states: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1435 ProdID=d191 Rev=ff.ff S: Manufacturer=Android S: Product=Android S:

Re: [PATCH 1/2] net: netsec: enable tx-irq during open callback

Hi Dave, On Mon, Apr 16, 2018 at 11:16 PM, David Miller wrote: > From: jassisinghb...@gmail.com > Date: Mon, 16 Apr 2018 12:52:16 +0530 > >> From: Jassi Brar >> >> Enable TX-irq as well during ndo_open() as we can not count upon >> RX to arrive

[PATCH v2 2/3] lan78xx: Read LED states from Device Tree

Add support for DT property "microchip,led-modes", a vector of zero to four cells (u32s) in the range 0-15, each of which sets the mode for one of the LEDs. Some possible values are: 0=link/activity 1=link1000/activity 2=link100/activity 3=link10/activity

[bpf-next PATCH 3/3] bpf: add sample program to trace map events

This patch adds a sample program, called trace_map_events, that shows how to capture map events and filter them based on the map id. The program accepts a list of map IDs, via the -i command line option, and filters all the map events related to those IDs (i.e.,

Re: [PATCH net-next 2/2] udp: implement and use per cpu rx skbs cache

On 04/18/2018 03:22 AM, Paolo Abeni wrote: > This changeset extends the idea behind commit c8c8b127091b ("udp: > under rx pressure, try to condense skbs"), trading more BH cpu > time and memory bandwidth to decrease the load on the user space > receiver. > > At boot time we allocate a limited

Re: [PATCH bpf-next v2 01/11] bpf: adding bpf_xdp_adjust_tail helper

On Tue, Apr 17, 2018 at 09:29:41PM -0700, Nikita V. Shirokov wrote: > Adding new bpf helper which would allow us to manipulate > xdp's data_end pointer, and allow us to reduce packet's size > indended use case: to generate ICMP messages from XDP context, > where such message would contain

Re: [PATCH bpf-next v3 01/11] bpf: adding bpf_xdp_adjust_tail helper

On Tue, Apr 17, 2018 at 09:42:13PM -0700, Nikita V. Shirokov wrote: > Adding new bpf helper which would allow us to manipulate > xdp's data_end pointer, and allow us to reduce packet's size > indended use case: to generate ICMP messages from XDP context, > where such message would contain

Re: [PATCH 1/2] net: netsec: enable tx-irq during open callback

From: Jassi Brar Date: Wed, 18 Apr 2018 18:27:59 +0530 > Just to make sure, let me please mention that c009f413b79de52 and > 9a00b697ce31e are very much needed in stable kernel. Without these we > couldn't install any OS over network. Ok, both patches in this series

Re: [net 1/1] tipc: fix infinite loop when dumping link monitor summary

From: Jon Maloy Date: Tue, 17 Apr 2018 21:58:27 +0200 > From: Tung Nguyen > > When configuring the number of used bearers to MAX_BEARER and issuing > command "tipc link monitor summary", the command enters infinite loop > in user space. >

Re: [net 1/1] tipc: fix use-after-free in tipc_nametbl_stop

From: Jon Maloy Date: Tue, 17 Apr 2018 21:25:42 +0200 > When we delete a service item in tipc_nametbl_stop() we loop over > all service ranges in the service's RB tree, and for each service > range we loop over its pertaining publications while calling >

[PATCH bpf] tools/bpf: fix test_sock and test_sock_addr.sh failure

The bpf selftests test_sock and test_sock_addr.sh failed in my test machine. The failure looks like: $ ./test_sock Test case: bind4 load with invalid access: src_ip6 .. [PASS] Test case: bind4 load with invalid access: mark .. [PASS] Test case: bind6 load with invalid access:

Re: [Bug 199429] New: smc_shutdown(net/smc/af_smc.c) has a UAF causing null pointer vulnerability.

On Wed, 18 Apr 2018 13:46:20 +0200 Ursula Braun wrote: > On 04/18/2018 04:56 AM, Stephen Hemminger wrote: > > This may already be fixed. > > > > Begin forwarded message: > > > > Date: Wed, 18 Apr 2018 01:52:59 + > > From: bugzilla-dae...@bugzilla.kernel.org > > To:

Re: [PATCH] net: don't use kvzalloc for DMA memory

On Wed, 18 Apr 2018, Eric Dumazet wrote: > > > On 04/18/2018 07:34 AM, Mikulas Patocka wrote: > > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > > fails (later patches change it to kvzalloc). > > > > The problem with this is that if the vzalloc function is

Re: [net PATCH v2] net: sched, fix OOO packets with pfifo_fast

On 04/18/2018 12:28 AM, Paolo Abeni wrote: > Hi, > > let me revive this old thread... > > On Mon, 2018-03-26 at 11:16 -0700, John Fastabend wrote: >> On 03/26/2018 10:30 AM, Cong Wang wrote: >>> On Sat, Mar 24, 2018 at 10:25 PM, John Fastabend >>> wrote: After the

[PATCH bpf-next v2 9/9] tools/bpf: add a test_progs test case for bpf_get_stack helper

The test_stacktrace_map is enhanced to call bpf_get_stack in the helper to get the stack trace as well. The stack traces from bpf_get_stack and bpf_get_stackid are compared to ensure that for the same stack as represented as the same hash, their ip addresses must be the same. Signed-off-by:

[PATCH bpf-next v2 7/9] samples/bpf: add a test for bpf_get_stack helper

The test attached a kprobe program to kernel function sys_write. It tested to get stack for user space, kernel space and user space with build_id request. It also tested to get user and kernel stack into the same buffer with back-to-back bpf_get_stack helper calls. Whenever the kernel stack is

[PATCH bpf-next v2 5/9] tools/bpf: add bpf_get_stack helper to tools headers

Signed-off-by: Yonghong Song --- tools/include/uapi/linux/bpf.h| 19 +-- tools/testing/selftests/bpf/bpf_helpers.h | 2 ++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h

[PATCH bpf-next v2 1/9] bpf: change prototype for stack_map_get_build_id_offset

This patch didn't incur functionality change. The function prototype got changed so that the same function can be reused later. Signed-off-by: Yonghong Song --- kernel/bpf/stackmap.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git

[PATCH bpf-next v2 3/9] bpf/verifier: refine retval R0 state for bpf_get_stack helper

The special property of return values for helpers bpf_get_stack and bpf_probe_read_str are captured in verifier. Both helpers return a negative error code or a length, which is equal to or smaller than the buffer size argument. This additional information in the verifier can avoid the condition

[PATCH bpf-next v2 0/9] bpf: add bpf_get_stack helper

Currently, stackmap and bpf_get_stackid helper are provided for bpf program to get the stack trace. This approach has a limitation though. If two stack traces have the same hash, only one will get stored in the stackmap table regardless of whether BPF_F_REUSE_STACKID is specified or not, so some

[PATCH bpf-next v2 4/9] bpf/verifier: improve register value range tracking with ARSH

When helpers like bpf_get_stack returns an int value and later on used for arithmetic computation, the LSH and ARSH operations are often required to get proper sign extension into 64-bit. For example, without this patch: 54: R0=inv(id=0,umax_value=800) 54: (bf) r8 = r0 55:

[PATCH bpf-next v2 8/9] tools/bpf: add a verifier test case for bpf_get_stack helper and ARSH

The test_verifier already has a few ARSH test cases. This patch adds a new test case which takes advantage of newly improved verifier behavior for bpf_get_stack and ARSH. Signed-off-by: Yonghong Song --- tools/testing/selftests/bpf/test_verifier.c | 45 +

Re: [PATCH bpf-next v4 07/10] bpf: btf: Add pretty print support to the basic arraymap

On Wed, 18 Apr 2018 17:20:11 +0200, Daniel Borkmann wrote: > Hi Martin, > > first of all great work on the set! One issue that puzzled me > while digesting it further below. > > On 04/17/2018 10:42 PM, Martin KaFai Lau wrote: > > This patch adds pretty print support to the basic arraymap. > >

Re: [PATCH net-next v2 16/21] net/ipv6: Add gfp_flags to route add functions

On 4/18/18 11:06 AM, Eric Dumazet wrote: > > > On 04/17/2018 05:33 PM, David Ahern wrote: >> Most FIB entries can be added using memory allocated with GFP_KERNEL. >> Add gfp_flags to ip6_route_add and addrconf_dst_alloc. Code paths that >> can be reached from the packet path (e.g., ndisc and

Re: [PATCH RFC net-next 00/11] udp gso

From: Paolo Abeni Date: Wed, 18 Apr 2018 13:17:54 +0200 > When testing with Spectre/Meltdown mitigation in places, I expect > that the most relevant part of the gain is due to the single syscall > per burst. I was going to say exactly this. Batching schemes that were

Re: SRIOV switchdev mode BoF minutes

On Wed, Apr 18, 2018 at 09:26:34AM -0700, Jakub Kicinski wrote: > On Wed, 18 Apr 2018 11:15:29 -0400, Andy Gospodarek wrote: > > > A similar issue exists on multi-host for PFs, right? If one of the > > > hosts is down do we still show their PF repr? IMHO yes. > > > > I would agree with that

Re: [PATCH net-next v2 16/21] net/ipv6: Add gfp_flags to route add functions

On 04/18/2018 10:10 AM, David Ahern wrote: > On 4/18/18 11:06 AM, Eric Dumazet wrote: >> >> >> On 04/17/2018 05:33 PM, David Ahern wrote: >>> Most FIB entries can be added using memory allocated with GFP_KERNEL. >>> Add gfp_flags to ip6_route_add and addrconf_dst_alloc. Code paths that >>> can

Re: [PATCH iproute2 net-next] vxlan: fix ttl inherit behavior

On Wed, 18 Apr 2018 13:10:49 +0800 Hangbin Liu wrote: > Hi Stephen, > > The patch's subject contains fix. But the kernel feature is applied on > net-next. > So I'm not sure if iproute2 net-next is suitable. If you are OK with the > patch, > please feel free to apply it

Re: [PATCH] net: don't use kvzalloc for DMA memory

On 04/18/2018 07:34 AM, Mikulas Patocka wrote: > The patch 74d332c13b21 changes alloc_netdev_mqs to use vzalloc if kzalloc > fails (later patches change it to kvzalloc). > > The problem with this is that if the vzalloc function is actually used, > virtio_net doesn't work (because it expects

Re: [RFC net-next PATCH 2/2] bpf: disallow XDP data_meta to overlap with xdp_frame area

On 04/18/2018 02:10 PM, Jesper Dangaard Brouer wrote: > If combining xdp_adjust_head and xdp_adjust_meta, then it is possible > to make data_meta overlap with area used by xdp_frame. And another > invocation of xdp_adjust_head can then clear that area, due to > clearing of xdp_frame area. > >

Re: [RFC PATCH] net: bridge: multicast querier per VLAN support

On April 18, 2018 6:54:07 PM GMT+03:00, Stephen Hemminger wrote: >On Wed, 18 Apr 2018 16:14:26 +0300 >Nikolay Aleksandrov wrote: > >> On 18/04/18 16:07, Joachim Nilsson wrote: >> > On Wed, Apr 18, 2018 at 03:31:57PM +0300, Nikolay

Re: SRIOV switchdev mode BoF minutes

On Wed, 18 Apr 2018 11:15:29 -0400, Andy Gospodarek wrote: > > A similar issue exists on multi-host for PFs, right? If one of the > > hosts is down do we still show their PF repr? IMHO yes. > > I would agree with that as well. With today's model the VF reps are > created once a PF is put

  1   2   3   4   >