Re: [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe wrote: > The get_page in this area looks *highly* suspect due to there being no > corresponding put_page. However, I've left that as is to avoid breaking > things. chcr driver will post the request to LLD driver cxgb4 and

Re: [PATCH net-next 1/8] rtnetlink: Do not generate notifications for MTU events

+Nicolas On 4/14/17 7:51 PM, Vlad Yasevich wrote: > On 04/10/2017 11:49 AM, David Ahern wrote: >> On 4/10/17 9:39 AM, Vlad Yasevich wrote: >>> OK, so this will work for the events that are generated as a result of >>> device state change >>> (like mtu, address, and others). >>> >>> However, the

Re: [PATCH net-next 1/8] rtnetlink: Do not generate notifications for MTU events

On 04/10/2017 11:49 AM, David Ahern wrote: > On 4/10/17 9:39 AM, Vlad Yasevich wrote: >> OK, so this will work for the events that are generated as a result of >> device state change >> (like mtu, address, and others). >> >> However, the original event data may be needed for other events that may

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, 14 Apr 2017 17:46:44 -0700, Alexei Starovoitov wrote: > On Fri, Apr 14, 2017 at 03:30:32PM -0700, Jakub Kicinski wrote: > > On Fri, 14 Apr 2017 12:28:15 -0700, Alexei Starovoitov wrote: > > > On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > > > > > > >

Re: [PATCH net-next v2] Add uid and cookie bpf helper to cg_skb_func_proto

On Fri, Apr 14, 2017 at 06:25:26PM -0700, Chenbo Feng wrote: > From: Chenbo Feng > > BPF helper functions get_socket_cookie and get_socket_uid can be > used for network traffic classifications, among others. Expose > them also to programs of type BPF_PROG_TYPE_CGROUP_SKB. As of

[PATCH net-next v2] Add uid and cookie bpf helper to cg_skb_func_proto

From: Chenbo Feng BPF helper functions get_socket_cookie and get_socket_uid can be used for network traffic classifications, among others. Expose them also to programs of type BPF_PROG_TYPE_CGROUP_SKB. As of commit 8f917bba0042 ("bpf: pass sk to helper functions") the required

Re: [PATCH v4 net-next RFC] net: Generic XDP

On Thu, Apr 13, 2017 at 04:23:15PM -0400, David Miller wrote: > + > + switch (act) { > + case XDP_TX: > + __skb_push(skb, skb->mac_len); s/skb->mac_len/mac_len/ > + HARD_TX_UNLOCK(dev, txq); > + if (free_skb) { > + trace_xdp_exception(dev, xdp_prog,

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, Apr 14, 2017 at 03:30:32PM -0700, Jakub Kicinski wrote: > On Fri, 14 Apr 2017 12:28:15 -0700, Alexei Starovoitov wrote: > > On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > > > > > We are consistently finding that there is this real need to > > > >

Re: ipv6 udp early demux breaks udp_l3mdev_accept=0

On 4/14/17 6:38 PM, Subash Abhinov Kasiviswanathan wrote: > On 2017-04-14 16:23, David Ahern wrote: >> Subash: >> >> My understanding of early demux is that it should only match connected >> sockets (src/sport + dst/dport are all set). The ipv6 udp early demux >> code added in 5425077d73e0c is

Re: ipv6 udp early demux breaks udp_l3mdev_accept=0

On 2017-04-14 16:23, David Ahern wrote: Subash: My understanding of early demux is that it should only match connected sockets (src/sport + dst/dport are all set). The ipv6 udp early demux code added in 5425077d73e0c is doing a generic socket lookup which does not require an exact match and

Re: [PATCH net-next] Add uid and cookie bpf helper to cg_skb_func_proto

On 04/15/2017 02:07 AM, Alexei Starovoitov wrote: On Fri, Apr 14, 2017 at 04:12:14PM -0700, Chenbo Feng wrote: From: Chenbo Feng BPF helper functions get_socket_cookie and get_socket_uid can be used for network traffic classifications, among others. Expose them also to

Re: [PATCH net-next] bonding: do not pass link-local packets to master-interface

Mahesh Bandewar (महेश बंडेवार) wrote: >On Fri, Apr 14, 2017 at 12:30 PM, Jay Vosburgh > wrote: >> >> >> Chonggang Li wrote: >> >> >Previously link-local packets excluding LACP (which are handled by >> >the recv_probe) received on bond slave

Re: [PATCH net-next] Add uid and cookie bpf helper to cg_skb_func_proto

On Fri, Apr 14, 2017 at 04:12:14PM -0700, Chenbo Feng wrote: > From: Chenbo Feng > > BPF helper functions get_socket_cookie and get_socket_uid can be > used for network traffic classifications, among others. Expose > them also to programs of type BPF_PROG_TYPE_CGROUP_SKB. As of

[PATCH net-next] drivers: net: xgene-v2: Extend ethtool statistics

This patch adds extended statistics reporting to ethtool. In summary, this patch, - adds ethtool.h with the statistics register definitions - adds 'struct xge_gstrings_extd_stats' to gather extended stats - modifies xge_get_strings(), get_sset_count() and get_ethtool_stats()

[PATCH net-next] Add uid and cookie bpf helper to cg_skb_func_proto

From: Chenbo Feng BPF helper functions get_socket_cookie and get_socket_uid can be used for network traffic classifications, among others. Expose them also to programs of type BPF_PROG_TYPE_CGROUP_SKB. As of commit 8f917bba0042 ("bpf: pass sk to helper functions") the required

[PATCH iproute2 v2] ip vrf: Add command name next to pid

'ip vrf pids' is used to list processes bound to a vrf, but it only shows the pid leaving a lot of work for the user. Add the command name to the output. With this patch you get the more user friendly: $ ip vrf pids mgmt 1121 ntpd 1418 gdm-session-wor 1488 gnome-session

Re: [PATCH iproute2] ip vrf: Add command name next to pid

On 4/14/17 4:57 PM, Stephen Hemminger wrote: > Overall, this looks like a good idea. > >> + >> +int get_comm(char *pid, char *comm, int len) > > > Please use more glibc style function signature, like: > > int get_comm(const char *pid, char *comm, size_t len) > > And maybe even > int

Re: [PATCH net-next 1/1 v3] drivers: net: rmnet: Initial implementation

+https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/\ +dataservices/tree/rmnetctl Don't split URL better to have long line. diff --git a/drivers/net/rmnet/Kconfig b/drivers/net/rmnet/Kconfig Since this is Qualcomm and Ethernet specific, maybe better to put in

Re: [iproute2 net-next v2 0/3] ip netconf improvements

On Thu, 23 Mar 2017 19:51:19 -0700 David Ahern wrote: > Currently, ip netconf only shows data for ipv4 and ipv6 for dumps > and just ipv4 for device requests. Improve the user experience by > using the new kernel patch to dump all address families that have >

Re: [patch iproute2/net-next repost] devlink: Add support for pipeline debug (dpipe)

On Thu, 13 Apr 2017 11:30:27 +0200 Jiri Pirko wrote: > We actually took this code from teamdctl (at least it was an influence). > Devlink style is so much different in every aspect from the rest of the > iproute2 suite. And I did it on purpose, because it is much nicer and >

Re: [PATCH iproute2] ip vrf: Add command name next to pid

Overall, this looks like a good idea. > + > +int get_comm(char *pid, char *comm, int len) Please use more glibc style function signature, like: int get_comm(const char *pid, char *comm, size_t len) And maybe even int get_command_name(pid_t pid, char *comm, size_t len)

[PATCH] net: natsemi: ns83820: add checks for dma mapping error

The driver does not check if mapping dma memory succeed. The patch adds the checks and failure handling. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov --- drivers/net/ethernet/natsemi/ns83820.c | 13 +++-- 1 file

Re: [PATCH next 2/5] bonding: initialize work-queues during creation of bond

On 8 March 2017 at 10:55, Mahesh Bandewar wrote: > From: Mahesh Bandewar > > Initializing work-queues every time ifup operation performed is unnecessary > and can be performed only once when the port is created. > > Signed-off-by: Mahesh Bandewar

Re: [PATCH iproute2 net-next 2/3] iproute: add support for SR-IPv6 lwtunnel encapsulation

On Fri, 14 Apr 2017 14:36:22 +0200 David Lebrun wrote: > + if (!tb[SEG6_IPTUNNEL_SRH]) > + return Bad indentation?

Re: [PATCH iproute2 net-next 1/3] ip: add ip sr command to control SR-IPv6 internal structures

On Fri, 14 Apr 2017 14:36:21 +0200 David Lebrun wrote: > +static struct { > + int cmd; Why not unsigned? you only assign positive values > + struct in6_addr addr; > + __u32 keyid; > + char *pass; Why not const char *? or do you free the value on exit? >

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, 14 Apr 2017 12:28:15 -0700, Alexei Starovoitov wrote: > On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > > > We are consistently finding that there is this real need to > > > communicate XDP capabilities, or somehow verify that the needs > > > of an XDP

ipv6 udp early demux breaks udp_l3mdev_accept=0

Subash: My understanding of early demux is that it should only match connected sockets (src/sport + dst/dport are all set). The ipv6 udp early demux code added in 5425077d73e0c is doing a generic socket lookup which does not require an exact match and accordingly breaks udp_l3mdev_accept=0.

Re: [PATCH v3 net-next RFC] Generic XDP

On 04/14/2017 09:28 PM, Alexei Starovoitov wrote: On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: We are consistently finding that there is this real need to communicate XDP capabilities, or somehow verify that the needs of an XDP program can be satisfied by a given

Re: [PATCH net-next 1/1 v3] drivers: net: rmnet: Initial implementation

On Fri, 14 Apr 2017 15:57:22 -0600 Subash Abhinov Kasiviswanathan wrote: > >> + rmnet_kfree_skb > >> + (skb, > >> + RMNET_STATS_SKBFREE_INGRESS_NOT_EXPECT_MAPD); > > > > very odd formatting.

Re: [PATCH net-next 1/1 v3] drivers: net: rmnet: Initial implementation

No, please use standard facilities in order to do debug logging. +static struct rmnet_logical_ep_conf_s *_rmnet_get_logical_ep Dont use "_" at the start of a name without purpose +static int rmnet_associate_network_device(struct net_device *dev) I would expect to see here you making

Re: [PATCH net-next] bonding: do not pass link-local packets to master-interface

On Fri, Apr 14, 2017 at 12:30 PM, Jay Vosburgh wrote: > > > Chonggang Li wrote: > > >Previously link-local packets excluding LACP (which are handled by > >the recv_probe) received on bond slave interfaces are delivered to > >stack with

Re: [PATCH net] ipv6: drop non loopback packets claiming to originate from ::1

On Fri, Apr 14, 2017, at 20:22, Florian Westphal wrote: > We lack a saddr check for ::1. This causes security issues e.g. with acls > permitting connections from ::1 because of assumption that these > originate > from local machine. > > Assuming a source address of ::1 is local seems reasonable.

[PATCH net-next 2/2] hv_netvsc: change netvsc device default duplex to FULL

From: Simon Xiao The netvsc device supports full duplex by default. This warnings in log from bonding device which did not like seeing UNKNOWN duplex. Signed-off-by: Simon Xiao --- drivers/net/hyperv/netvsc_drv.c | 2 +- 1 file changed, 1

[PATCH net-next 1/2] netvsc: fix RCU warning in get_stats

The statistics functionis called with RTNL held during probe but with RCU held during access from /proc and elsewhere. This is safe so update the lockdep annotation. Signed-off-by: Stephen Hemminger --- drivers/net/hyperv/netvsc_drv.c | 2 +- 1 file changed, 1

4.10.9 nok with realtek wlan, atom

On Thu, Feb 9, 2017 at 9:09 PM, Larry Finger wrote: > On 02/09/2017 01:43 PM, Bjorn Helgaas wrote: >> >> [+cc rtl8192ce folks in case they've seen this] >> >> On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote: >>> >>> hi, >>> >>> not technical expert

Re: [PATCH net-next] bonding: do not pass link-local packets to master-interface

> In what case is the current behavior a problem (my guess would > be something related to LLDP)? LLDP is indeed the case we're trying to solve here. Listen on one socket and get LLDP for all interfaces in the system. > What if, e.g., the bond is a bridge > port, will STP frames no

Re: [PATCH block-tree] net: off by one in inet6_pton()

On 04/13/2017 01:42 PM, Dan Carpenter wrote: > If "scope_len" is sizeof(scope_id) then we would put the NUL terminator > one space beyond the end of the buffer. Added, thanks Dan. -- Jens Axboe

Re: [PATCH v3 net-next RFC] Generic XDP

On Thu, Apr 13, 2017 at 11:38:10AM -0400, David Miller wrote: > From: Johannes Berg > Date: Thu, 13 Apr 2017 08:10:56 +0200 > > > On Wed, 2017-04-12 at 21:20 -0700, Alexei Starovoitov wrote: > > > >> > +if (skb_linearize(skb)) > >> > +goto

Re: [PATCH net-next] bonding: do not pass link-local packets to master-interface

Chonggang Li wrote: >Previously link-local packets excluding LACP (which are handled by >the recv_probe) received on bond slave interfaces are delivered to >stack with bond-master device with RX_HANDLER_ANOTHER, however all >link-local packets are link specific and

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote: > > > > We are consistently finding that there is this real need to > > communicate XDP capabilities, or somehow verify that the needs > > of an XDP program can be satisfied by a given implementation. > > I fully agree that

export pcie_flr and remove copies of it in drivers V2

Hi all, this exports the PCI layer pcie_flr helper, and removes various opencoded copies of it. Changes since V1: - rebase on top of the pci/virtualization branch - fixed the probe case in __pci_dev_reset - added ACKs from Bjorn

[PATCH 2/7] PCI: call pcie_flr from reset_intel_82599_sfp_virtfn

The 82599 quirk contained an outdated copy of the FLR code. Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas --- drivers/pci/quirks.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/pci/quirks.c

[PATCH 1/7] PCI: export pcie_flr

Currently we opencode the FLR sequence in lots of place, export a core helper instead. We split out the probing for FLR support as all the non-core callers already know their hardware. Note that in the new pci_has_flr function the quirk check has been moved before the capability check as there

Re: [PATCH -next] net: phy: test the right variable in phy_write_mmd()

On Fri, Apr 14, 2017 at 10:10:41PM +0300, Dan Carpenter wrote: > This is a copy and paste buglet. We meant to test for ->write_mmd but > we test for ->read_mmd. > > Fixes: 1ee6b9bc6206 ("net: phy: make phy_(read|write)_mmd() generic MMD > accessors") > Signed-off-by: Dan Carpenter

[no subject]

Things seem to be settling down as far as networking is concerned, let's hope this trend continues... 1) Add iov_iter_revert() and use it to fix the behavior of skb_copy_datagram_msg() et al., from Al Viro. 2) Fix the protocol used in the synthetic SKB we cons up for the purposes of doing

[PATCH 3/7] PCI: call pcie_flr from reset_chelsio_generic_dev

Instead of copy & pasting and old version of the code. Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas --- drivers/pci/quirks.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/pci/quirks.c

[PATCH 6/7] crypto: qat: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig --- drivers/crypto/qat/qat_common/adf_aer.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/crypto/qat/qat_common/adf_aer.c b/drivers/crypto/qat/qat_common/adf_aer.c index 2839fccdd84b..d3e25c37dc33 100644

[PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index

[PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig --- drivers/infiniband/hw/hfi1/chip.c | 4 ++-- drivers/infiniband/hw/hfi1/hfi.h | 1 - drivers/infiniband/hw/hfi1/pcie.c | 30 -- 3 files changed, 2 insertions(+), 33 deletions(-) diff --git

[PATCH 7/7] liquidio: use pcie_flr instead of duplicating it

Signed-off-by: Christoph Hellwig --- drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c index

[PATCH -next] net: phy: test the right variable in phy_write_mmd()

This is a copy and paste buglet. We meant to test for ->write_mmd but we test for ->read_mmd. Fixes: 1ee6b9bc6206 ("net: phy: make phy_(read|write)_mmd() generic MMD accessors") Signed-off-by: Dan Carpenter diff --git a/drivers/net/phy/phy-core.c

Re: [PATCH net] ipv6: drop non loopback packets claiming to originate from ::1

On Fri, 2017-04-14 at 20:22 +0200, Florian Westphal wrote: > We lack a saddr check for ::1. This causes security issues e.g. with acls > permitting connections from ::1 because of assumption that these originate > from local machine. > > Assuming a source address of ::1 is local seems reasonable.

Re: [PATCH v3 net-next RFC] Generic XDP

On Fri, Apr 14, 2017 at 10:07:40AM +0200, Johannes Berg wrote: > On Thu, 2017-04-13 at 16:01 -0400, David Miller wrote: > > From: Johannes Berg > > Date: Thu, 13 Apr 2017 21:22:21 +0200 > > > > > OTOH, it might depend on the frame data itself, if the program does > > >

Re: [RFC 1/3] bpf/wireless: add wifimon program type

On Wed, Apr 12, 2017 at 05:30:40PM +0200, Johannes Berg wrote: > On Wed, 2017-04-12 at 11:19 -0400, David Miller wrote: > > > > > Instead it may make more sense to just have a "wifi_info(skb, > > info)" > > > function you can call, e.g. with a structure that has various > > fields > > > and flags

Re: eBPF - little-endian load instructions?

On Thu, Apr 13, 2017 at 07:58:45AM +0200, Johannes Berg wrote: > On Wed, 2017-04-12 at 20:08 -0700, Alexei Starovoitov wrote: > > > it's really llvm bug that i need fix. It's plain broken > > to generate what effectively is nop insn for march=bpfeb > > My only excuse that when that code was

Re: [PATCH 3/4] net: macb: Add hardware PTP support

On Thu, Apr 13, 2017 at 02:39:23PM +0100, Rafal Ozieblo wrote: > This patch is based on original Harini's patch and Andrei's patch, > implemented in a separate file to ease the review/maintanance > and integration with other platforms. Please see if you can break this patch into 2 parts: 1.

Re: [Intel-wired-lan] [next-queue v6 PATCH 5/7] i40e: Add TX and RX support over port netdev's in switchdev mode

On 4/14/2017 9:47 AM, Alexander Duyck wrote: On Wed, Mar 29, 2017 at 5:22 PM, Sridhar Samudrala wrote: In switchdev mode, broadcasts from VFs are received by the PF and passed to corresponding port representor netdev. Any frames sent via port netdevs are sent as

[PATCH net] ipv6: drop non loopback packets claiming to originate from ::1

We lack a saddr check for ::1. This causes security issues e.g. with acls permitting connections from ::1 because of assumption that these originate from local machine. Assuming a source address of ::1 is local seems reasonable. RFC4291 doesn't allow such a source address either, so drop such

pull request: bluetooth-next 2017-04-14

Hi Dave, Here's the main batch of Bluetooth & 802.15.4 patches for the 4.12 kernel. - Many fixes to 6LoWPAN, in particular for BLE - New CA8210 IEEE 802.15.4 device driver (accounting for most of the lines of code added in this pull request) - Added Nokia Bluetooth (UART) HCI driver -

[PATCH net-next] bonding: do not pass link-local packets to master-interface

Previously link-local packets excluding LACP (which are handled by the recv_probe) received on bond slave interfaces are delivered to stack with bond-master device with RX_HANDLER_ANOTHER, however all link-local packets are link specific and should be delivered with exact same link/dev.

Re: [PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses

On Fri, 14 Apr 2017 18:44:46 +0200 Matthias Schiffer wrote: > As link-local addresses are only valid for a single interface, we can allow > to use the same VNI for multiple independent VXLANs, as long as the used > interfaces are distinct. This way, VXLANs can

Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

On Fri, 14 Apr 2017 18:44:44 +0200 Matthias Schiffer wrote: > diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c > index 07f89b037681..95a71546e8f2 100644 > --- a/drivers/net/vxlan.c > +++ b/drivers/net/vxlan.c > @@ -2881,11 +2881,39 @@ static int

[PATCH net-next 1/6] bpf: lru: Add test_lru_sanity6 for BPF_F_NO_COMMON_LRU

test_lru_sanity3 is not applicable to BPF_F_NO_COMMON_LRU. It just happens to work when PERCPU_FREE_TARGET == 16. This patch: 1) Disable test_lru_sanity3 for BPF_F_NO_COMMON_LRU 2) Add test_lru_sanity6 to test list rotation for the BPF_F_NO_COMMON_LRU map. Signed-off-by: Martin KaFai Lau

[PATCH net-next 6/6] bpf: lru: Add map-in-map LRU example

This patch adds a map-in-map LRU example. If we know only a subset of cores will use the LRU, we can allocate a common LRU list per targeting core and store it into an array-of-hashs. It allows using the common LRU map with map-update performance comparable to the BPF_F_NO_COMMON_LRU map but

[PATCH net-next 0/6] bpf: LRU performance and test-program improvements

The first 4 patches make a few improvements to the LRU tests. Patch 5/6 is to improve the performance of BPF_F_NO_COMMON_LRU map. Patch 6/6 adds an example in using LRU map with map-in-map. Martin KaFai Lau (6): bpf: lru: Add test_lru_sanity6 for BPF_F_NO_COMMON_LRU bpf: lru: Cleanup

[PATCH net-next 3/6] bpf: lru: Refactor LRU map tests in map_perf_test

One more LRU test will be added later in this patch series. In this patch, we first move all existing LRU map tests into a single syscall (connect) first so that the future new LRU test can be added without hunting another syscall. One of the map name is also changed from percpu_lru_hash_map to

[PATCH net-next 5/6] bpf: lru: Lower the PERCPU_NR_SCANS from 16 to 4

After doing map_perf_test with a much bigger BPF_F_NO_COMMON_LRU map, the perf report shows a lot of time spent in rotating the inactive list (i.e. __bpf_lru_list_rotate_inactive): > map_perf_test 32 8 1 100 | awk '{sum += $3}END{print sum}' 19644783 (19M/s) > map_perf_test 32 8 1000

[PATCH net-next 4/6] bpf: Allow bpf sample programs (*_user.c) to change bpf_map_def

The current bpf_map_def is statically defined during compile time. This patch allows the *_user.c program to change it during runtime. It is done by adding load_bpf_file_fixup_map() which takes a callback. The callback will be called before creating each map so that it has a chance to modify

[PATCH net-next 2/6] bpf: lru: Cleanup test_lru_map.c

This patch does the following cleanup on test_lru_map.c 1) Fix indentation (Replace spaces by tabs) 2) Remove redundant BPF_F_NO_COMMON_LRU test 3) Simplify some comments Signed-off-by: Martin KaFai Lau Acked-by: Alexei Starovoitov Acked-by: Daniel Borkmann

Re: [PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

On 04/14/2017 07:44 PM, Matthias Schiffer wrote: * Multicast addresses are never valid as local address * Link-local IPv6 unicast addresses may only be used as remote when the local address is link-local as well * Don't allow link-local IPv6 local/remote addresses without interface We also

Re: [Intel-wired-lan] [next-queue v6 PATCH 5/7] i40e: Add TX and RX support over port netdev's in switchdev mode

On Wed, Mar 29, 2017 at 5:22 PM, Sridhar Samudrala wrote: > In switchdev mode, broadcasts from VFs are received by the PF and passed > to corresponding port representor netdev. > Any frames sent via port netdevs are sent as directed transmits to the > corresponding

[PATCH net-next v2 3/6] vxlan: improve validation of address family configuration

Address families of source and destination addresses must match, and changelink operations can't change the address family. In addition, always use the VXLAN_F_IPV6 to check if a VXLAN device uses IPv4 or IPv6. Signed-off-by: Matthias Schiffer --- v2: new patch

[PATCH net-next v2 2/6] vxlan: get rid of redundant vxlan_dev.flags

There is no good reason to keep the flags twice in vxlan_dev and vxlan_config. Signed-off-by: Matthias Schiffer --- v2: new patch drivers/net/vxlan.c | 76 +-- include/net/vxlan.h | 1 -

[PATCH net-next v2 0/6] vxlan: cleanup and IPv6 link-local support

Running VXLANs over IPv6 link-local addresses allows to use them as a drop-in replacement for VLANs, avoiding to allocate additional outer IP addresses to run the VXLAN over. Since v1, I have added a lot more consistency checks to the address configuration, making sure address families and scopes

[PATCH net-next v2 4/6] vxlan: check valid combinations of address scopes

* Multicast addresses are never valid as local address * Link-local IPv6 unicast addresses may only be used as remote when the local address is link-local as well * Don't allow link-local IPv6 local/remote addresses without interface We also store in the flags field if link-local addresses are

[PATCH net-next v2 6/6] vxlan: allow multiple VXLANs with same VNI for IPv6 link-local addresses

As link-local addresses are only valid for a single interface, we can allow to use the same VNI for multiple independent VXLANs, as long as the used interfaces are distinct. This way, VXLANs can always be used as a drop-in replacement for VLANs with greater ID space. This also extends VNI lookup

[PATCH net-next v2 5/6] vxlan: fix snooping for link-local IPv6 addresses

If VXLAN is run over link-local IPv6 addresses, it is necessary to store the ifindex in the FDB entries. Otherwise, the used interface is undefined and unicast communication will most likely fail. Signed-off-by: Matthias Schiffer --- v2: use u32 instead of __u32

[PATCH net-next v2 1/6] vxlan: refactor verification and application of configuration

The vxlan_dev_configure function was mixing validation and application of the vxlan configuration; this could easily lead to bugs with the changelink operation, as it was hard to see if the function wcould return an error after parts of the configuration had already been applied. This commit

Re: How to debug DMAR errors?

On 04/14/2017 09:24 AM, Alexander Duyck wrote: On Fri, Apr 14, 2017 at 9:19 AM, Ben Greear wrote: On 04/14/2017 08:45 AM, Alexander Duyck wrote: On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear wrote: Hello, I have been seeing a regular

Re: [PATCH v4 net-next RFC] net: Generic XDP

On Thu, Apr 13, 2017 at 9:09 AM, David Miller wrote: > [snip] > +static u32 netif_receive_generic_xdp(struct sk_buff *skb, > +struct bpf_prog *xdp_prog) > +{ > + struct xdp_buff xdp; > + u32 act = XDP_DROP; > + void

Re: How to debug DMAR errors?

On Fri, Apr 14, 2017 at 9:19 AM, Ben Greear wrote: > > > On 04/14/2017 08:45 AM, Alexander Duyck wrote: >> >> On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear >> wrote: >>> >>> Hello, >>> >>> I have been seeing a regular occurrence of DMAR errors,

Re: How to debug DMAR errors?

On 04/14/2017 08:45 AM, Alexander Duyck wrote: On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear wrote: Hello, I have been seeing a regular occurrence of DMAR errors, looking something like this when testing my ath10k driver/firmware under some specific loads (maximum

Re: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

Great, thanks! Logan On 14/04/17 10:07 AM, Kershner, David A wrote: > Can you add Acked-by for this patch? > > Acked-by: David Kershner > > Tested on s-Par and no problems. > > Thanks, > David Kershner > >> --- >> drivers/staging/unisys/visorhba/visorhba_main.c

Re: [PATCH net-next 1/1 v3] drivers: net: rmnet: Initial implementation

On Thu, 13 Apr 2017 23:05:29 -0600 Subash Abhinov Kasiviswanathan wrote: > RmNet driver provides a transport agnostic MAP (multiplexing and > aggregation protocol) support in embedded module. Module provides > virtual network devices which can be attached to any IP-mode

Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)

://github.com/0day-ci/linux/commits/Logan-Gunthorpe/Introduce-common-scatterlist-map-function/20170414-142518 > base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next > :: branch date: 8 hours ago > :: commit date: 8 hours ago > >>> drivers/tar

RE: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

> -Original Message- > From: Logan Gunthorpe [mailto:log...@deltatee.com] ... > Subject: [PATCH 10/22] staging: unisys: visorbus: Make use of the new > sg_map helper function > > Straightforward conversion to the new function. > > Signed-off-by: Logan Gunthorpe Can

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On 14/04/17 02:39 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in all four spots. > > I think the right fix here is to switch dm-crypt to the ahash API > that takes a scatterlist. Hmm,

RE: HR department.

From: Mona Duncan Sent: 14 April 2017 10:08 Subject: HR department. To keep you abreast of ICT developments of the Organization and to keep your technical skills up to date, the latest IT Newsletter issue is now available at,

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 09:51:48AM -0500, Bjorn Helgaas wrote: > > Otherwise, I'd be glad to take the series given acks for the non-PCI > > parts. Just let me know. > > I do already have a patch (c5e4f0192ad2 ("PCI: Avoid FLR for Intel > 82579 NICs")) on my pci/virtualization branch that touches

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 09:41:08AM -0500, Bjorn Helgaas wrote: > Looks good to me (except the comment on probe). If you want to apply > the whole series via netdev or some non-PCI tree, here's my ack for > the drivers/pci parts, assuming the probe thing is resolved: > > Acked-by: Bjorn Helgaas

Re: [PATCH 1/7] PCI: export pcie_flr

> s/pcie_has_flr/pcie_has_flr()/ Ok. > This performs an FLR (if supported) always, regardless of "probe". > I think it should look something like this instead: > > if (pcie_has_flr(dev)) { > if (!probe) > pcie_flr(dev); > rc = 0; > goto done; > } Indeed!

Re: How to debug DMAR errors?

On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear wrote: > Hello, > > I have been seeing a regular occurrence of DMAR errors, looking something > like this when testing my ath10k driver/firmware under some specific loads > (maximum receive of 512 byte frames in AP mode): > >

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On 14/04/17 02:36 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: >> Convert the kmap and kmap_atomic uses to the sg_map function. We now >> store the flags for the kmap instead of a boolean to indicate >> atomicitiy. We also propogate a possible

Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions

On 14/04/17 02:35 AM, Christoph Hellwig wrote: >> + >> static inline int is_dma_buf_file(struct file *); >> >> struct dma_buf_list { > > I think the right fix here is to rename the operation to unmap_atomic > and send out a little patch for that ASAP. Ok, I can do that next week. > I'd

Re: [PATCH] net: can: Introduce MEN 16Z192-00 CAN controller driver

On 06/28/2016 03:44 PM, Andreas Werner wrote: > This CAN Controller is found on MEN Chameleon FPGAs. > > The driver/device supports the CAN2.0 specification. > There are 255 RX and 255 Tx buffer within the IP. The > pointer for the buffer are handled by HW to make the > access from within the

Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)

it tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Logan-Gunthorpe/Introduce-common-scatterlist-map-function/20170414-142518 base: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next :: branch date: 8 hours ago ::

Re: [PATCH 0/9] Netfilter fixes for net

From: Pablo Neira Ayuso Date: Fri, 14 Apr 2017 02:26:42 +0200 > The following patchset contains Netfilter fixes for your net tree, > they are: ... > You can pull these changes from: > > git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git Pulled, thanks Pablo.

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 9:41 AM, Bjorn Helgaas wrote: > On Thu, Apr 13, 2017 at 04:53:32PM +0200, Christoph Hellwig wrote: >> Hi all, >> >> this exports the PCI layer pcie_flr helper, and removes various opencoded >> copies of it. > > Looks good to me (except the comment on

Re: export pcie_flr and remove copies of it in drivers

On Thu, Apr 13, 2017 at 04:53:32PM +0200, Christoph Hellwig wrote: > Hi all, > > this exports the PCI layer pcie_flr helper, and removes various opencoded > copies of it. Looks good to me (except the comment on probe). If you want to apply the whole series via netdev or some non-PCI tree,

Re: [PATCH 1/7] PCI: export pcie_flr

[+cc Alex] On Thu, Apr 13, 2017 at 04:53:33PM +0200, Christoph Hellwig wrote: > Currently we opencode the FLR sequence in lots of place, export a core > helper instead. We split out the probing for FLR support as all the > non-core callers already know their hardware. > > Signed-off-by:

  1   2   >