Re: [PATCH] bpf: hide a possibly unused variable

On Tue, Feb 20, 2018 at 10:44 PM, Daniel Borkmann wrote: > Hi Arnd, > > On 02/20/2018 10:16 PM, Arnd Bergmann wrote: >> The only user of this variable is inside of an #ifdef, causing >> a warning without CONFIG_INET: >> >> net/core/filter.c: In function

[PATCH] bpf: clean up unused-variable warning

The only user of this variable is inside of an #ifdef, causing a warning without CONFIG_INET: net/core/filter.c: In function 'bpf_sock_ops_cb_flags_set': net/core/filter.c:3382:6: error: unused variable 'val' [-Werror=unused-variable] int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS; This

Re: [PATCH iproute2] ip: link_gre6.c: Support IP6_TNL_F_ALLOW_LOCAL_REMOTE flag

Serhey Popovych writes: > Maybe it is better to rebase this against iproute2-next? Sure, I sent a v2 rebased on top of iproute2. Thanks, Petr

[net 04/11] net/mlx5e: Eliminate build warnings on no previous prototype

From: Or Gerlitz Fix these gcc warnings on drivers/net/ethernet/mellanox/mlx5: [..]/core/lib/clock.c:454:6: warning: no previous prototype for 'mlx5_init_clock' [-Wmissing-prototypes] [..]/core/lib/clock.c:510:6: warning: no previous prototype for 'mlx5_cleanup_clock'

[net 10/11] net/mlx5: E-Switch, Fix drop counters use before creation

From: Eugenia Emantayev First use of drop counters happens in esw_apply_vport_conf function, while they are allocated later in the flow. Fix that by moving esw_vport_create_drop_counters function to be called before the first use. Fixes: b8a0dbe3a90b ("net/mlx5e: E-switch,

[net 09/11] net/mlx5: Add header re-write to the checks for conflicting actions

From: Or Gerlitz We can't allow only some of the rules sharing an FTE to ask for header re-write, add it to the conflicting action checks. Fixes: 0d235c3fabb7 ('net/mlx5: Add hash table to search FTEs in a flow-group') Signed-off-by: Or Gerlitz

[pull request][net 00/11] Mellanox, mlx5 fixes 2018-02-20

Hi Dave, The following pull request includes some fixes for the mlx5 core and netdevice driver. Please pull and let me know if there's any issue. -stable 4.10.y: ('net/mlx5e: Fix loopback self test when GRO is off') -stable 4.12.y: ('net/mlx5e: Specify numa node when allocating drop rq')

[net 05/11] net/mlx5: Address static checker warnings on non-constant initializers

From: Or Gerlitz Address these sparse warnings on drivers/net/ethernet/mellanox/mlx5 [..]/core/diag/fs_tracepoint.c:99:53: warning: non-constant initializer for static object [..]/core/diag/fs_tracepoint.c:102:53: warning: non-constant initializer for static object etc

[net 02/11] net/mlx5e: Fix loopback self test when GRO is off

From: Inbar Karmy When GRO is off, the transport header pointer in sk_buff is initialized to network's header. To find the udp header, instead of using udp_hdr() which assumes skb_network_header was set, manually calculate the udp header offset. Fixes: 0952da791c97

[net 03/11] net/mlx5e: Verify inline header size do not exceed SKB linear size

From: Eran Ben Elisha Driver tries to copy at least MLX5E_MIN_INLINE bytes into the control segment of the WQE. It assumes that the linear part contains at least MLX5E_MIN_INLINE bytes, which can be wrong. Cited commit verified that driver will not copy more bytes into the

[net 11/11] net/mlx5: Fix error handling when adding flow rules

From: Vlad Buslov If building match list or adding existing fg fails when node is locked, function returned without unlocking it. This happened if node version changed or adding existing fg returned with EAGAIN after jumping to search_again_locked label. Fixes: bd71b08ec2ee

[net 08/11] net/mlx5: Use 128B cacheline size for 128B or larger cachelines

From: Daniel Jurgens The adapter uses the cache_line_128byte setting to set the bounds for end padding. On systems where the cacheline size is greater than 128B use 128B instead of the default of 64B. This results in fewer partial cacheline writes. There's a 50% chance it

[net 07/11] net/mlx5e: Specify numa node when allocating drop rq

From: Gal Pressman When allocating a drop rq, no numa node is explicitly set which means allocations are done on node zero. This is not necessarily the nearest numa node to the HCA, and even worse, might even be a memoryless numa node. Choose the numa_node given to us by the

Re: [PATCH] bpf: hide a possibly unused variable

On 02/20/2018 11:08 PM, Arnd Bergmann wrote: > On Tue, Feb 20, 2018 at 10:44 PM, Daniel Borkmann > wrote: >> Hi Arnd, >> >> On 02/20/2018 10:16 PM, Arnd Bergmann wrote: >>> The only user of this variable is inside of an #ifdef, causing >>> a warning without CONFIG_INET: >>>

[RFC net-next 11/11] ipmr, ip6mr: Unite dumproute flows

The various MFC entries are being held in the same kind of mr_tables for both ipmr and ip6mr, and their traversal logic is identical. Also, with the exception of the addresses [and other small tidbits] the major bulk of the nla setting is identical. Unite as much of the dumping as possible

[RFC net-next 04/11] mroute*: Make mr_table a common struct

Following previous changes to ip6mr, mr_table and mr6_table are basically the same [up to mr6_table having additional '6' suffixes to its variable names]. Move the common structure definition into a common header; This requires renaming all references in ip6mr to variables that had the distinct

[RFC net-next 01/11] ipmr,ipmr6: Define a uniform vif_device

The two implementations have almost identical structures - vif_device and mif_device. As a step toward uniforming the mr_tables, eliminate the mif_device and relocate the vif_device definition into a new common header file. Also, introduce a common initializing function for setting most of the

[RFC net-next 08/11] ipmr, ip6mr: Unite mfc seq logic

With the exception of the final dump, ipmr and ip6mr have the exact same seq logic for traversing a given mr_table. Refactor that code and make it common. Signed-off-by: Yuval Mintz --- include/linux/mroute_base.h | 69 net/ipv4/ipmr.c

[RFC net-next 10/11] ip6mr: Remove MFC_NOTIFY and refactor flags

MFC_NOTIFY exists in ip6mr, probably as some legacy code [was already removed for ipmr in commit 06bd6c0370bb ("net: ipmr: remove unused MFC_NOTIFY flag and make the flags enum"). Remove it from ip6mr as well, and move the enum into a common file; Notice MFC_OFFLOAD is currently only used by

[RFC net-next 07/11] ipmr, ip6mr: Unite logic for searching in MFC cache

ipmr and ip6mr utilize the exact same methods for searching the hashed resolved connections, difference being only in the construction of the hash comparison key. In order to unite the flow, introduce an mr_table operation set that would contain the protocol specific information required for

[RFC net-next 02/11] ip6mr: Make mroute_sk rcu-based

In ipmr the mr_table socket is handled under RCU. Introduce the same for ip6mr. Signed-off-by: Yuval Mintz --- include/linux/mroute6.h | 6 +++--- net/ipv6/ip6_output.c | 2 +- net/ipv6/ip6mr.c| 43 ++- 3 files changed, 30

Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device

On Tue, 20 Feb 2018 21:14:10 +0100, Jiri Pirko wrote: > Yeah, I can see it now :( I guess that the ship has sailed and we are > stuck with this ugly thing forever... > > Could you at least make some common code that is shared in between > netvsc and virtio_net so this is handled in exacly the

[PATCH iproute2-next v2] ip: link_gre6.c: Support IP6_TNL_F_ALLOW_LOCAL_REMOTE flag

For IP-in-IP tunnels, one can specify the [no]allow-localremote command when configuring a device. Under the hood, this flips the IP6_TNL_F_ALLOW_LOCAL_REMOTE flag on the netdevice. However, ip6gretap and ip6erspan devices, where the flag is also relevant, are not IP-in-IP tunnels, and thus

Re: [PATCH V7 2/4] sctp: Add ip option support

On Tue, Feb 20, 2018 at 07:15:27PM +, Richard Haines wrote: > Add ip option support to allow LSM security modules to utilise CIPSO/IPv4 > and CALIPSO/IPv6 services. > > Signed-off-by: Richard Haines > --- > All SCTP lksctp-tools/src/func_tests run correctly

Re: [PATCH iproute2-next v2 3/7] iplink: Use "dev" and "name" parameters interchangeable when possible

On Tue, 20 Feb 2018 23:37:25 +0200 Serhey Popovych wrote: > Both of them accept network device name as argument, but have different > meaning: > > dev - is a device by it's name, > name - name for specific device device. > > The only case where they treated

Re: [PATCH net-next 0/6] tcp: remove non GSO code

On Tue, 2018-02-20 at 21:45 +0100, Oleksandr Natalenko wrote: > On úterý 20. února 2018 21:09:37 CET Eric Dumazet wrote: > > Also you can tune your NIC to accept few MSS per GSO/TSO packet > > > > ip link set dev eth0 gso_max_segs 2 > > > > So even if TSO/GSO is there, BBR should not use

[net 06/11] net/mlx5e: Return error if prio is specified when offloading eswitch vlan push

From: Or Gerlitz This isn't supported when we emulate eswitch vlan push action which is the current state of things. Fixes: 8b32580df1cb ('net/mlx5e: Add TC vlan action for SRIOV offloads') Signed-off-by: Or Gerlitz Reviewed-by: Mark Bloch

[net 01/11] net/mlx5e: Fix TCP checksum in LRO buffers

From: Gal Pressman When receiving an LRO packet, the checksum field is set by the hardware to the checksum of the first coalesced packet. Obviously, this checksum is not valid for the merged LRO packet and should be fixed. We can use the CQE checksum which covers the checksum

Re: [PATCH net-next RFC 0/2] Convert OKI PCH GBE to mdiobus and phylib

Hi Andrew, On Tue, Feb 20, 2018 at 03:28:17AM +0100, Andrew Lunn wrote: > Hi Paul > > Here is my stab at converting the OKI PCH GBE to use the common MDIO > bus and phylib drivers. This is compile tested only, and pretty much > guaranteed to be broken. But hopefully it will help you. Feel free

[PATCH iproute2-next] tc: implement color output

Implement the -color option; in this case -co is ambiguous since it was already used for -conf. For now this just means putting device name in color. Signed-off-by: Stephen Hemminger --- man/man8/tc.8 | 9 +++-- tc/tc.c| 15 +++

Re: [PATCH net-next] cxgb4: append firmware dump to vmcore in kernel panic

On Mon, 19 Feb 2018 18:04:17 +0530, Rahul Lakkireddy wrote: > Our requirement is to analyze the state of firmware/hardware at the > time of kernel panic. I was wondering about this since you posted the patch and I can't come up with any specific scenario where kernel crash would correlate

Re: [Intel-wired-lan] [PATCH net-queue] e1000e: Fix check_for_link return value with autoneg off.

On 2/19/2018 22:12, Benjamin Poirier wrote: When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later.

Re: [PATCH iproute2-next 1/8] iplink: Return from function instead of calling exit()

On Tue, Feb 20, 2018 at 12:49 PM, David Ahern wrote: > On 2/20/18 1:44 PM, Roopa Prabhu wrote: >> On Tue, Feb 20, 2018 at 12:33 PM, Stephen Hemminger >> wrote: >>> On Tue, 20 Feb 2018 13:27:21 -0700 >>> David Ahern wrote: >>>

Re: [V9fs-developer] [PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

Hi Al, It's been two years without any sign of life from 9p maintainers... :-\ Would you apply (or nack) this patch ? Thanks, -- Greg PS: in the case you apply it, probable Cc sta...@vger.kernel.org as well On Thu, 08 Feb 2018 18:38:49 +0100 Greg Kurz wrote: > If it was

Re: [PATCH 1/3] net: Kill net_mutex

On Mon, 19 Feb 2018 12:58:38 +0300 Kirill Tkhai wrote: > + struct list_headexit_list; /* To linked to call pernet exit > + * methods on dead net (net_sem > + * read

Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure

On Tue, Feb 20, 2018 at 11:53:55AM +0100, Pablo Neira Ayuso wrote: > Hi David, > > On Mon, Feb 19, 2018 at 01:53:34PM -0500, David Miller wrote: > > I'm very suprised that this is generating classical BPF filters. > > > > We have native eBPF and that is what anything generating new code > >

Re: [PATCH] Carrier detect ok, don't turn off negotiation

Hi, David: How  is your thinking about this patch? >From b5902a4dfc709b62b704997ab64f31c9ef69a6db Mon Sep 17 00:00:00 2001 From: Denis Du Date: Mon, 15 Jan 2018 17:26:06 -0500 Subject: [PATCH] netdev: carrier detect ok, don't turn off negotiation Sometimes when

[PATCH net-next v4 1/2] ipvlan: drop ipv6 dependency

IPVlan has an hard dependency on IPv6, refactor the ipvlan code to allow compiling it with IPv6 disabled, move duplicate code into addr_equal() and refactor series of if-else into a switch. Signed-off-by: Matteo Croce --- v4: more descriptive commit message and fix

[PATCH net-next v4 0/2] Remove IPVlan module dependencies on IPv6 and L3 Master dev

The IPVlan module currently depends on IPv6 and L3 Master dev. Refactor the code to allow building IPVlan module regardless of the value of CONFIG_IPV6 as done in other drivers like VxLAN or GENEVE. Also change the CONFIG_NET_L3_MASTER_DEV dependency into a select, since compiling L3 Master device

[PATCH net-next v4 2/2] ipvlan: selects master_l3 device instead of depending on it

The L3 Master device is just a glue between the core networking code and device drivers, so it should be selected automatically rather than requiring to be enabled explicitly. Signed-off-by: Matteo Croce --- drivers/net/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1

[RFC net-next 03/11] ip6mr: Align hash implementation to ipmr

Since commit 8fb472c09b9d ("ipmr: improve hash scalability") ipmr has been using rhashtable as a basis for its mfc routes, but ip6mr is currently still using the old private MFC hash implementation. Align ip6mr to the current ipmr implementation. Signed-off-by: Yuval Mintz

[RFC net-next 09/11] ipmr, ip6mr: Unite vif seq functions

Same as previously done with the mfc seq, the logic for the vif seq is refactored to be shared between ipmr and ip6mr. Signed-off-by: Yuval Mintz --- include/linux/mroute_base.h | 33 ++ net/ipv4/ipmr.c | 49

[RFC net-next 06/11] ipmr, ip6mr: Make mfc_cache a common structure

mfc_cache and mfc6_cache are almost identical - the main difference is in the origin/group addresses and comparison-key. Make a common structure encapsulating most of the multicast routing logic - mr_mfc and convert both ipmr and ip6mr into using it. For easy conversion [casting, in this case]

[RFC net-next 05/11] ipmr, ip6mr: Unite creation of new mr_table

Now that both ipmr and ip6mr are using the same mr_table structure, we can have a common function to allocate & initialize a new instance. Signed-off-by: Yuval Mintz --- include/linux/mroute_base.h | 17 + net/ipv4/ipmr.c | 27

[RFC net-next 00/11] ipmr, ip6mr: Align multicast routing for IPv4 & IPv6

Historically ip6mr was based [cut-n-paste] on ipmr and the two have not diverged too much. Apparently as ipv4 multicast routing is more common than its ipv6 brethren modifications since then are mostly one-way, affecting ipmr while leaving ip6mr unchanged. This series is meant to re-factor both

Re: [PATCH net-next] cxgb4: append firmware dump to vmcore in kernel panic

On 02/20/2018 04:43 PM, Jakub Kicinski wrote: > On Mon, 19 Feb 2018 18:04:17 +0530, Rahul Lakkireddy wrote: >> Our requirement is to analyze the state of firmware/hardware at the >> time of kernel panic. > > I was wondering about this since you posted the patch and I can't come > up with any

Re: [PATCH net-next] cxgb4: append firmware dump to vmcore in kernel panic

On Tue, 20 Feb 2018 16:51:03 -0800, Florian Fainelli wrote: > On 02/20/2018 04:43 PM, Jakub Kicinski wrote: > > On Mon, 19 Feb 2018 18:04:17 +0530, Rahul Lakkireddy wrote: > >> Our requirement is to analyze the state of firmware/hardware at the > >> time of kernel panic. > > > > I was

Re: [PATCH v2] sched: report if filter is too large to dump

From: Roman Kapl Date: Mon, 19 Feb 2018 21:32:51 +0100 > So far, if the filter was too large to fit in the allocated skb, the > kernel did not return any error and stopped dumping. Modify the dumper > so that it returns -EMSGSIZE when a filter fails to dump and it is the > first

[PATCH iproute2-next] color: disable color when json output is requested

Instead of declaring -color and -json exclusive, ignore -color when -json is provided. The rationale is to allow to put -color in an alias for ip while still being able to use -json. -color is merely a presentation suggestion and we can assume there is nothing to color in the JSON output.

Re: [PATCH iproute2-next] color: disable color when json output is requested

On Wed, 21 Feb 2018 00:28:04 +0100 Vincent Bernat wrote: > Instead of declaring -color and -json exclusive, ignore -color when > -json is provided. The rationale is to allow to put -color in an alias > for ip while still being able to use -json. -color is merely a >

[PATCH net-next] net: dsa: mv88e6xxx: scratch registers and external MDIO pins

MV88E6352 and later switches support GPIO control through the "Scratch & Misc" global2 register. Two of the pins controlled this way on the mv88e6390 family are the external MDIO pins. They can either by used as part of the MII interface for port 0, GPIOs, or MDIO. Add a function to configure them

[PATCH iproute2-next 4/4] ip: Add ability to flush a rule based upon protocol

Add code to allow the `ip rule flush protocol XXX` command to be accepted and properly handled. Additionally modify the documentation to be correct with these changes. Signed-off-by: Donald Sharp --- ip/iprule.c| 25 ++---

[PATCH iproute2-next 1/4] ip: Use the `struct fib_rule_hdr` for rules

The iprule.c code was using `struct rtmsg` as the data type to pass into the kernel for the netlink message. While 'struct rtmsg' and `struct fib_rule_hdr` are the same size and mostly the same, we should use the correct data structure. This commit translates the data structures to have iprule.c

[PATCH iproute2-next 2/4] ip: Display ip rule protocol used

Newer kernels are now accepting a protocol from the installing program for who installed the rule. This change allows us to see this change if it is being specified by the installing program. Signed-off-by: Donald Sharp --- ip/iprule.c | 4 1 file changed, 4

[PATCH iproute2-next 3/4] ip: Allow rules to accept a specified protocol

Allow the specification of a protocol when the user adds/modifies/deletes a rule. Signed-off-by: Donald Sharp --- ip/iprule.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ip/iprule.c b/ip/iprule.c index b3e7d92c..fd242fee 100644 --- a/ip/iprule.c +++

[PATCH iproute2-next 0/4] Allow 'ip rule' command to use protocol

Fix iprule.c to use the actual `struct fib_rule_hdr` and to allow the end user to see and use the protocol keyword for rule manipulations. Donald Sharp (4): ip: Use the `struct fib_rule_hdr` for rules ip: Display ip rule protocol used ip: Allow rules to accept a specified protocol ip: Add

Re: [PATCH RFC 0/4] net: add bpfilter

On Tue, Feb 20, 2018 at 11:44:31AM +0100, Pablo Neira Ayuso wrote: > > Don't get me wrong, no software is safe from security issues, but if you > don't abstract your resources in the right way, you have more chance to > have experimence more problems. interesting point. The key part of

[PATCH] netlink: put module reference if dump start fails

Before, if cb->start() failed, the module reference would never be put, because cb->cb_running is intentionally false at this point. Users are generally annoyed by this because they can no longer unload modules that leak references. Also, it may be possible to tediously wrap a reference counter

Re: [PATCH iproute2-next v2 1/7] utils: Introduce and use nodev() helper routine

On 2/20/18 2:37 PM, Serhey Popovych wrote: > diff --git a/ip/ipneigh.c b/ip/ipneigh.c > index 0735424..9c9cd23 100644 > --- a/ip/ipneigh.c > +++ b/ip/ipneigh.c > @@ -178,11 +178,13 @@ static int ipneigh_modify(int cmd, int flags, int argc, > char **argv) > > ll_init_map(); > > - if

Re: [PATCH iproute2-next] color: disable color when json output is requested

❦ 20 février 2018 16:04 -0800, Stephen Hemminger  : >> Instead of declaring -color and -json exclusive, ignore -color when >> -json is provided. The rationale is to allow to put -color in an alias >> for ip while still being able to use -json. -color is merely a >>

Re: [PATCH iproute2-next v2] ip: link_gre6.c: Support IP6_TNL_F_ALLOW_LOCAL_REMOTE flag

Petr Machata wrote: > For IP-in-IP tunnels, one can specify the [no]allow-localremote command > when configuring a device. Under the hood, this flips the > IP6_TNL_F_ALLOW_LOCAL_REMOTE flag on the netdevice. However, ip6gretap > and ip6erspan devices, where the flag is also relevant, are not

Re: [net-next v2 1/2] bpf, seccomp: Add eBPF filter capabilities

On Mon, Feb 19, 2018 at 4:00 PM, Daniel Borkmann wrote: > On 02/19/2018 05:22 PM, Sargun Dhillon wrote: >> This introduces the BPF_PROG_TYPE_SECCOMP bpf program type. It is meant >> to be used for seccomp filters as an alternative to cBPF filters. The >> program type has

Re: [PATCH net-next] r8169: remove not needed PHY soft reset in rtl8168e_2_hw_phy_config

Am 21.02.2018 um 05:27 schrieb David Miller: > From: Heiner Kallweit > Date: Tue, 20 Feb 2018 07:30:16 +0100 > >> rtl8169_init_phy() resets the PHY anyway after applying the chip-specific >> PHY configuration. So we don't need to soft-reset the PHY as part of the >>

Re: [PATCH net-next] r8169: remove not needed PHY soft reset in rtl8168e_2_hw_phy_config

From: Heiner Kallweit Date: Tue, 20 Feb 2018 07:30:16 +0100 > rtl8169_init_phy() resets the PHY anyway after applying the chip-specific > PHY configuration. So we don't need to soft-reset the PHY as part of the > chip-specific configuration. > > Signed-off-by: Heiner

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, 2018-02-21 at 04:41 +0100, Jason A. Donenfeld wrote: > Before, if cb->start() failed, the module reference would never be put, > because cb->cb_running is intentionally false at this point. Users are > generally annoyed by this because they can no longer unload modules that > leak

Re: [PATCH iproute2-next v2 3/7] iplink: Use "dev" and "name" parameters interchangeable when possible

Stephen Hemminger wrote: > On Tue, 20 Feb 2018 23:37:25 +0200 > Serhey Popovych wrote: > >> Both of them accept network device name as argument, but have different >> meaning: >> >> dev - is a device by it's name, >> name - name for specific device device. >> >>

[PATCH net] smsc75xx: fix smsc75xx_set_features()

From: Eric Dumazet If an attempt is made to disable RX checksums, USB adapter is changed but netdev->features is not, because smsc75xx_set_features() returns a non zero value. This throws errors from netdev_rx_csum_fault() : : hw csum failure Signed-off-by: Eric Dumazet

Re: [PATCH iproute2-next v2 2/7] iplink: Correctly report error when network device isn't found

David Ahern wrote: > On 2/20/18 2:37 PM, Serhey Popovych wrote: >> Distinguish cases when "dev" parameter isn't given from cases where no >> network device corresponding to "dev" is found. >> >> Do not check for index validity in xdp_parse(): caller should take care >> of this because has more

Re: [PATCH net-next] r8169: remove some WOL-related dead code

From: Heiner Kallweit Date: Tue, 20 Feb 2018 07:23:03 +0100 > Commit bde135a672bf "r8169: only enable PCI wakeups when WOL is active" > removed the only user of flag RTL_FEATURE_WOL. So let's remove some > now dead code. > > Signed-off-by: Heiner Kallweit

Re: [net-next v2 1/2] bpf, seccomp: Add eBPF filter capabilities

On Mon, Feb 19, 2018 at 4:00 PM, Daniel Borkmann wrote: > On 02/19/2018 05:22 PM, Sargun Dhillon wrote: >> This introduces the BPF_PROG_TYPE_SECCOMP bpf program type. It is meant >> to be used for seccomp filters as an alternative to cBPF filters. The >> program type has

Re: [PATCH v2] sched: report if filter is too large to dump

Hi Roman, On Mon, Feb 19, 2018 at 09:32:51PM +0100, Roman Kapl wrote: > So far, if the filter was too large to fit in the allocated skb, the > kernel did not return any error and stopped dumping. Modify the dumper > so that it returns -EMSGSIZE when a filter fails to dump and it is the > first

nla_put_string() vs NLA_STRING

Hi, It seems that in at least one case[1], nla_put_string() is being used on an NLA_STRING, which lacks a NULL terminator, which leads to silliness when nla_put_string() uses strlen() to figure out the size: /** * nla_put_string - Add a string netlink attribute to a socket buffer * @skb:

Re: [PATCH iproute2-next v2 2/7] iplink: Correctly report error when network device isn't found

On 2/20/18 2:37 PM, Serhey Popovych wrote: > Distinguish cases when "dev" parameter isn't given from cases where no > network device corresponding to "dev" is found. > > Do not check for index validity in xdp_parse(): caller should take care > of this because has more information (e.g. when "dev"

Re: [PATCH net-next 0/6] tcp: remove non GSO code

Hi. On středa 21. února 2018 0:21:37 CET Eric Dumazet wrote: > My latest patch (fixing BBR underestimation of cwnd) > was meant for net tree, on a NIC where SG/TSO/GSO) are disabled. > > ( ie when sk->sk_gso_max_segs is not set to 'infinite' ) > > It is packet scheduler independent really. > >

Re: net: hang in unregister_netdevice: waiting for lo to become free

On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala wrote: > On 19.02.2018 20:59, Dmitry Vyukov wrote: >> >> On Sat, Feb 3, 2018 at 1:15 PM, Xin Long wrote: > > On 1/30/18 1:57 PM, David Ahern wrote: >> >> On 1/30/18 1:08 PM, Daniel

Re: ppp/pppoe, still panic 4.15.3 in ppp_push

On 2018-02-16 20:48, Guillaume Nault wrote: On Fri, Feb 16, 2018 at 01:13:18PM +0200, Denys Fedoryshchenko wrote: On 2018-02-15 21:42, Guillaume Nault wrote: > On Thu, Feb 15, 2018 at 09:34:42PM +0200, Denys Fedoryshchenko wrote: > > On 2018-02-15 21:31, Guillaume Nault wrote: > > > On Thu, Feb

Re: [PATCH iproute2-next] ip link: add support to display extended tun attributes

2018-02-20, 00:19:25 +0200, Serhey Popovych wrote: > I get following checkpatch.pl warnings: > > WARNING: Missing a blank line after declarations > #73: FILE: ip/iptuntap.c:497: > + __u8 mq = rta_getattr_u8(tb[IFLA_TUN_MULTI_QUEUE]); > + if (!mq) > > WARNING: Missing

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David! On Mon, Feb 19, 2018 at 12:22:26PM -0500, David Miller wrote: [...] > Netfilter's chronic performance differential is why a lot of mindshare > was lost to userspace networking technologies. Claiming that Netfilter is the reason for the massive adoption of userspace networking isn't a

Re: [PATCH RFC 0/4] net: add bpfilter

On Mon, Feb 19, 2018 at 06:09:39PM +0100, Phil Sutter wrote: > What puzzles me about your argumentation is that you seem to propose for > the kernel to cover up flaws in userspace. Spinning this concept further > would mean that if there would be an old bug in iproute2 we should think > of adding

Re: [PATCH RFC PoC 0/3] nftables meets bpf

Hi Daniel, On Mon, Feb 19, 2018 at 08:57:39PM +0100, Daniel Borkmann wrote: > On 02/19/2018 05:37 PM, Pablo Neira Ayuso wrote: > [...] > > * Simplified infrastructure: We don't need the ebpf verifier complexity > > either given we trust the code we generate from the kernel. We don't > > need

Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls

"Naveen N. Rao" writes: > Daniel Borkmann wrote: >> On 02/15/2018 05:25 PM, Daniel Borkmann wrote: >>> On 02/13/2018 05:05 AM, Sandipan Das wrote: The imm field of a bpf_insn is a signed 32-bit integer. For JIT-ed bpf-to-bpf function calls, it stores the

Re: [RFC PATCH v3 0/3] Enable virtio_net to act as a backup for a passthru device

Fri, Feb 16, 2018 at 07:11:19PM CET, sridhar.samudr...@intel.com wrote: >Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be >used by hypervisor to indicate that virtio_net interface should act as >a backup for another device with the same MAC address. > >Ppatch 2 is in response

Re: [PATCH v2] sched: report if filter is too large to dump

Mon, Feb 19, 2018 at 09:32:51PM CET, c...@rkapl.cz wrote: >So far, if the filter was too large to fit in the allocated skb, the >kernel did not return any error and stopped dumping. Modify the dumper >so that it returns -EMSGSIZE when a filter fails to dump and it is the >first filter in the skb.

Re: [PATCH net-next 0/6] tcp: remove non GSO code

Hi. 19.02.2018 20:56, Eric Dumazet wrote: Switching TCP to GSO mode, relying on core networking layers to perform eventual adaptation for dumb devices was overdue. 1) Most TCP developments are done with TSO in mind. 2) Less high-resolution timers needs to be armed for TCP-pacing 3) GSO can

Appending firmware/hardware dump to vmcore during kernel panic

Hi all, We have a requirement to collect firmware/hardware state of the underlying NIC during kernel panic. We are doing this in cxgb4 driver, using panic notifier list [1]. cxgb4 registers a callback function to the panic notifier list, which gets invoked during kernel panic. In the callback

[4.4-stable 17/22] cw1200: fix bogus maybe-uninitialized warning

commit 7fc1503c906f0fac62d3506a6e993e49fb996248 upstream. On x86, the cw1200 driver produces a rather silly warning about the possible use of the 'ret' variable without an initialization presumably after being confused by the architecture specific definition of WARN_ON:

[4.4-stable 19/22] net: hp100: remove unnecessary #ifdefs

commit 747a11279a442b913a57bf38934879babab3b58b upstream. Building the hp100 ethernet driver causes warnings when both the PCI and EISA drivers are disabled: ethernet/hp/hp100.c: In function 'hp100_module_init': ethernet/hp/hp100.c:3047:2: warning: label 'out3' defined but not used

Re: INFO: rcu detected stall in xfrm_confirm_neigh

On Mon, Feb 19, 2018 at 11:05:38AM +0100, Dmitry Vyukov wrote: > On Mon, Feb 19, 2018 at 8:22 AM, Steffen Klassert > wrote: > >> > wrote: > >> >> Hello, > >> >> > >> >> syzbot hit the following crash on net-next

Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure

Hi David, On Mon, Feb 19, 2018 at 01:53:34PM -0500, David Miller wrote: > I'm very suprised that this is generating classical BPF filters. > > We have native eBPF and that is what anything generating new code > should be using, rather than the 20+ year old CBPF. I'm not the only one that likes

Re: [RFC net PATCH] virtio_net: disable XDP_REDIRECT in receive_mergeable() case

On Fri, 16 Feb 2018 09:19:02 -0800 John Fastabend wrote: > On 02/16/2018 07:41 AM, Jesper Dangaard Brouer wrote: > > On Fri, 16 Feb 2018 13:31:37 +0800 > > Jason Wang wrote: > > > >> On 2018年02月16日 06:43, Jesper Dangaard Brouer wrote: > >>>

[PATCH iproute2] rdma: Avoid memory leak for skipper resource

From: Leon Romanovsky The call to get_task_name() allocates memory which is not freed in case of skipping the object. Fixes: 8ecac46a60ff ("rdma: Add QP resource tracking information") Signed-off-by: Leon Romanovsky --- rdma/res.c | 4 +++- 1 file

Re: [PATCH RFC 0/4] net: add bpfilter

Hi David, On Mon, Feb 19, 2018 at 12:15:37PM -0500, David Miller wrote: > From: Phil Sutter > Date: Mon, 19 Feb 2018 18:09:39 +0100 > > > What puzzles me about your argumentation is that you seem to propose for > > the kernel to cover up flaws in userspace. Spinning this concept

Re: [PATCH RFC 0/4] net: add bpfilter

From: Pablo Neira Ayuso Date: Tue, 20 Feb 2018 11:44:31 +0100 > * Lack of sufficient abstraction: bpf is not only exposing its own > software bugs through its interface, but it will also bite the dust > with CPU bugs due to lack of glue code to hide details behind the >

[net PATCH 1/4] virtio_net: disable XDP_REDIRECT in receive_mergeable() case

The virtio_net code have three different RX code-paths in receive_buf(). Two of these code paths can handle XDP, but one of them is broken for at least XDP_REDIRECT. Function(1): receive_big() does not support XDP. Function(2): receive_small() support XDP fully and uses build_skb(). Function(3):

[net PATCH 4/4] virtio_net: fix ndo_xdp_xmit crash towards dev not ready for XDP

When a driver implements the ndo_xdp_xmit() function, there is (currently) no generic way to determine whether it is safe to call. It is e.g. unsafe to call the drivers ndo_xdp_xmit, if it have not allocated the needed XDP TX queues yet. This is the case for virtio_net, which first allocates the

[net PATCH 2/4] virtio_net: fix XDP code path in receive_small()

When configuring virtio_net to use the code path 'receive_small()', in-order to get correct XDP_REDIRECT support, I discovered TCP packets would get silently dropped when loading an XDP program action XDP_PASS. The bug seems to be that receive_small() when XDP is loaded check that hdr->hdr.flags

[net PATCH 3/4] virtio_net: fix memory leak in XDP_REDIRECT

XDP_REDIRECT calling xdp_do_redirect() can fail for multiple reasons (which can be inspected by tracepoints). The current semantics is that on failure the driver calling xdp_do_redirect() must handle freeing or recycling the page associated with this frame. This can be seen as an optimization, as

[net PATCH 0/4] virtio_net: several bugs in XDP code for driver virtio_net

The virtio_net driver actually violates the original memory model of XDP causing hard to debug crashes. Per request of John Fastabend, instead of removing the XDP feature I'm fixing as much as possible. While testing virtio_net with XDP_REDIRECT I found 4 different bugs. Patch-1: not enough

[PATCH net-next v2 0/1] Allow rules to track originating protocol

Add the ability for the kernel to track the originating protocol for when new rules are added to the kernel. --- v1->v2 -> Address comments by David Miller to collapse patches into 1. Donald Sharp (1): net: Allow a rule to track originating protocol drivers/net/vrf.c | 1 +

[PATCH net-next v2 1/1] net: Allow a rule to track originating protocol

Allow a rule that is being added/deleted/modified or dumped to contain the originating protocol's id. The protocol is handled just like a routes originating protocol is. This is especially useful because there is starting to be a plethora of different user space programs adding rules. Allow the

  1   2   3   >