[PATCH next 0/2] Rename WORD_TRUNC/ROUND macros and use them

This patchset aims to rename these macros to a non-confusing name, as reported by David Laight and David Miller, and to update all remaining places to make use of it, which was 1 last remaining spot. Details on the specific changelogs. Thanks! Marcelo Ricardo Leitner (2): sctp: rename

[PATCH next 2/2] sctp: make use of WORD_TRUNC macro

And avoid the usage of '&~3'. This is the last place still not using the macro. Also break the line to make it easier to read. Signed-off-by: Marcelo Ricardo Leitner --- When I checked it the other day I thought I had this patch applied by the moment but I hadn't.

[PATCH next 1/2] sctp: rename WORD_TRUNC/ROUND macros

To something more meaningful these days, specially because this is working on packet headers or lengths and which are not tied to any CPU arch but to the protocol itself. So, WORD_TRUNC becomes SCTP_TRUNC4 and WORD_ROUND becomes SCTP_ALIGN4. Reported-by: David Laight

Re: [RFC PATCH] xdp: separate struct xdp_prog as container for bpf_prog

On 09/20/2016 09:55 PM, Jesper Dangaard Brouer wrote: Currently the XDP program is simply a bpf_prog pointer. While it is good for simplicity, it is limiting extendability for upcoming features. Introducing a new struct xdp_prog, that can carry information related to the XDP program. Notice

[PATCH 1/2] ptp_clock: allow for it to be optional

In order to break the hard dependency between the PTP clock subsystem and ethernet drivers capable of being clock providers, this patch provides simple PTP stub functions to allow linkage of those drivers into the kernel even when the PTP subsystem is configured out. And to make it possible for

[PATCH 2/2] posix-timers: make it configurable

Many embedded systems typically don't need them. This removes about 22KB from the kernel binary size on ARM when configured out. Corresponding syscalls are routed to a stub logging the attempt to use those syscalls which should be enough of a clue if they were disabled without proper

[PATCH v2 0/2] make POSIX timers optional

Many embedded systems don't need the full POSIX timer support. Configuring them out provides a nice kernel image size reduction. When POSIX timers are configured out, the PTP clock subsystem should be left out as well. However a bunch of ethernet drivers currently *select* it in their Kconfig

[RFC PATCH] xdp: separate struct xdp_prog as container for bpf_prog

Currently the XDP program is simply a bpf_prog pointer. While it is good for simplicity, it is limiting extendability for upcoming features. Introducing a new struct xdp_prog, that can carry information related to the XDP program. Notice this approach does not affect performance (tested and

Re: [PATCH net-next 3/3] net: ethernet: mediatek: add the dts property to set if TRGMII supported on GMAC0

On Tue, Sep 20, 2016 at 03:59:20PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add the dts property for the capability if TRGMII supported on GAMC0 > > Signed-off-by: Sean Wang > --- >

Re: [RFC] PCI: Allow sysfs control over totalvfs

Tue, Sep 20, 2016 at 05:49:48PM CEST, yuval.mi...@qlogic.com wrote: >[Sorry in advance if this was already discussed in the past] > >Some of the HW capable of SRIOV has resource limitations, where the >PF and VFs resources are drawn from a common pool. >In some cases, these limitations have to be

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, Sep 20, 2016 at 11:59 AM, Jesper Dangaard Brouer wrote: > On Tue, 20 Sep 2016 10:39:20 -0700 > Eric Dumazet wrote: > >> On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote: >> >> > because 'div by zero' is an abnormal situation that

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 20 Sep 2016 10:39:20 -0700 Eric Dumazet wrote: > On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote: > > > because 'div by zero' is an abnormal situation that shouldn't be exploited. > > Meaning if xdp program is doing DoS prevention and it has a bug

[PATCH net-next V2] net/vxlan: Avoid unaligned access in vxlan_build_skb()

The vxlan header may not be aligned to 4 bytes in vxlan_build_skb (e.g., for MLD packets). This patch avoids unaligned access traps from vxlan_build_skb (in platforms like sparc) by making struct vxlanhdr __packed. Signed-off-by: Sowmini Varadhan ---

Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

On 09/20/2016 07:30 AM, David Laight wrote: From: Jason Baron Sent: 19 September 2016 19:34 ... sizeof(struct bnx2x_mcast_list_elem) = 24. So there are 170 per page on x86. So if we want to fit 2,048 elements, we need 12 pages. If you only need to save the mcast addresses you could use a

Re: [PATCH v4 net-next 16/16] tcp_bbr: add BBR congestion control

On Tue, Sep 20, 2016 at 11:48 AM, Stephen Hemminger wrote: > On Mon, 19 Sep 2016 23:39:23 -0400 > Neal Cardwell wrote: > >> +/* INET_DIAG_BBRINFO */ >> + >> +struct tcp_bbr_info { >> + /* u64 bw: max-filtered BW (app throughput) estimate in

Re: [PATCH v4 net-next 16/16] tcp_bbr: add BBR congestion control

On Tue, Sep 20, 2016 at 2:48 PM, Stephen Hemminger wrote: > > On Mon, 19 Sep 2016 23:39:23 -0400 > Neal Cardwell wrote: > > > +/* INET_DIAG_BBRINFO */ > > + > > +struct tcp_bbr_info { > > + /* u64 bw: max-filtered BW (app throughput) estimate

Re: [PATCH v4 net-next 16/16] tcp_bbr: add BBR congestion control

On Mon, 19 Sep 2016 23:39:23 -0400 Neal Cardwell wrote: > +/* INET_DIAG_BBRINFO */ > + > +struct tcp_bbr_info { > + /* u64 bw: max-filtered BW (app throughput) estimate in Byte per sec: */ > + __u32 bbr_bw_lo; /* lower 32 bits of bw */ > + __u32

Re: [PATCH v4 net-next 13/16] tcp: allow congestion control to expand send buffer differently

On Tue, Sep 20, 2016 at 10:48 AM, Stephen Hemminger wrote: > > On Mon, 19 Sep 2016 23:39:20 -0400 > Neal Cardwell wrote: > > > From: Yuchung Cheng > > > > Currently the TCP send buffer expands to twice cwnd, in order to allow

Re: UBSAN reports issue in ip_idents_reserve

On Tue, 2016-09-20 at 19:46 +0200, Jiri Pirko wrote: > > This patch makes ubsan silent. Thanks Jiri, I will post an official patch then ;)

Re: Possible code defects: macros and precedence

On Tue, 2016-09-20 at 10:07 -0700, Joe Perches wrote: > On Tue, 2016-09-20 at 15:14 +0200, Julia Lawall wrote: > > The semantic patch below finds a binary operator in a macro and a binary > > operator in the use of the macro, and checks if the priority of the > > operator in the macro is higher

Re: [PATCH net-next 5/7] rhashtable: abstract out function to get hash

On 09/20/16 at 05:36pm, Herbert Xu wrote: > Tom Herbert wrote: > > Split out most of rht_key_hashfn which is calculating the hash into > > its own function. This way the hash function can be called separately to > > get the hash value. > > > > Acked-by: Thomas Graf

Re: [PATCH v4 net-next 13/16] tcp: allow congestion control to expand send buffer differently

On Mon, 19 Sep 2016 23:39:20 -0400 Neal Cardwell wrote: > From: Yuchung Cheng > > Currently the TCP send buffer expands to twice cwnd, in order to allow > limited transmits in the CA_Recovery state. This assumes that cwnd > does not increase in the

Re: UBSAN reports issue in ip_idents_reserve

Tue, Sep 20, 2016 at 04:18:12PM CEST, eric.duma...@gmail.com wrote: >On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote: >> On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote: >> >> > I see. So how to silent the warning? >> > >> >> We can replace the atomic_add_return() and use a loop

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 2016-09-20 at 09:45 -0700, Alexei Starovoitov wrote: > because 'div by zero' is an abnormal situation that shouldn't be exploited. > Meaning if xdp program is doing DoS prevention and it has a bug that > attacker can now exploit by sending a crafted packet that causes > 'div by zero' and

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On (09/20/16 19:09), Jiri Benc wrote: > > But the point stands, we have much greater problems here than VXLAN. > And I don't think that wrapping all IP address accesses into > get/put_unaligned all around the stack is the solution. > Agreed, and I think Tom made that point too. For the

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Tue, Sep 20, 2016 at 10:09 AM, Jiri Benc wrote: > On Tue, 20 Sep 2016 18:43:33 +0200, Jiri Benc wrote: >> On Tue, 20 Sep 2016 12:31:08 -0400, Sowmini Varadhan wrote: >> > The vxlan header is after the ethernet header (14 bytes), >> > IP header (20 bytes, assuming no options)

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Tue, 20 Sep 2016 13:07:42 -0400, Sowmini Varadhan wrote: > I will try out Hannes' solution (which makes sense) in a moment, > and report back. No objections to marking the struct as packed. Will only push the problem to a different place, though. Jiri

Re: [PATCH v3 net-next 2/2] net: skbuff: Coding: Use eth_type_vlan() instead of open coding it

On Tue, Sep 20, 2016 at 2:48 AM, Shmulik Ladkani wrote: > Fix 'skb_vlan_pop' to use eth_type_vlan instead of directly comparing > skb->protocol to ETH_P_8021Q or ETH_P_8021AD. > > Signed-off-by: Shmulik Ladkani Reviewed-by: Pravin B

Re: [PATCH v3 net-next 1/2] net: skbuff: Remove errornous length validation in skb_vlan_pop()

On Tue, Sep 20, 2016 at 2:48 AM, Shmulik Ladkani wrote: > In 93515d53b1 > "net: move vlan pop/push functions into common code" > skb_vlan_pop was moved from its private location in openvswitch to > skbuff common code. > > In case skb has non hw-accel vlan

Re: [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing

On 15/09/2016 11:19, Pavel Machek wrote: > Hi! > >> This series is a proof of concept to fill some missing part of seccomp as the >> ability to check syscall argument pointers or creating more dynamic security >> policies. The goal of this new stackable Linux Security Module (LSM) called >>

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Tue, 20 Sep 2016 18:43:33 +0200, Jiri Benc wrote: > On Tue, 20 Sep 2016 12:31:08 -0400, Sowmini Varadhan wrote: > > The vxlan header is after the ethernet header (14 bytes), > > IP header (20 bytes, assuming no options) and udp header (8 bytes). > > If the VXLAN header is not aligned to 4

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On (09/20/16 18:43), Jiri Benc wrote: > > IPv6 header is certainly not 20 bytes. vxlan encapsulates an IPv6/ethernet frame in a UDP/IPv4/ethernet packet. the ipv4 header is 20 bytes (without options). mld_newpack is dealing with the vxlan net_device in this case, which has ->hard_header_len of

Re: [RFC 02/11] Add RoCE driver framework

On Tue, Sep 20, 2016 at 03:04:12PM +, Elior, Ariel wrote: > > From: Leon Romanovsky [mailto:l...@kernel.org] > > On Thu, Sep 15, 2016 at 05:11:03AM +, Mintz, Yuval wrote: > > > > As a summary, I didn't see in your responses any real life example > > > > where you will > > > > need global

Re: [RFC v3 18/22] cgroup,landlock: Add CGRP_NO_NEW_PRIVS to handle unprivileged hooks

On 20/09/2016 06:37, Sargun Dhillon wrote: > On Thu, Sep 15, 2016 at 09:41:33PM +0200, Mickaël Salaün wrote: >> >> On 15/09/2016 06:48, Alexei Starovoitov wrote: >>> On Wed, Sep 14, 2016 at 09:38:16PM -0700, Andy Lutomirski wrote: On Wed, Sep 14, 2016 at 9:31 PM, Alexei Starovoitov

Re: lsm naming dilemma. Re: [RFC v3 07/22] landlock: Handle file comparisons

On 20/09/2016 03:10, Sargun Dhillon wrote: > I'm fine giving up the Checmate name. Landlock seems easy enough to > Google. I haven't gotten a chance to look through the entire patchset > yet, but it does seem like they are somewhat similar. Excellent! I'm looking forward for your review. > >

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On 09/20/16 at 09:45am, Alexei Starovoitov wrote: > that's a great idea. Instead of adding aborted, ring_full, blahblah counters > everywhere that cost performance, let's add tracepoints that are nops > when not in use. > And if all drivers call the same tracepoints it will be even better. >

Re: [PATCH v6 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs

On 09/20/16 at 04:29pm, Pablo Neira Ayuso wrote: > On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote: > [...] > > Why would we artificially limit the use-cases of this implementation if > > the way it stands, both filtering and introspection are possible? > > Why should we place

Re: [PATCHv2 iproute2] ip route: check ftell, fseek return value

On Thu, 8 Sep 2016 10:26:57 +0800 Hangbin Liu wrote: > ftell() may return -1 in error case, which is not handled and therefore pass a > negative offset to fseek(). The return code of fseek() is also not checked. > > Reported-by: Phil Sutter > Signed-off-by:

Re: [iproute PATCH] tc: don't accept qdisc 'handle' greater than ffff

On Fri, 16 Sep 2016 10:30:00 +0200 Davide Caratti wrote: > since get_qdisc_handle() truncates the input value to 16 bit, return an > error and prompt "invalid qdisc ID" in case input 'handle' parameter needs > more than 16 bit to be stored. > > Signed-off-by: Davide Caratti

Re: [PATCH] ip: (ipvlan) introduce L3s mode

On Mon, 19 Sep 2016 14:39:40 -0700 Mahesh Bandewar wrote: > From: Mahesh Bandewar > > The new mode 'l3s' can be set like - > > ip link add link dev type ipvlan mode l3s > > e.g. ip link add link eth0 dev ipvl0 type ipvlan mode l3s > > Also did

Re: [iproute PATCH] macsec: fix input range of 'icvlen' parameter

On Fri, 9 Sep 2016 16:02:22 +0200 Davide Caratti wrote: > the maximum possible ICV length in a MACsec frame is 16 octects, not 32: > fix get_icvlen() accordingly, so that a proper error message is displayed > in case input 'icvlen' is greater than 16. > > Signed-off-by:

Re: [PATCH iproute2 2/2] vxlan: group address requires net device

On Mon, 5 Sep 2016 11:35:28 +0200 Jiri Benc wrote: > This is now enforced in the kernel, check also in iproute to get a better > error message. > > Signed-off-by: Jiri Benc Applied

Re: [RFC v2 04/12] qedr: Add support for user context verbs

On Tue, Sep 20, 2016 at 01:35:56PM +0300, Ram Amrani wrote: > From: Ram amrani > > Add support for ucontext, query port, add and del gid verbs. > > Signed-off-by: Rajesh Borundia > Signed-off-by: Ram Amrani > --- <...>

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, Sep 20, 2016 at 06:27:17PM +0200, Jesper Dangaard Brouer wrote: > On Tue, 20 Sep 2016 09:13:56 -0700 > Eric Dumazet wrote: > > > On Tue, 2016-09-20 at 18:06 +0200, Jesper Dangaard Brouer wrote: > > > On Tue, 20 Sep 2016 08:58:30 -0700 > > > Eric Dumazet

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On 20.09.2016 16:27, Sowmini Varadhan wrote: > The vxlan header is at offset (14 + 20 + 8) into the packet, > so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned > functions to modify flags and vni field in the vxh. > > Signed-off-by: Sowmini Varadhan

Re: [PATCH net-next 8/8] net: qualcomm: add QCA7000 UART driver

> kbuild test robot <l...@intel.com> hat am 20. September 2016 um 16:44 > geschrieben: > > > Hi Stefan, > > [auto build test ERROR on net-next/master] > > url: > > https://github.com/0day-ci/linux/commits/Stefan-Wahren/net-qualcomm-add-QCA7000-UAR

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Tue, 20 Sep 2016 12:31:08 -0400, Sowmini Varadhan wrote: > The vxlan header is after the ethernet header (14 bytes), > IP header (20 bytes, assuming no options) and udp header (8 bytes). If the VXLAN header is not aligned to 4 bytes, then IP header is not aligned to 4 bytes, too, and you have

Re: [PATCH v6 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs

Hi Pablo, On 09/20/2016 04:29 PM, Pablo Neira Ayuso wrote: > On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote: > [...] >> Why would we artificially limit the use-cases of this implementation if >> the way it stands, both filtering and introspection are possible? > > Why should we

Re: [PATCH 3/6] ip xfrm state: add save/restore

On Fri, 2 Sep 2016 12:02:23 +0300 Pavel Tikhomirov wrote: > +static __u32 state_dump_magic = 0x71706987; > + > +static int xfrm_state_list_deleteall_or_save(int argc, char **argv, int > deleteall, int save) I have no problem with the overall functionality of this

Re: [PATCH v4 net-next 01/16] tcp: cdg: rename struct minmax in tcp_cdg.c to avoid a naming conflict

On Tue, Sep 20, 2016 at 5:39 AM, Neal Cardwell wrote: > > From: Soheil Hassas Yeganeh > > The upcoming change "lib/win_minmax: windowed min or max estimator" > introduces a struct called minmax, which is then included in > include/linux/tcp.h in the

Re: [PATCH iproute2 net-next v1 0/7] tipc: updates for neighbour monitor

On Mon, 12 Sep 2016 17:17:14 +0200 Parthasarathy Bhuvaragan wrote: > We add configuration support for the new link monitoring attributes. > > Parthasarathy Bhuvaragan (7): > tipc: remove dead code > tipc: add link monitor set threshold > tipc: add

Re: [PATCH bug-fix] iproute: fix documentation for ip rule scan order

On Thu, 8 Sep 2016 14:43:17 +0200 Phil Sutter wrote: > On Thu, Sep 08, 2016 at 01:48:08PM +0200, Michal Kubecek wrote: > > On Thu, Sep 08, 2016 at 12:33:03PM +0200, Phil Sutter wrote: > > > On Thu, Sep 08, 2016 at 11:59:55AM +0200, Michal Kubecek wrote: > > > > > > > > I'm

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On (09/20/16 18:11), Jiri Benc wrote: > > The vxlan header is at offset (14 + 20 + 8) into the packet, > > so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned > > functions to modify flags and vni field in the vxh. > > How did you calculate that? IP header should be aligned to 4

Re: [RFC v2 06/12] qedr: Add support for QP verbs

On Tue, Sep 20, 2016 at 01:35:58PM +0300, Ram Amrani wrote: > From: Ram amrani > > Add support for Queue Pair verbs which adds, deletes, > modifies and queries Queue Pairs. > > Signed-off-by: Rajesh Borundia > Signed-off-by: Ram Amrani

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 20 Sep 2016 09:13:56 -0700 Eric Dumazet wrote: > On Tue, 2016-09-20 at 18:06 +0200, Jesper Dangaard Brouer wrote: > > On Tue, 20 Sep 2016 08:58:30 -0700 > > Eric Dumazet wrote: > > > > Same for XDP_TX if/when packet is dropped because

Re: UBSAN reports issue in ip_idents_reserve

Tue, Sep 20, 2016 at 05:25:16PM CEST, eric.duma...@gmail.com wrote: >On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote: >> On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote: >> >> > I see. So how to silent the warning? >> > >> >> We can replace the atomic_add_return() and use a loop

Re: [RFC v2 00/11] QLogic RDMA Driver (qedr) RFC

On Tue, Sep 20, 2016 at 01:33:25PM +, Elior, Ariel wrote: > > On Tue, Sep 20, 2016 at 01:35:52PM +0300, Ram Amrani wrote: > ... > > > The series adds on top of RFC v1: > > > * a check for all drivers that IB_ACCESS_MW_BIND isn't set for > > > ib_get_dma_mr > > > * relocation of qedr user API

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 2016-09-20 at 18:06 +0200, Jesper Dangaard Brouer wrote: > On Tue, 20 Sep 2016 08:58:30 -0700 > Eric Dumazet wrote: > > Same for XDP_TX if/when packet is dropped because output ring is full. > > For the XDP_TX case a counter is already incremented[1] but it is a

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Tue, 20 Sep 2016 10:27:00 -0400, Sowmini Varadhan wrote: > The vxlan header is at offset (14 + 20 + 8) into the packet, > so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned > functions to modify flags and vni field in the vxh. How did you calculate that? IP header should be

RE: [RFC v2 00/11] QLogic RDMA Driver (qedr) RFC

> On Tue, Sep 20, 2016 at 01:35:52PM +0300, Ram Amrani wrote: ... > > The series adds on top of RFC v1: > > * a check for all drivers that IB_ACCESS_MW_BIND isn't set for ib_get_dma_mr > > * relocation of qedr user API to include/rdma/uapi/providers/ > > * removal of qedr_devlist_local > > * fixed

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 20 Sep 2016 08:58:30 -0700 Eric Dumazet wrote: > On Tue, 2016-09-20 at 08:51 -0700, Tom Herbert wrote: > > On Tue, Sep 20, 2016 at 8:40 AM, Alexei Starovoitov > > wrote: > > > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 20 Sep 2016 08:40:37 -0700 Alexei Starovoitov wrote: > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote: > > >>>+case XDP_ABORTED: > > >>It is not clearly defined, but I believe XDP_ABORTED should also result > > >>in a warning (calling

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, Sep 20, 2016 at 08:51:05AM -0700, Tom Herbert wrote: > On Tue, Sep 20, 2016 at 8:40 AM, Alexei Starovoitov > wrote: > > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote: > >> >>>+ case XDP_ABORTED: > >> >>It is not clearly defined, but I believe

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, 2016-09-20 at 08:51 -0700, Tom Herbert wrote: > On Tue, Sep 20, 2016 at 8:40 AM, Alexei Starovoitov > wrote: > > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote: > >> >>>+ case XDP_ABORTED: > >> >>It is not clearly defined, but I believe

[PATCH net-next] net: ethernet: mediatek: fix missing changes merged for conflicts overlapping commits

From: Sean Wang add the missing commits about 1) Commit d3bd1ce4db8e843dce421e2f8f123e5251a9c7d3 ("remove redundant free_irq for devm_request_ir allocated irq") 2) Commit 7c6b0d76fa02213393815e3b6d5e4a415bf3f0e2 ("fix logic unbalance between probe and remove") during

[RFC] PCI: Allow sysfs control over totalvfs

[Sorry in advance if this was already discussed in the past] Some of the HW capable of SRIOV has resource limitations, where the PF and VFs resources are drawn from a common pool. In some cases, these limitations have to be considered early during chip initialization and can only be changed by

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, Sep 20, 2016 at 8:40 AM, Alexei Starovoitov wrote: > On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote: >> >>>+ case XDP_ABORTED: >> >>It is not clearly defined, but I believe XDP_ABORTED should also result >> >>in a warning (calling

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On (09/20/16 08:31), Tom Herbert wrote: > > On Tue, Sep 20, 2016 at 7:27 AM, Sowmini Varadhan > wrote: > > The vxlan header is at offset (14 + 20 + 8) into the packet, > > so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned > > functions to modify

Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support

On Tue, Sep 20, 2016 at 03:53:10PM +0300, Tariq Toukan wrote: > >>>+ case XDP_ABORTED: > >>It is not clearly defined, but I believe XDP_ABORTED should also result > >>in a warning (calling bpf_warn_invalid_xdp_action(act)). > I'll add this. Certainly NOT. XDP_ABORTED is an exception case when

RE: [RFC 02/11] Add RoCE driver framework

> From: Leon Romanovsky [mailto:l...@kernel.org] > On Thu, Sep 15, 2016 at 05:11:03AM +, Mintz, Yuval wrote: > > > As a summary, I didn't see in your responses any real life example where > > > you will > > > need global debug level for your driver. > > > > Not sure what you you're expecting

Re: [PATCH net-next 8/8] net: qualcomm: add QCA7000 UART driver

Hi Stefan, > This patch adds the Ethernet over UART driver for the > Qualcomm QCA7000 HomePlug GreenPHY. > > Signed-off-by: Stefan Wahren > --- > drivers/net/ethernet/qualcomm/Kconfig | 12 + > drivers/net/ethernet/qualcomm/Makefile | 2 + >

Re: [PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

On Tue, Sep 20, 2016 at 7:27 AM, Sowmini Varadhan wrote: > The vxlan header is at offset (14 + 20 + 8) into the packet, > so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned > functions to modify flags and vni field in the vxh. > I'm wondering if

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Tue, Sep 20, 2016 at 10:13:14PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2016-09-20 at 16:00 +0930, Joel Stanley wrote: > > On Aspeed SoC with a direct PHY connection (non-NSCI), we receive > > continual PHYSTS interrupts: > > > >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] =

Re: [RFC v2 04/12] qedr: Add support for user context verbs

On Tue, Sep 20, 2016 at 01:35:56PM +0300, Ram Amrani wrote: > +++ b/include/uapi/rdma/providers/qedr-abi.h > @@ -0,0 +1,27 @@ > +/* QLogic qed NIC Driver > + * Copyright (c) 2015 QLogic Corporation > + * > + * This software is available under the terms of the GNU General Public > License > + *

Re: [RFC v2 06/12] qedr: Add support for QP verbs

On Tue, Sep 20, 2016 at 01:35:58PM +0300, Ram Amrani wrote: > +++ b/include/uapi/rdma/providers/qedr-abi.h > @@ -43,4 +43,39 @@ struct qedr_create_cq_uresp { > u16 icid; > }; Ugh, each patch keeps adding to this? > +struct qedr_create_qp_ureq { > + u32 qp_handle_hi; > + u32

Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

On 09/20/2016 11:00 AM, Mintz, Yuval wrote: The question I rose was whether it actually makes a difference under such circumstances whether the device would actually filter those multicast addresses or be completely multicast promiscuous. e.g., whether it's significant to be filtering out

Re: UBSAN reports issue in ip_idents_reserve

On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote: > On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote: > > > I see. So how to silent the warning? > > > > We can replace the atomic_add_return() and use a loop around > atomic_read() and atomic_cmpxhg() > > This would change the nice

Re: [PATCH] netfilter: xt_socket: fix transparent match for IPv6 request sockets

On Tue, 2016-09-20 at 08:01 -0700, Eric Dumazet wrote: > > Something like : > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index 3ebf45b38bc3..0fccfd6cc258 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -6264,6 +6264,7 @@ int tcp_conn_request(struct

Re: [PATCH] netfilter: xt_socket: fix transparent match for IPv6 request sockets

On Tue, 2016-09-20 at 15:26 +0200, KOVACS Krisztian wrote: > The introduction of TCP_NEW_SYN_RECV state, and the addition of request > sockets to the ehash table seems to have broken the --transparent option > of the socket match for IPv6 (around commit a9407000). > > Now that the socket lookup

RE: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

> > The question I rose was whether it actually makes a difference under > > such circumstances whether the device would actually filter those > > multicast addresses or be completely multicast promiscuous. > > e.g., whether it's significant to be filtering out multicast ingress > > traffic when

Re: [PATCH net-next 2/2] bnx2x: allocate mac filtering pending list in PAGE_SIZE increments

On 09/20/2016 03:41 AM, Mintz, Yuval wrote: Currently, we can have high order page allocations that specify GFP_ATOMIC when configuring multicast MAC address filters. For example, we have seen order 2 page allocation failures with ~500 multicast addresses configured. Convert the allocation

Re: [PATCH net-next v2 05/10] bnxt_en: Fix ethtool -l|-L inconsistent channel counts.

Hi! On Tue, 20 Sep 2016 02:50:23 -0400, Michael Chan wrote: > The existing code is inconsistent in reporting and accepting the combined > channel count. bnxt_get_channels() reports maximum combined as the > maximum rx count. bnxt_set_channels() accepts combined count that > cannot be bigger

[PATCH] cxgb4: fix signed wrap around when decrementing index idx

From: Colin Ian King Change predecrement compare to post decrement compare to avoid an unsigned integer wrap-around comparison when decrementing idx in the while loop. For example, when idx is zero, the current situation will predecrement idx in the while loop,

[PATCH] cxgb4: fix signed wrap around when decrementing index idx

From: Colin Ian King Change predecrement compare to post decrement compare to avoid an unsigned integer wrap-around comparison when decrementing idx in the while loop. For example, when idx is zero, the current situation will predecrement idx in the while loop,

Re: DSA: Suspicious RCU usage (via rtnl_bridge_getlink)

Tue, Sep 20, 2016 at 04:32:53PM CEST, vivien.dide...@savoirfairelinux.com wrote: >Hi Andrew, Russell, > >Andrew Lunn writes: > >> On Tue, Sep 20, 2016 at 11:26:12AM +0100, Russell King - ARM Linux wrote: >>> Issuing "bridge vlan show" on clearfog provokes a "suspicious RCU usage"

Re: [PATCH net-next 8/8] net: qualcomm: add QCA7000 UART driver

Hi Stefan, [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Stefan-Wahren/net-qualcomm-add-QCA7000-UART-driver/20160920-210908 config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save

Re: DSA: Suspicious RCU usage (via rtnl_bridge_getlink)

Hi Andrew, Russell, Andrew Lunn writes: > On Tue, Sep 20, 2016 at 11:26:12AM +0100, Russell King - ARM Linux wrote: >> Issuing "bridge vlan show" on clearfog provokes a "suspicious RCU usage" >> warning from the kernel (see below). >> >> As it's illegal to schedule while

Re: [PATCH v5 0/6] Add eBPF hooks for cgroups

On 09/19/2016 11:53 PM, Sargun Dhillon wrote: > On Mon, Sep 19, 2016 at 06:34:28PM +0200, Daniel Mack wrote: >> On 09/16/2016 09:57 PM, Sargun Dhillon wrote: >>> Now, with this patch, we don't have that, but I think we can reasonably add >>> some >>> flag like "no override" when applying

Re: [PATCH v6 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs

On Mon, Sep 19, 2016 at 10:56:14PM +0200, Daniel Mack wrote: [...] > Why would we artificially limit the use-cases of this implementation if > the way it stands, both filtering and introspection are possible? Why should we place infrastructure in the kernel to filter packets so late, and why at

Re: DSA: Suspicious RCU usage (via rtnl_bridge_getlink)

On Tue, Sep 20, 2016 at 03:38:33PM +0200, Andrew Lunn wrote: > On Tue, Sep 20, 2016 at 11:26:12AM +0100, Russell King - ARM Linux wrote: > > Issuing "bridge vlan show" on clearfog provokes a "suspicious RCU usage" > > warning from the kernel (see below). > > > > As it's illegal to schedule while

Re: UBSAN reports issue in ip_idents_reserve

On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote: > I see. So how to silent the warning? > We can replace the atomic_add_return() and use a loop around atomic_read() and atomic_cmpxhg() This would change the nice property of x86 xadd into a loop. Or we also could fallback to random

[PATCH net-next] net/vxlan: Avoid unaligned access in vxlan_build_skb()

The vxlan header is at offset (14 + 20 + 8) into the packet, so the vxh is not aligned in vxlan_build_skb. Use [get/put]_unaligned functions to modify flags and vni field in the vxh. Signed-off-by: Sowmini Varadhan --- drivers/net/vxlan.c | 10 ++ 1 files

Re: UBSAN reports issue in ip_idents_reserve

On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote: > On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote: > > > I see. So how to silent the warning? > > > > We can replace the atomic_add_return() and use a loop around > atomic_read() and atomic_cmpxhg() > > This would change the nice

[PATCH net v2] ipmr, ip6mr: return lastuse relative to now

When I introduced the lastuse member I made a subtle error because it was returned as an absolute value but that is meaningless to user-space as it doesn't allow to see how old exactly an entry is. Let's make it similar to how the bridge returns such values and make it relative to "now" (jiffies).

Re: UBSAN reports issue in ip_idents_reserve

On Tue, 2016-09-20 at 07:18 -0700, Eric Dumazet wrote: > + */ > + if (unlikely(atomic_cmpxchg(p_id, old, new) != old)) > + new = prandom_u32(); > + return new; Looks like we should return new - segs;

Re: [PATCH v2 4/6] net: ethernet: bgmac: convert to feature flags

On Tue, Sep 20, 2016 at 1:19 AM, Rafał Miłecki wrote: > On 17 August 2016 at 13:34, Rafał Miłecki wrote: >> On 8 July 2016 at 01:08, Jon Mason wrote: >>> mode = (bgmac_read(bgmac, BGMAC_DEV_STATUS) & BGMAC_DS_MM_MASK) >> >>>

[PATCH ipsec-next] xfrm: state lookup can be lockless

This is called from the packet input path, we get lock contention if many cpus handle ipsec in parallel. After recent rcu conversion it is safe to call __xfrm_state_lookup without the spinlock. Signed-off-by: Florian Westphal --- net/xfrm/xfrm_state.c | 4 ++-- 1 file changed,

Re: UBSAN reports issue in ip_idents_reserve

On Tue, 2016-09-20 at 13:36 +, David Laight wrote: > From: Eric Dumazet > > Sent: 20 September 2016 14:29 > ... > > > [ 47.565420] -2117905507 + -695755206 cannot be represented in type > > > 'int' > ... > > I do not think we have to worry here. > > > > These is best effort, and

RE: UBSAN reports issue in ip_idents_reserve

From: Eric Dumazet > Sent: 20 September 2016 14:29 ... > > [ 47.565420] -2117905507 + -695755206 cannot be represented in type 'int' ... > I do not think we have to worry here. > > These is best effort, and unfortunately atomic_t are int. Not until we compile on a cpu where int arithmetic

Re: DSA: Suspicious RCU usage (via rtnl_bridge_getlink)

On Tue, Sep 20, 2016 at 11:26:12AM +0100, Russell King - ARM Linux wrote: > Issuing "bridge vlan show" on clearfog provokes a "suspicious RCU usage" > warning from the kernel (see below). > > As it's illegal to schedule while holding the RCU read lock, there's the > possibility for this happening

<    1   2   3   4   >