Re: [PATCH net-next 2/3] cxgb4: Add PTP Hardware Clock (PHC) support

[Richard Cochran]

On Tue, Jul 04, 2017 at 04:46:21PM +0530, Atul Gupta wrote:
> +/**
> + * cxgb4_ptp_init - initialize PTP for devices which support it
> + * @adapter: board private structure
> + *
> + * This function performs the required steps for enabling PTP support.
> + */
> +void cxgb4_ptp_init(struct adapter *adapter)
> +{
> + struct timespec64 now;
> +  /* no need to create a clock device if we already have one */
> + if (!IS_ERR_OR_NULL(adapter->ptp_clock))
> + return;
> +
> + adapter->ptp_tx_skb = NULL;
> + adapter->ptp_clock_info = cxgb4_ptp_clock_info;
> + spin_lock_init(>ptp_lock);
> +
> + adapter->ptp_clock = ptp_clock_register(>ptp_clock_info,
> + >pdev->dev);
> + if (!adapter->ptp_clock) {
> + dev_err(adapter->pdev_dev,
> + "PTP %s Clock registration has failed\n", __func__);
> + return;
> + }

This is wrong.  To quote the header file:

/**
 * ptp_clock_register() - register a PTP hardware clock driver
 *
 * @info:   Structure describing the new clock.
 * @parent: Pointer to the parent device of the new clock.
 *
 * Returns a valid pointer on success or PTR_ERR on failure.  If PHC
 * support is missing at the configuration level, this function
 * returns NULL, and drivers are expected to gracefully handle that
 * case separately.
 */

As this has already been merged, please submit a patch to properly
handle both PTR_ERR and NULL.

Thanks,
Richard

Re: [PATCH v2] mrf24j40: Fix en error handling path in 'mrf24j40_probe()'

[Alan Ott]

On 07/08/2017 04:40 AM, Christophe JAILLET wrote:

If this check fails, we must release some resources as done everywhere
else in this function before returning an error code.

Signed-off-by: Christophe JAILLET 
---
V2: initialization of ret in this erro path ws missing. Stupid me!
---
 drivers/net/ieee802154/mrf24j40.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ieee802154/mrf24j40.c 
b/drivers/net/ieee802154/mrf24j40.c
index 7d334963dc08..da8683782ffc 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -1330,7 +1330,8 @@ static int mrf24j40_probe(struct spi_device *spi)
if (spi->max_speed_hz > MAX_SPI_SPEED_HZ) {
dev_warn(>dev, "spi clock above possible maximum: %d",
 MAX_SPI_SPEED_HZ);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_register_device;
}

ret = mrf24j40_hw_init(devrec);



Acked-by: Alan Ott 

Re: [PATCH net v2] samples/bpf: fix a build issue

[Lawrence Brakmo]

On 7/10/17, 2:13 PM, "Daniel Borkmann"  wrote:

On 07/10/2017 11:04 PM, Yonghong Song wrote:
> With latest net-next:
> 
> clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \
>  -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
>  -Wno-compare-distinct-pointer-types \
>  -Wno-gnu-variable-sized-type-not-at-end \
>  -Wno-address-of-packed-member -Wno-tautological-compare \
>  -Wno-unknown-warning-option \
>  -O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
> samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not 
found
>^~
> 1 error generated.
> 
>
> net has the same issue.
>
> Add support for ntohl and htonl in 
tools/testing/selftests/bpf/bpf_endian.h.
> Also move bpf_helpers.h from samples/bpf to selftests/bpf and change
> compiler include logic so that programs in samples/bpf can access the 
headers
> in selftests/bpf, but not the other way around.
>
> Signed-off-by: Yonghong Song 

LGTM, thanks!

Acked-by: Daniel Borkmann dan...@iogearbox.net

Acked-by: Lawrence Brakmo 

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Casey Leedom]

Hey Alexander,

  Okay, I understand your point regarding the "most likely scenario" being
TLPs directed upstream to the Root Complex.  But I'd still like to make sure
that we have an agreed upon API/methodology for doing Peer-to-Peer with
Relaxed Ordering and no Relaxed Ordering to the Root Complex.  I don't see
how the proposed APIs can be used in that fashion.
 
  Right now the proposed change for cxgb4 is for it to test its own PCIe
Capability Device Control[Relaxed Ordering Enable] in order to use that
information to program the Chelsio Hardware to emit/not emit upstream TLPs
with the Relaxed Ordering Attribute set.  But if we're going to have the
mixed mode situation I describe, the PCIe Capability Device Control[Relaxed
Ordering Enable] will have to be set which means that we'll be programming
the Chelsio Hardware to send upstream TLPs with Relaxed Ordering Enable to
the Root Complex which is what we were trying to avoid in the first place ...

  [[ And, as I noted on Friday evening, the currect cxgb4 Driver hardwires
 the Relaxed Ordering Enable on early dureing device probe, so that
 would minimally need to be addressed even if we decide that we don't
 ever want to support mixed mode Relaxed Ordering. ]]

  We need some method of telling the Chelsio Driver that it should/shouldn't
use Relaxed Ordering with TLPs directed at the Root Complex.  And the same
is true for a Peer PCIe Device.

  It may be that we should approach this from the completely opposite
direction and instead of having quirks which identify problematic devices,
have quirks which identify devices which would benefit from the use of
Relaxed Ordering (if the sending device supports that).  That is, assume the
using Relaxed Ordering shouldn't be done unless the target device says "I
love Relaxed Ordering TLPs" ...  In such a world, an NVMe or a Graphics
device might declare love of Relaxed Ordering and the same for a SPARC Root
Complex (I think that was your example).

  By the way, the sole example of Data Corruption with Relaxed Ordering is
the AMD A1100 ARM SoC and AMD appears to have given up on that almost as
soon as it was released.  So what we're left with currently is a performance
problem on modern Intel CPUs ...  (And hopefully we'll get a Technical
Publication on that issue fairly soon.)

Casey

Re: [PATCH iproute2 V3 0/4] RDMAtool

[Jiri Pirko]

Mon, Jul 10, 2017 at 06:01:44PM CEST, l...@kernel.org wrote:
>On Mon, Jul 10, 2017 at 10:02:30AM +0200, Jiri Pirko wrote:
>> Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote:
>> >Hi,
>> >
>> >This is third version of series implementing the RDAMtool -  the tool
>> >to configure RDMA devices. The initial proposal was sent as RFC [1] and
>> >was based on sysfs entries as POC.
>> >
>> >The current series was rewritten completely to work with RDMA netlinks as
>> >a source of user<->kernel communications. In order to achieve that, the
>> >RDMA netlinks were extensively refactored and modernized [2, 3, 4 and 5].
>> >
>> >The following is an example of various runs on my machine with 5 devices
>> >(4 in IB mode and one in Ethernet mode)
>> >
>> >### Without parameters
>> >$ rdma
>> >Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help }
>> >where  OBJECT := { dev | link | help }
>> >   OPTIONS := { -V[ersion] | -d[etails]}
>>
>> What about json output? You will need it sooner than later. It will
>> prevent you from a lot of headaches if you implement it right away.
>> Lesson learned...
>
>I'm planning to do it in the coming kernel cycle.

Yeah, just consider pushing it in this initial patchset. Makes sense and
saves you troubles. Up to you.

Re: [PATCH iproute2 V3 3/4] rdma: Add link object

[Jiri Pirko]

Mon, Jul 10, 2017 at 06:22:23PM CEST, l...@kernel.org wrote:
>On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote:
>> Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote:
>> >From: Leon Romanovsky 
>> >
>> >Link (port) object represent struct ib_port to the user space.
>> >
>> >Link properties:
>> > * Port capabilities
>> > * IB subnet prefix
>> > * LID, SM_LID and LMC
>> > * Port state
>> > * Physical state
>> >
>> >Signed-off-by: Leon Romanovsky 
>> >---
>> > rdma/Makefile |   2 +-
>> > rdma/link.c   | 280 
>> > ++
>> > rdma/rdma.c   |   3 +-
>> > rdma/utils.c  |   5 ++
>> > 4 files changed, 288 insertions(+), 2 deletions(-)
>> > create mode 100644 rdma/link.c
>> >
>> >diff --git a/rdma/Makefile b/rdma/Makefile
>> >index 123d7ac5..1a9e4b1a 100644
>> >--- a/rdma/Makefile
>> >+++ b/rdma/Makefile
>> >@@ -2,7 +2,7 @@ include ../Config
>> >
>> > ifeq ($(HAVE_MNL),y)
>> >
>> >-RDMA_OBJ = rdma.o utils.o dev.o
>> >+RDMA_OBJ = rdma.o utils.o dev.o link.o
>> >
>> > TARGETS=rdma
>> > CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
>> >diff --git a/rdma/link.c b/rdma/link.c
>> >new file mode 100644
>> >index ..f92b4cef
>> >--- /dev/null
>> >+++ b/rdma/link.c
>> >@@ -0,0 +1,280 @@
>> >+/*
>> >+ * link.c  RDMA tool
>> >+ *
>> >+ *  This program is free software; you can redistribute it 
>> >and/or
>> >+ *  modify it under the terms of the GNU General Public License
>> >+ *  as published by the Free Software Foundation; either 
>> >version
>> >+ *  2 of the License, or (at your option) any later version.
>> >+ *
>> >+ * Authors: Leon Romanovsky 
>> >+ */
>> >+
>> >+#include "rdma.h"
>> >+
>> >+static int link_help(struct rdma *rd)
>> >+{
>> >+   pr_out("Usage: %s link show [DEV/PORT_INDEX]\n", rd->filename);
>> >+   return 0;
>> >+}
>> >+
>> >+static void link_print_caps(struct nlattr **tb)
>> >+{
>> >+   uint64_t caps;
>> >+   uint32_t idx;
>> >+
>> >+   /*
>> >+* FIXME: move to indexes when kernel will start exporting them.
>>
>> Not exported yet?
>
>Not yet, I want to minimize the UAPI export from kernel before user-space
>part is accepted.

I don't get it. If you need it in userspace, you should expose it. Why
to wait? What am I missing?

[...]


>> >+   rd->port_idx = port ? :1;
>>
>> "port ? : 1"
>
>Yeah, legal C, the same as (port) ? port : 1
>ihttps://en.wikipedia.org/wiki/%3F:#C


I was referring to the missing " ". I'm a nitpicker :)

Re: meson-gxbb-p200 4.12.0 network TCP transfer stalls

[Marc Duponcheel]

 FYI

I changed 4.12.0 drivers/net/phy/realtek.c RTL8211F code to equal the
3.14.29 amlogic/ethernet/phy/am_realtek.c code and now the networking
works without TCP stalls.

I don't say below patch should be considered mainstream (as maybe some
4.12.0 rtl8211f_config_init code should not be removed) but sure
someone could figure out what best patch is...

 --
# diff -U2 realtek.c.orig realtek.c
--- realtek.c.orig  2017-07-03 01:07:02.0 +0200
+++ realtek.c   2017-07-11 01:32:20.273445023 +0200
@@ -94,28 +94,27 @@
 }
 
+#define RTL8211F_MMD_CTRL   0x0D
+#define RTL8211F_MMD_DATA   0x0E
+#define RTL8211E_INER_LINK_STAT 0x10
+
 static int rtl8211f_config_init(struct phy_device *phydev)
 {
-   int ret;
-   u16 reg;
-
-   ret = genphy_config_init(phydev);
-   if (ret < 0)
-   return ret;
-
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0xd08);
-   reg = phy_read(phydev, 0x11);
-
-   /* enable TX-delay for rgmii-id and rgmii-txid, otherwise disable it */
-   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
-   phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
-   reg |= RTL8211F_TX_DELAY;
-   else
-   reg &= ~RTL8211F_TX_DELAY;
-
-   phy_write(phydev, 0x11, reg);
-   /* restore to default page 0 */
-   phy_write(phydev, RTL8211F_PAGE_SELECT, 0x0);
-
+   int val;
+/* we want to disable eee */
+   phy_write(phydev, RTL8211F_MMD_CTRL, 0x7);
+   phy_write(phydev, RTL8211F_MMD_DATA, 0x3c);
+   phy_write(phydev, RTL8211F_MMD_CTRL, 0x4007);
+   phy_write(phydev, RTL8211F_MMD_DATA, 0x0);
+/* disable 1000m adv*/
+   val = phy_read(phydev, 0x9);
+   phy_write(phydev, 0x9, val&(~(1<<9)));
+/* rx reg 21 bit 3 tx reg 17 bit 8 */
+/*
+   phy_write(phydev, 0x1f, 0xd08);
+   val =  phy_read(phydev, 0x15);
+   phy_write(phydev, 0x15,val| 1<<21);
+ */
return 0;
+/* Enable Auto Power Saving mode */
 }
 
@@ -167,6 +166,6 @@
.name   = "RTL8211F Gigabit Ethernet",
.phy_id_mask= 0x001f,
-   .features   = PHY_GBIT_FEATURES,
-   .flags  = PHY_HAS_INTERRUPT,
+   .features   = PHY_GBIT_FEATURES | SUPPORTED_Pause | 
SUPPORTED_Asym_Pause,
+   .flags  = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,
.config_aneg= _config_aneg,
 --


On 2017 Jul 08, Marc Duponcheel wrote:
> Hi all
> 
> Similar to 'crow'
> 
> ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after 
> some traffic
> 
> I also have the situation where copying large file over LAN stalls.
> 
> 3.14.29 performance is good 4.12.0 performance not
> 
> 
>  Perhaps one must compare 3.14.29 am_realtek.c and realtek.c with 4.12.0 
> realtek.c
> 
> 
>  thanks

have a nice day

Re: [PATCH net] ip[6]: don't register inet[6]dev when dev is down

[Nicolas Dichtel]

Le 08/07/2017 à 20:44, Cong Wang a écrit :
> On Sat, Jul 8, 2017 at 3:02 AM, David Miller  wrote:
[snip]
>> Can you show exactly why the procfs state isn't cleaned up for
>> these devices moving between namespaces?  Maybe that is the real
>> bug and a better place to fix this.
>>
> 
> It is because the ipv6_add_dev() adds these proc files back after
> NETDEV_UNREGISTER event.
> 
Yep, that was the initial problem.


Regards,
Nicolas

RE: [PATCH 00/17] v3 net generic subsystem refcount conversions

[Reshetova, Elena]

> On Mon, Jul 03, 2017 at 02:28:56AM -0700, Eric Dumazet wrote:
> >On Fri, 2017-06-30 at 13:07 +0300, Elena Reshetova wrote:
> >> Changes in v3:
> >> Rebased on top of the net-next tree.
> >>
> >> Changes in v2:
> >> No changes in patches apart from rebases, but now by
> >> default refcount_t = atomic_t (*) and uses all atomic standard operations
> >> unless CONFIG_REFCOUNT_FULL is enabled. This is a compromise for the
> >> systems that are critical on performance (such as net) and cannot accept 
> >> even
> >> slight delay on the refcounter operations.
> >>
> >> This series, for core network subsystem components, replaces atomic_t
> reference
> >> counters with the new refcount_t type and API (see
> include/linux/refcount.h).
> >> By doing this we prevent intentional or accidental
> >> underflows or overflows that can led to use-after-free vulnerabilities.
> >> These patches contain only generic net pieces. Other changes will be sent
> separately.
> >>
> >> The patches are fully independent and can be cherry-picked separately.
> >> The big patches, such as conversions for sock structure, need a very 
> >> detailed
> >> look from maintainers: refcount managing is quite complex in them and while
> >> it seems that they would benefit from the change, extra checking is needed.
> >> The biggest corner issue is the fact that refcount_inc() does not increment
> >> from zero.
> >>
> >> If there are no objections to the patches, please merge them via respective
> trees.
> >>
> >> * The respective change is currently merged into -next as
> >>   "locking/refcount: Create unchecked atomic_t implementation".
> >>
> >> Elena Reshetova (17):
> >>   net: convert inet_peer.refcnt from atomic_t to refcount_t
> >>   net: convert neighbour.refcnt from atomic_t to refcount_t
> >>   net: convert neigh_params.refcnt from atomic_t to refcount_t
> >>   net: convert nf_bridge_info.use from atomic_t to refcount_t
> >>   net: convert sk_buff.users from atomic_t to refcount_t
> >>   net: convert sk_buff_fclones.fclone_ref from atomic_t to refcount_t
> >>   net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
> >>   net: convert sock.sk_refcnt from atomic_t to refcount_t
> >>   net: convert ip_mc_list.refcnt from atomic_t to refcount_t
> >>   net: convert in_device.refcnt from atomic_t to refcount_t
> >>   net: convert netpoll_info.refcnt from atomic_t to refcount_t
> >>   net: convert unix_address.refcnt from atomic_t to refcount_t
> >>   net: convert fib_rule.refcnt from atomic_t to refcount_t
> >>   net: convert inet_frag_queue.refcnt from atomic_t to refcount_t
> >>   net: convert net.passive from atomic_t to refcount_t
> >>   net: convert netlbl_lsm_cache.refcount from atomic_t to refcount_t
> >>   net: convert packet_fanout.sk_ref from atomic_t to refcount_t
> >
> >
> >Can you take a look at this please ?
> >
> >[   64.601749] [ cut here ]
> >[   64.601757] WARNING: CPU: 0 PID: 6476 at lib/refcount.c:184
> refcount_sub_and_test+0x75/0xa0
> >[   64.601758] Modules linked in: w1_therm wire cdc_acm ehci_pci ehci_hcd
> mlx4_en ib_uverbs mlx4_ib ib_core mlx4_core
> >[   64.601769] CPU: 0 PID: 6476 Comm: ip Tainted: GW   
> >4.12.0-smp-DEV
> #274
> >[   64.601770] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.40.0
> 06/22/2016
> >[   64.601771] task: 8837bf482040 task.stack: 8837bdc08000
> >[   64.601773] RIP: 0010:refcount_sub_and_test+0x75/0xa0
> >[   64.601774] RSP: 0018:8837bdc0f5c0 EFLAGS: 00010286
> >[   64.601776] RAX: 0026 RBX: 0001 RCX:
> 
> >[   64.601777] RDX: 0026 RSI: 0096 RDI:
> ed06f7b81eae
> >[   64.601778] RBP: 8837bdc0f5d0 R08: 0004 R09:
> fbfff4a54c25
> >[   64.601779] R10: cbc500e5 R11: a52a6128 R12: 
> >881febcf6f24
> >[   64.601779] R13: 881fbf4eaf00 R14: 881febcf6f80 R15: 
> >8837d7a4ed00
> >[   64.601781] FS:  7ff5a2f6b700() GS:881fff80()
> knlGS:
> >[   64.601782] CS:  0010 DS:  ES:  CR0: 80050033
> >[   64.601783] CR2: 7ffcdc70d000 CR3: 001f9c91e000 CR4:
> 001406f0
> >[   64.601783] Call Trace:
> >[   64.601786]  refcount_dec_and_test+0x11/0x20
> >[   64.601790]  fib_nl_delrule+0xc39/0x1630
> [snip]
> 
> I'm seeing a similar one coming from sctp:
> 
> refcount_t: underflow; use-after-free.
> [ cut here ]
> WARNING: CPU: 3 PID: 15570 at lib/refcount.c:186
> refcount_sub_and_test.cold.13+0x18/0x21 lib/refcount.c:186
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 3 PID: 15570 Comm: syz-executor0 Not tainted 4.12.0-next-20170706+ #186
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1
> 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x11d/0x1ef lib/dump_stack.c:52
>  panic+0x1bc/0x3ad kernel/panic.c:180
>  __warn.cold.6+0x2f/0x2f kernel/panic.c:541
>  

Re: [PATCH iproute2 V3 0/4] RDMAtool

[Jiri Pirko]

Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote:
>Hi,
>
>This is third version of series implementing the RDAMtool -  the tool

s/RDAMtool/RDMAtool/


>to configure RDMA devices. The initial proposal was sent as RFC [1] and
>was based on sysfs entries as POC.
>
>The current series was rewritten completely to work with RDMA netlinks as
>a source of user<->kernel communications. In order to achieve that, the
>RDMA netlinks were extensively refactored and modernized [2, 3, 4 and 5].
>
>The following is an example of various runs on my machine with 5 devices
>(4 in IB mode and one in Ethernet mode)
>
>### Without parameters
>$ rdma
>Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help }
>where  OBJECT := { dev | link | help }
>   OPTIONS := { -V[ersion] | -d[etails]}

Do you plan to add "mon" any time soon?

Re: [PATCH 1/2] netdevice: add netdev_pub helper function

[David Miller]

From: "Jason A. Donenfeld" 
Date: Mon, 10 Jul 2017 05:19:58 +0200

> Being able to utilize this makes code a lot simpler and cleaner. It's
> easier in many cases for drivers to pass around their private data
> structure, while occationally needing to dip into net_device, rather
> than the other way around, which results in tons of calls to netdev_priv
> in the top of every single function, which makes everything confusing
> and less clear. Additionally, this enables a "correct" way of doing such
> a thing, instead of having drivers attempt to reinvent the wheel and
> screw it up.
> 
> Signed-off-by: Jason A. Donenfeld 

I disagree.  Assuming one can go from the driver private to the netdev
object trivially is a worse assumption than the other way around, and
locks us into the current implementation of how the netdev and driver
private memory is allocated.

If you want to style your driver such that the private is passed
around instead of the netdev, put a pointer back to the netdev object
in your private data structure.

Which is exactly what the ioc3-eth driver ought to be doing.

[PATCH] net: can: at91_can: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6164 304   064681944 drivers/net/can/at91_can.o

File size After adding 'const':
   textdata bss dec hex filename
   6228 240   064681944 drivers/net/can/at91_can.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/can/at91_can.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index 0e0df0b..f37ce0e 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -1232,7 +1232,7 @@ static DEVICE_ATTR(mb0_id, S_IWUSR | S_IRUGO,
NULL,
 };
 
-static struct attribute_group at91_sysfs_attr_group = {
+static const struct attribute_group at91_sysfs_attr_group = {
.attrs = at91_sysfs_attrs,
 };
 
-- 
1.9.1

RE: [PATCH v 1/2] ravb: Add support for r8a7743 SoC

[Biju Das]

Hello,

Thanks for the review.

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 10 July 2017 02:20
> To: Biju Das 
> Cc: Mark Rutland ; Russell King
> ; Sergei Shtylyov
> ; Simon Horman
> ; Magnus Damm ; Chris
> Paterson ; devicet...@vger.kernel.org; linux-
> renesas-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> netdev@vger.kernel.org
> Subject: Re: [PATCH v 1/2] ravb: Add support for r8a7743 SoC
>
> On Wed, Jul 05, 2017 at 02:01:50PM +0100, Biju Das wrote:
> > Add support for Gigabit Ethernet E-MAC on r8a7743 (RZ/G1M) SoC.
> > Renesas RZ/G1M (R8A7743) SoC Ethernet AVB IP is identical to the R-Car
> > Gen2 family.
>
> For the subject: "dt-bindings: net: ..."

I will change the subject to "dt-bindings: net: ravb: ..

>
> >
> > Signed-off-by: Biju Das 
> > Reviewed-by: Chris Paterson 
> > ---
> >  Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
> >  drivers/net/ethernet/renesas/ravb_main.c   | 1 +
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > index b519503..bc692ab 100644
> > --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> > @@ -4,7 +4,8 @@ This file provides information on what the device node
> > for the Ethernet AVB  interface contains.
> >
> >  Required properties:
> > -- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790
> SoC.
> > +- compatible: "renesas,etheravb-r8a7743" if the device is a part of R8A7743
> SoC.
> > +  "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC.
>
> Please re-format like this:
>
> - compatible: Must be one of:
> ...
>
Ok. I will change this as well.

> So it's a one line change to add new compatibles.
>
> >"renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC.
> >"renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC.
> >"renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC.
> > diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> > b/drivers/net/ethernet/renesas/ravb_main.c
> > index 5931e85..e35b30f 100644
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -1869,6 +1869,7 @@ static int ravb_mdio_release(struct ravb_private
> > *priv)  }
> >
> >  static const struct of_device_id ravb_match_table[] = {
> > +{ .compatible = "renesas,etheravb-r8a7743", .data = (void
> > +*)RCAR_GEN2 },
> >  { .compatible = "renesas,etheravb-r8a7790", .data = (void
> *)RCAR_GEN2 },
> >  { .compatible = "renesas,etheravb-r8a7794", .data = (void
> *)RCAR_GEN2 },
> >  { .compatible = "renesas,etheravb-rcar-gen2", .data = (void
> > *)RCAR_GEN2 },
> > --
> > 1.9.1
> >



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH net] ip[6]: don't register inet[6]dev when dev is down

[Nicolas Dichtel]

Le 08/07/2017 à 20:56, Cong Wang a écrit :
> On Fri, Jul 7, 2017 at 5:39 AM, Nicolas Dichtel
>  wrote:
[snip]
>>  - the patch is easy to backport in older kernel.
>>
> 
> Easy to backport doesn't mean easy to verify. ;) As David said, this
> code is mess, especially for the keep_addr_on_down logic.
> 
Yes sure. Let's live with your patch.


Thank you,
Nicolas

Re: [PATCH v2 2/2] ARM: shmobile: defconfig: Enable Ethernet AVB

[Simon Horman]

On Thu, Jul 06, 2017 at 08:05:43AM +, Chris Paterson wrote:
> Hello Sergei, 
> 
> Thank you for your comments.
> 
> > From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> > Sent: 05 July 2017 17:14
> > 
> > Hello!
> > 
> > On 07/05/2017 06:56 PM, Biju Das wrote:
> > 
> > > The iWave RZ/G1M Q7 SOM supports Gigabit Ethernet Phy (Micrel
> > KSZ9031MNX).
> > > Gigabit Ethernet support is available in Renesas AVB driver.
> > > To increase hardware support enable the driver in the
> > > shmobile_defconfig multiplatform configuration.
> > >
> > > Signed-off-by: Biju Das 
> > > Reviewed-by: Chris Paterson 
> > > Acked-by: Geert Uytterhoeven 
> > > ---
> > >  arch/arm/configs/shmobile_defconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/configs/shmobile_defconfig
> > > b/arch/arm/configs/shmobile_defconfig
> > > index 3c66a42..d992911 100644
> > > --- a/arch/arm/configs/shmobile_defconfig
> > > +++ b/arch/arm/configs/shmobile_defconfig
> > > @@ -83,6 +83,7 @@ CONFIG_NETDEVICES=y
> > >  # CONFIG_NET_VENDOR_MICREL is not set  #
> > CONFIG_NET_VENDOR_NATSEMI is
> > > not set  CONFIG_SH_ETH=y
> > > +CONFIG_RAVB=y
> > 
> > Hm, I would enable it only as a module, given it's not easy to make use 
> > of
> > AVB on the 32-bit boards.
> 
> On the iWave-M platforms the only available Ethernet interface is AVB.
> Without including the RAVB driver in the Kernel we won't be able to use
> NFS.
> 
> I know adding CONFIG_RAVB for all shmobile devices may increase the
> Kernel size for everyone, especially when most cannot use AVB without an
> add-on board, but I don't think the increase will be big.

Thanks for the explanation, applied for v4.14.

[PATCH] net: usb: qmi_wwan: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  16831 464   0   17295438f drivers/net/usb/qmi_wwan.o

File size After adding 'const':
   textdata bss dec hex filename
  16895 400   0   17295438f drivers/net/usb/qmi_wwan.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/qmi_wwan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 5894e3c..b2ddd5c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -434,7 +434,7 @@ static ssize_t del_mux_store(struct device *d,  struct 
device_attribute *attr, c
NULL,
 };
 
-static struct attribute_group qmi_wwan_sysfs_attr_group = {
+static const struct attribute_group qmi_wwan_sysfs_attr_group = {
.name = "qmi",
.attrs = qmi_wwan_sysfs_attrs,
 };
-- 
1.9.1

Re: [PATCH iproute2 V3 2/4] rdma: Add dev object

[Jiri Pirko]

Tue, Jul 04, 2017 at 09:55:39AM CEST, l...@kernel.org wrote:
>From: Leon Romanovsky 
>
>Device (dev) object represents struct ib_device to the user space.
>
>Device properties:
> * Device capabilities
> * FW version to the device output
> * node_guid and sys_image_guid
> * node_type
>
>Signed-off-by: Leon Romanovsky 
>---
> rdma/Makefile |   2 +-
> rdma/dev.c| 235 ++
> rdma/rdma.c   |   3 +-
> rdma/rdma.h   |  12 ++-
> rdma/utils.c  |  46 +++-
> 5 files changed, 293 insertions(+), 5 deletions(-)
> create mode 100644 rdma/dev.c
>
>diff --git a/rdma/Makefile b/rdma/Makefile
>index 64da2142..123d7ac5 100644
>--- a/rdma/Makefile
>+++ b/rdma/Makefile
>@@ -2,7 +2,7 @@ include ../Config
>
> ifeq ($(HAVE_MNL),y)
>
>-RDMA_OBJ = rdma.o utils.o
>+RDMA_OBJ = rdma.o utils.o dev.o
>
> TARGETS=rdma
> CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
>diff --git a/rdma/dev.c b/rdma/dev.c
>new file mode 100644
>index ..b80e5288
>--- /dev/null
>+++ b/rdma/dev.c
>@@ -0,0 +1,235 @@
>+/*
>+ * dev.c  RDMA tool
>+ *
>+ *  This program is free software; you can redistribute it and/or
>+ *  modify it under the terms of the GNU General Public License
>+ *  as published by the Free Software Foundation; either version
>+ *  2 of the License, or (at your option) any later version.
>+ *
>+ * Authors: Leon Romanovsky 
>+ */
>+
>+#include "rdma.h"
>+
>+static int dev_help(struct rdma *rd)
>+{
>+  pr_out("Usage: %s dev show [DEV]\n", rd->filename);
>+  return 0;
>+}
>+
>+static void dev_print_caps(struct nlattr **tb)
>+{
>+  uint64_t caps;
>+  uint32_t idx;
>+
>+  /*
>+   * FIXME: move to indexes when kernel will start exporting them.
>+   */
>+  static const char *dev_caps[64] = {

static const char *dev_caps[] = {


>+  "RESIZE_MAX_WR",
>+  "BAD_PKEY_CNTR",
>+  "BAD_QKEY_CNTR",
>+  "RAW_MULTI",
>+  "AUTO_PATH_MIG",
>+  "CHANGE_PHY_PORT",
>+  "UD_AV_PORT_ENFORCE",
>+  "CURR_QP_STATE_MOD",
>+  "SHUTDOWN_PORT",
>+  "INIT_TYPE",
>+  "PORT_ACTIVE_EVENT",
>+  "SYS_IMAGE_GUID",
>+  "RC_RNR_NAK_GEN",
>+  "SRQ_RESIZE",
>+  "N_NOTIFY_CQ",
>+  "LOCAL_DMA_LKEY",
>+  "RESERVED",
>+  "MEM_WINDOW",
>+  "UD_IP_CSUM",
>+  "UD_TSO",
>+  "XRC",
>+  "MEM_MGT_EXTENSIONS",
>+  "BLOCK_MULTICAST_LOOPBACK",
>+  "MEM_WINDOW_TYPE_2A",
>+  "MEM_WINDOW_TYPE_2B",
>+  "RC_IP_CSUM",
>+  "RAW_IP_CSUM",
>+  "CROSS_CHANNEL",
>+  "MANAGED_FLOW_STEERING",
>+  "SIGNATURE_HANDOVER",
>+  "ON_DEMAND_PAGING",
>+  "SG_GAPS_REG",
>+  "VIRTUAL_FUNCTION",
>+  "RAW_SCATTER_FCS",
>+  "RDMA_NETDEV_OPA_VNIC",
>+  };
>+
>+  if (!tb[RDMA_NLDEV_ATTR_CAP_FLAGS])
>+ return;
>+
>+  caps = mnl_attr_get_u64(tb[RDMA_NLDEV_ATTR_CAP_FLAGS]);
>+
>+  pr_out("\ncaps: <");
>+  for (idx = 0; idx < 64; idx++) {
>+  if (caps & 0x1) {
>+  pr_out("%s", dev_caps[idx]?dev_caps[idx]:"UNKNONW");
>+  if (caps >> 0x1)
>+  pr_out(", ");
>+  }
>+  caps >>= 0x1;
>+  }
>+
>+  pr_out(">");
>+}
>+
>+static void dev_print_fw(struct nlattr **tb)
>+{
>+  if (!tb[RDMA_NLDEV_ATTR_FW_VERSION])
>+  return;
>+
>+  pr_out("fw %s ",
>+ mnl_attr_get_str(tb[RDMA_NLDEV_ATTR_FW_VERSION]));
>+}
>+
>+static void _dev_print_be64(char *name, uint64_t val)

Why the initial "_"? I think it could be avoided.

Wait, I'm confused. Does kernel actually exposes BE64 in U64 attribute?
That is wrong. Please fix it while there is still a time (if it is).


>+{
>+  uint16_t vp[4];
>+
>+  memcpy(vp, , sizeof(uint64_t));
>+  pr_out("%s %04x:%04x:%04x:%04x ", name, vp[3], vp[2], vp[1], vp[0]);
>+}
>+
>+static void dev_print_node_guid(struct nlattr **tb)
>+{
>+  uint64_t node_guid;
>+
>+  if (!tb[RDMA_NLDEV_ATTR_NODE_GUID])
>+  return;
>+
>+  node_guid = mnl_attr_get_u64(tb[RDMA_NLDEV_ATTR_NODE_GUID]);
>+  _dev_print_be64("node_guid", node_guid);
>+}
>+
>+static void dev_print_sys_image_guid(struct nlattr **tb)
>+{
>+   uint64_t   sys_image_guid;
>+
>+  if (!tb[RDMA_NLDEV_ATTR_SYS_IMAGE_GUID])
>+  return;
>+
>+  sys_image_guid = mnl_attr_get_u64(tb[RDMA_NLDEV_ATTR_SYS_IMAGE_GUID]);
>+  _dev_print_be64("sys_image_guid", sys_image_guid);
>+}
>+
>+static void dev_print_node_type(struct nlattr **tb)
>+{
>+  uint8_t node_type;
>+  /*
>+   * FIXME: move 

Re: [PATCH iproute2 V3 3/4] rdma: Add link object

[Leon Romanovsky]

On Mon, Jul 10, 2017 at 10:13:07AM +0200, Jiri Pirko wrote:
> Tue, Jul 04, 2017 at 09:55:40AM CEST, l...@kernel.org wrote:
> >From: Leon Romanovsky 
> >
> >Link (port) object represent struct ib_port to the user space.
> >
> >Link properties:
> > * Port capabilities
> > * IB subnet prefix
> > * LID, SM_LID and LMC
> > * Port state
> > * Physical state
> >
> >Signed-off-by: Leon Romanovsky 
> >---
> > rdma/Makefile |   2 +-
> > rdma/link.c   | 280 
> > ++
> > rdma/rdma.c   |   3 +-
> > rdma/utils.c  |   5 ++
> > 4 files changed, 288 insertions(+), 2 deletions(-)
> > create mode 100644 rdma/link.c
> >
> >diff --git a/rdma/Makefile b/rdma/Makefile
> >index 123d7ac5..1a9e4b1a 100644
> >--- a/rdma/Makefile
> >+++ b/rdma/Makefile
> >@@ -2,7 +2,7 @@ include ../Config
> >
> > ifeq ($(HAVE_MNL),y)
> >
> >-RDMA_OBJ = rdma.o utils.o dev.o
> >+RDMA_OBJ = rdma.o utils.o dev.o link.o
> >
> > TARGETS=rdma
> > CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
> >diff --git a/rdma/link.c b/rdma/link.c
> >new file mode 100644
> >index ..f92b4cef
> >--- /dev/null
> >+++ b/rdma/link.c
> >@@ -0,0 +1,280 @@
> >+/*
> >+ * link.c   RDMA tool
> >+ *
> >+ *  This program is free software; you can redistribute it 
> >and/or
> >+ *  modify it under the terms of the GNU General Public License
> >+ *  as published by the Free Software Foundation; either version
> >+ *  2 of the License, or (at your option) any later version.
> >+ *
> >+ * Authors: Leon Romanovsky 
> >+ */
> >+
> >+#include "rdma.h"
> >+
> >+static int link_help(struct rdma *rd)
> >+{
> >+pr_out("Usage: %s link show [DEV/PORT_INDEX]\n", rd->filename);
> >+return 0;
> >+}
> >+
> >+static void link_print_caps(struct nlattr **tb)
> >+{
> >+uint64_t caps;
> >+uint32_t idx;
> >+
> >+/*
> >+ * FIXME: move to indexes when kernel will start exporting them.
>
> Not exported yet?

Not yet, I want to minimize the UAPI export from kernel before user-space
part is accepted.

>
>
>
> >+ */
> >+static const char *link_caps[64] = {
>
> []

It will require from me to fill all 64 fields.
In current version, I'm leveraging the fact that static is initialized
to zero (NULL).

>
>
> >+"UNKNOWN",
> >+"SM",
> >+"NOTICE",
> >+"TRAP",
> >+"OPT_IPD",
> >+"AUTO_MIGR",
> >+"SL_MAP",
> >+"MKEY_NVRAM",
> >+"PKEY_NVRAM",
> >+"LED_INFO",
> >+"SM_DISABLED",
> >+"SYS_IMAGE_GUID",
> >+"PKEY_SW_EXT_PORT_TRAP",
> >+"UNKNOWN",
> >+"EXTENDED_SPEEDS",
> >+"UNKNOWN",
> >+"CM",
> >+"SNMP_TUNNEL",
> >+"REINIT",
> >+"DEVICE_MGMT",
> >+"VENDOR_CLASS",
> >+"DR_NOTICE",
> >+"CAP_MASK_NOTICE",
> >+"BOOT_MGMT",
> >+"LINK_LATENCY",
> >+"CLIENT_REG",
> >+"IP_BASED_GIDS",
> >+};
> >+
> >+if (!tb[RDMA_NLDEV_ATTR_CAP_FLAGS])
> >+return;
> >+
> >+caps = mnl_attr_get_u64(tb[RDMA_NLDEV_ATTR_CAP_FLAGS]);
> >+
> >+pr_out("\ncaps: <");
> >+for (idx = 0; idx < 64; idx++) {
> >+if (caps & 0x1) {
> >+pr_out("%s", link_caps[idx]?link_caps[idx]:"UNKNONW");
>
> "link_caps[idx] ? link_caps[idx] : "UNKNOWN""
>
> note the s/UNKNONW/UNKNOWN/

Right

>
>
> >+if (caps >> 0x1)
> >+pr_out(", ");
> >+}
> >+caps >>= 0x1;
>
> Interesting.
>
>
> >+}
> >+
> >+pr_out(">");
> >+}
> >+
> >+static void link_print_subnet_prefix(struct nlattr **tb)
> >+{
> >+uint64_t subnet_prefix;
> >+uint16_t sp[4];
> >+
> >+if (!tb[RDMA_NLDEV_ATTR_SUBNET_PREFIX])
> >+return;
> >+
> >+subnet_prefix = mnl_attr_get_u64(tb[RDMA_NLDEV_ATTR_SUBNET_PREFIX]);
> >+memcpy(sp, _prefix, sizeof(uint64_t));
> >+pr_out("subnet_prefix %04x:%04x:%04x:%04x ", sp[3], sp[2], sp[1], 
> >sp[0]);
>
> You have similar pr_out helper in the previous patch. Perhaps you can
> re-use it?

Sure

>
>
> >+}
> >+
> >+static void link_print_lid(struct nlattr **tb)
> >+{
> >+if (!tb[RDMA_NLDEV_ATTR_LID])
> >+return;
> >+
> >+pr_out("lid %u ",
> >+   mnl_attr_get_u32(tb[RDMA_NLDEV_ATTR_LID]));
> >+}
> >+
> >+static void link_print_sm_lid(struct nlattr **tb)
> >+{
> >+
>
> Avoid the extra empty line.
>

Will remove

>
> >+if (!tb[RDMA_NLDEV_ATTR_SM_LID])
> >+return;
> >+
> >+pr_out("sm_lid %u ",
> >+   mnl_attr_get_u32(tb[RDMA_NLDEV_ATTR_SM_LID]));
> >+}
> >+
> >+static void link_print_lmc(struct nlattr **tb)
> >+{
> >+if (!tb[RDMA_NLDEV_ATTR_LMC])
> >+return;
> >+
> >+pr_out("lmc %u ", 

[RESEND PATCH net] tap: convert a mutex to a spinlock

[Cong Wang]

We are not allowed to block on the RCU reader side, so can't
just hold the mutex as before. As a quick fix, convert it to
a spinlock.

Fixes: d9f1f61c0801 ("tap: Extending tap device create/destroy APIs")
Reported-by: Christian Borntraeger 
Tested-by: Christian Borntraeger 
Cc: Sainath Grandhi 
Signed-off-by: Cong Wang 
---
 drivers/net/tap.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 9af3239..3570c75 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -106,7 +106,7 @@ struct major_info {
struct rcu_head rcu;
dev_t major;
struct idr minor_idr;
-   struct mutex minor_lock;
+   spinlock_t minor_lock;
const char *device_name;
struct list_head next;
 };
@@ -416,15 +416,15 @@ int tap_get_minor(dev_t major, struct tap_dev *tap)
goto unlock;
}
 
-   mutex_lock(_major->minor_lock);
-   retval = idr_alloc(_major->minor_idr, tap, 1, TAP_NUM_DEVS, 
GFP_KERNEL);
+   spin_lock(_major->minor_lock);
+   retval = idr_alloc(_major->minor_idr, tap, 1, TAP_NUM_DEVS, 
GFP_ATOMIC);
if (retval >= 0) {
tap->minor = retval;
} else if (retval == -ENOSPC) {
netdev_err(tap->dev, "Too many tap devices\n");
retval = -EINVAL;
}
-   mutex_unlock(_major->minor_lock);
+   spin_unlock(_major->minor_lock);
 
 unlock:
rcu_read_unlock();
@@ -442,12 +442,12 @@ void tap_free_minor(dev_t major, struct tap_dev *tap)
goto unlock;
}
 
-   mutex_lock(_major->minor_lock);
+   spin_lock(_major->minor_lock);
if (tap->minor) {
idr_remove(_major->minor_idr, tap->minor);
tap->minor = 0;
}
-   mutex_unlock(_major->minor_lock);
+   spin_unlock(_major->minor_lock);
 
 unlock:
rcu_read_unlock();
@@ -467,13 +467,13 @@ static struct tap_dev *dev_get_by_tap_file(int major, int 
minor)
goto unlock;
}
 
-   mutex_lock(_major->minor_lock);
+   spin_lock(_major->minor_lock);
tap = idr_find(_major->minor_idr, minor);
if (tap) {
dev = tap->dev;
dev_hold(dev);
}
-   mutex_unlock(_major->minor_lock);
+   spin_unlock(_major->minor_lock);
 
 unlock:
rcu_read_unlock();
@@ -1244,7 +1244,7 @@ static int tap_list_add(dev_t major, const char 
*device_name)
tap_major->major = MAJOR(major);
 
idr_init(_major->minor_idr);
-   mutex_init(_major->minor_lock);
+   spin_lock_init(_major->minor_lock);
 
tap_major->device_name = device_name;
 
-- 
2.5.5

Re: [RFC PATCH 10/12] xdp: Add batching support to redirect map

[Jesper Dangaard Brouer]

On Fri, 07 Jul 2017 10:37:59 -0700
John Fastabend  wrote:

> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index 36dc13de..656e334 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
[...]
>  
> +void __dev_map_insert_ctx(struct bpf_map *map, u32 key)
> +{
> + struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
> + unsigned long *bitmap = this_cpu_ptr(dtab->flush_needed);
> +
> + set_bit(key, bitmap);
> +}

I don't like that this adds an atomic op (set_bit) per packet on a fast-path.
It shows up on a perf top #6 with xdp_redirect_map.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

[David Miller]

From: Arnd Bergmann 
Date: Mon, 10 Jul 2017 11:37:51 +0200

> The new IPSec offload code introduced a build error:
> 
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function 
> `mlx5e_ipsec_build_inverse_table':
> ipsec_rxtx.c:(.text+0x556): undefined reference
> 
> Another patch was added on top to fix the build error, but
> that introduced a new bug, as we now use the remainder of
> the division rather than the result.
> 
> This makes it use the correct helper function instead.
> 
> Fixes: 5dfd87b67cd9 ("net/mlx5: IPSec, Fix 64-bit division on 32-bit builds")
> Fixes: 2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data 
> path")
> Signed-off-by: Arnd Bergmann 

Applied, thanks.

[patch net-next RFC 0/4] net: sched: allow qdiscs to share filter block instances

[Jiri Pirko]

From: Jiri Pirko 

Currently the filters added to qdiscs are independent. So for example if you
have 2 netdevices and you create ingress qdisc on both and you want to add
identical filter rules both, you need to add them twice. This patchset
makes this easier and mainly saves resources allowing to share all filters
within a qdisc - I call it a "filter block". Also this helps to save
resources when we do offload to hw for example to expensive TCAM.

So back to the example. First, we create 2 qdiscs. Both will share
block number 22. "22" is just an identification. If we don't pass any
block number, a new one will be generated by kernel:

$ tc qdisc add dev ens7 ingress block 22

$ tc qdisc add dev ens8 ingress block 22


Now if we list the qdiscs, we will see the block index in the output:
qdisc fq_codel 0: dev ens7 root refcnt 2 limit 10240p flows 1024 quantum 1514 
target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 9014 bytes 99 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc ingress : dev ens7 parent :fff1 block 22 
  
 Sent 4592 bytes 58 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
qdisc fq_codel 0: dev ens8 root refcnt 2 limit 10240p flows 1024 quantum 1514 
target 5.0ms interval 100.0ms memory_limit 32Mb ecn 
 Sent 17022 bytes 307 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
  maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
  new_flows_len 0 old_flows_len 0
qdisc ingress : dev ens8 parent :fff1 block 22 
  
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 


Now we can add filter to any of qdiscs sharing the same block:

$ tc filter add dev ens7 parent : protocol ip pref 25 flower dst_ip 
192.168.0.0/16 action drop


We will see the same output if we list filters for ens7 and ens8, including 
stats:

$ tc -s filter show dev ens7 root
filter parent : protocol ip pref 25 flower 
filter parent : protocol ip pref 25 flower handle 0x1 
  eth_type ipv4
  dst_ip 192.168.1.0/24
action order 1: gact action drop
 random type none pass val 0
 index 3 ref 1 bind 1 installed 10201 sec used 10150 sec
Action statistics:
Sent 4200 bytes 50 pkt (dropped 50, overlimits 0 requeues 0) 
backlog 0b 0p requeues 0 

$ tc -s filter show dev ens8 root
filter dev ens7 parent : protocol ip pref 25 flower 
filter dev ens7 parent : protocol ip pref 25 flower handle 0x1 
  eth_type ipv4
  dst_ip 192.168.1.0/24
action order 1: gact action drop
 random type none pass val 0
 index 3 ref 1 bind 1 installed 10202 sec used 10152 sec
Action statistics:
Sent 4200 bytes 50 pkt (dropped 50, overlimits 0 requeues 0) 
backlog 0b 0p requeues 0 


Issues:
- tp->q is set by the device used to add the filter. That has to be resolved.
  Impacts the dump (as you can see above)

Jiri Pirko (4):
  net: sched: introduce support for multiple filter chain pointers
registration
  net: sched: intruduce qdisc_net helper
  net: sched: introduce shared filter blocks infrastructure
  net: sched: allow ingress and clsact qdiscs to share filter blocks

 include/net/pkt_cls.h  |  22 +++-
 include/net/pkt_sched.h|   7 ++
 include/net/sch_generic.h  |   4 +-
 include/uapi/linux/pkt_sched.h |  12 +++
 net/sched/cls_api.c| 240 +
 net/sched/sch_ingress.c| 107 --
 6 files changed, 362 insertions(+), 30 deletions(-)

-- 
2.9.3

[patch net-next RFC 4/4] net: sched: allow ingress and clsact qdiscs to share filter blocks

[Jiri Pirko]

From: Jiri Pirko 

Benefit from the previously introduced shared filter blocks
infrastructure and allow ingress and clsact qdisc instances to share
filter blocks. The block index is coming from userspace as qdisc option.

Signed-off-by: Jiri Pirko 
---
 include/uapi/linux/pkt_sched.h |  12 +
 net/sched/sch_ingress.c| 107 ++---
 2 files changed, 112 insertions(+), 7 deletions(-)

diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index 099bf55..a684087 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -871,4 +871,16 @@ struct tc_pie_xstats {
__u32 maxq; /* maximum queue size */
__u32 ecn_mark; /* packets marked with ecn*/
 };
+
+/* Ingress/clsact */
+
+enum {
+   TCA_CLSACT_UNSPEC,
+   TCA_CLSACT_INGRESS_BLOCK,
+   TCA_CLSACT_EGRESS_BLOCK,
+   __TCA_CLSACT_MAX
+};
+
+#define TCA_CLSACT_MAX (__TCA_CLSACT_MAX - 1)
+
 #endif
diff --git a/net/sched/sch_ingress.c b/net/sched/sch_ingress.c
index d8a9beb..f18b257 100644
--- a/net/sched/sch_ingress.c
+++ b/net/sched/sch_ingress.c
@@ -58,13 +58,42 @@ static struct tcf_block *ingress_tcf_block(struct Qdisc 
*sch, unsigned long cl)
return q->block;
 }
 
+static const struct nla_policy ingress_policy[TCA_CLSACT_MAX + 1] = {
+   [TCA_CLSACT_INGRESS_BLOCK]  = { .type = NLA_U32 },
+};
+
+static int ingress_parse_opt(struct nlattr *opt, u32 *p_ingress_block_index)
+{
+   struct nlattr *tb[TCA_CLSACT_MAX + 1];
+   int err;
+
+   *p_ingress_block_index = 0;
+
+   if (!opt)
+   return 0;
+   err = nla_parse_nested(tb, TCA_CLSACT_MAX, opt, ingress_policy, NULL);
+   if (err)
+   return err;
+
+   if (tb[TCA_CLSACT_INGRESS_BLOCK])
+   *p_ingress_block_index =
+   nla_get_u32(tb[TCA_CLSACT_INGRESS_BLOCK]);
+   return 0;
+}
+
 static int ingress_init(struct Qdisc *sch, struct nlattr *opt)
 {
struct ingress_sched_data *q = qdisc_priv(sch);
struct net_device *dev = qdisc_dev(sch);
+   u32 ingress_block_index;
int err;
 
-   err = tcf_block_get(>block, >ingress_cl_list);
+   err = ingress_parse_opt(opt, _block_index);
+   if (err)
+   return err;
+
+   err = tcf_block_get_shared(>block, qdisc_net(sch),
+  ingress_block_index, >ingress_cl_list);
if (err)
return err;
 
@@ -77,18 +106,22 @@ static int ingress_init(struct Qdisc *sch, struct nlattr 
*opt)
 static void ingress_destroy(struct Qdisc *sch)
 {
struct ingress_sched_data *q = qdisc_priv(sch);
+   struct net_device *dev = qdisc_dev(sch);
 
-   tcf_block_put(q->block);
+   tcf_block_put_shared(q->block, qdisc_net(sch), >ingress_cl_list);
net_dec_ingress_queue();
 }
 
 static int ingress_dump(struct Qdisc *sch, struct sk_buff *skb)
 {
+   struct ingress_sched_data *q = qdisc_priv(sch);
struct nlattr *nest;
 
nest = nla_nest_start(skb, TCA_OPTIONS);
if (nest == NULL)
goto nla_put_failure;
+   if (nla_put_u32(skb, TCA_CLSACT_INGRESS_BLOCK, q->block->index))
+   goto nla_put_failure;
 
return nla_nest_end(skb, nest);
 
@@ -159,17 +192,54 @@ static struct tcf_block *clsact_tcf_block(struct Qdisc 
*sch, unsigned long cl)
}
 }
 
+static const struct nla_policy clsact_policy[TCA_CLSACT_MAX + 1] = {
+   [TCA_CLSACT_INGRESS_BLOCK]  = { .type = NLA_U32 },
+   [TCA_CLSACT_EGRESS_BLOCK]   = { .type = NLA_U32 },
+};
+
+static int clsact_parse_opt(struct nlattr *opt, u32 *p_ingress_block_index,
+   u32 *p_egress_block_index)
+{
+   struct nlattr *tb[TCA_CLSACT_MAX + 1];
+   int err;
+
+   *p_ingress_block_index = 0;
+   *p_egress_block_index = 0;
+
+   if (!opt)
+   return 0;
+   err = nla_parse_nested(tb, TCA_CLSACT_MAX, opt, clsact_policy, NULL);
+   if (err)
+   return err;
+
+   if (tb[TCA_CLSACT_INGRESS_BLOCK])
+   *p_ingress_block_index =
+   nla_get_u32(tb[TCA_CLSACT_INGRESS_BLOCK]);
+   if (tb[TCA_CLSACT_EGRESS_BLOCK])
+   *p_egress_block_index =
+   nla_get_u32(tb[TCA_CLSACT_EGRESS_BLOCK]);
+   return 0;
+}
+
 static int clsact_init(struct Qdisc *sch, struct nlattr *opt)
 {
struct clsact_sched_data *q = qdisc_priv(sch);
struct net_device *dev = qdisc_dev(sch);
+   u32 ingress_block_index;
+   u32 egress_block_index;
int err;
 
-   err = tcf_block_get(>ingress_block, >ingress_cl_list);
+   err = clsact_parse_opt(opt, _block_index, _block_index);
if (err)
return err;
 
-   err = tcf_block_get(>egress_block, >egress_cl_list);
+   err = tcf_block_get_shared(>ingress_block, qdisc_net(sch),
+  

[patch net-next RFC 1/4] net: sched: introduce support for multiple filter chain pointers registration

[Jiri Pirko]

From: Jiri Pirko 

So far, there was possible only to register a single filter chain
pointer to a block->chain[0]. However, when the blocks will get
shareable, we need to allow multiple filter chain pointers registration.

Signed-off-by: Jiri Pirko 
---
 include/net/sch_generic.h |  2 +-
 net/sched/cls_api.c   | 66 ---
 2 files changed, 57 insertions(+), 11 deletions(-)

diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 1c123e2..7396de8 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -257,7 +257,7 @@ struct qdisc_skb_cb {
 
 struct tcf_chain {
struct tcf_proto __rcu *filter_chain;
-   struct tcf_proto __rcu **p_filter_chain;
+   struct list_head filter_chain_list;
struct list_head list;
struct tcf_block *block;
u32 index; /* chain index */
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 39da0c5..411f5577 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -186,6 +186,11 @@ static void tcf_proto_destroy(struct tcf_proto *tp)
kfree_rcu(tp, rcu);
 }
 
+struct tfc_filter_chain_list_item {
+   struct list_head list;
+   struct tcf_proto __rcu **p_filter_chain;
+};
+
 static struct tcf_chain *tcf_chain_create(struct tcf_block *block,
  u32 chain_index)
 {
@@ -194,6 +199,7 @@ static struct tcf_chain *tcf_chain_create(struct tcf_block 
*block,
chain = kzalloc(sizeof(*chain), GFP_KERNEL);
if (!chain)
return NULL;
+   INIT_LIST_HEAD(>filter_chain_list);
list_add_tail(>list, >chain_list);
chain->block = block;
chain->index = chain_index;
@@ -203,10 +209,11 @@ static struct tcf_chain *tcf_chain_create(struct 
tcf_block *block,
 
 static void tcf_chain_flush(struct tcf_chain *chain)
 {
+   struct tfc_filter_chain_list_item *item;
struct tcf_proto *tp;
 
-   if (*chain->p_filter_chain)
-   RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
+   list_for_each_entry(item, >filter_chain_list, list)
+   RCU_INIT_POINTER(*item->p_filter_chain, NULL);
while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
RCU_INIT_POINTER(chain->filter_chain, tp->next);
tcf_proto_destroy(tp);
@@ -248,11 +255,40 @@ void tcf_chain_put(struct tcf_chain *chain)
 }
 EXPORT_SYMBOL(tcf_chain_put);
 
+static int
+tcf_chain_filter_chain_ptr_add(struct tcf_chain *chain,
+  struct tcf_proto __rcu **p_filter_chain)
+{
+   struct tfc_filter_chain_list_item *item;
+
+   item = kmalloc(sizeof(*item), GFP_KERNEL);
+   if (!item)
+   return -ENOMEM;
+   item->p_filter_chain = p_filter_chain;
+   list_add(>list, >filter_chain_list);
+   return 0;
+}
+
 static void
-tcf_chain_filter_chain_ptr_set(struct tcf_chain *chain,
+tcf_chain_filter_chain_ptr_del(struct tcf_chain *chain,
   struct tcf_proto __rcu **p_filter_chain)
 {
-   chain->p_filter_chain = p_filter_chain;
+   struct tfc_filter_chain_list_item *item;
+
+   list_for_each_entry(item, >filter_chain_list, list) {
+   if (!p_filter_chain ||
+   item->p_filter_chain == p_filter_chain) {
+   list_del(>list);
+   kfree(item);
+   return;
+   }
+   }
+   WARN_ON(1);
+}
+
+static struct tcf_chain *tcf_block_chain_zero(struct tcf_block *block)
+{
+   return list_first_entry(>chain_list, struct tcf_chain, list);
 }
 
 int tcf_block_get(struct tcf_block **p_block,
@@ -271,7 +307,7 @@ int tcf_block_get(struct tcf_block **p_block,
err = -ENOMEM;
goto err_chain_create;
}
-   tcf_chain_filter_chain_ptr_set(chain, p_filter_chain);
+   tcf_chain_filter_chain_ptr_add(chain, p_filter_chain);
*p_block = block;
return 0;
 
@@ -288,6 +324,8 @@ void tcf_block_put(struct tcf_block *block)
if (!block)
return;
 
+   tcf_chain_filter_chain_ptr_del(tcf_block_chain_zero(block), NULL);
+
list_for_each_entry_safe(chain, tmp, >chain_list, list)
tcf_chain_destroy(chain);
kfree(block);
@@ -362,9 +400,13 @@ static void tcf_chain_tp_insert(struct tcf_chain *chain,
struct tcf_chain_info *chain_info,
struct tcf_proto *tp)
 {
-   if (chain->p_filter_chain &&
-   *chain_info->pprev == chain->filter_chain)
-   rcu_assign_pointer(*chain->p_filter_chain, tp);
+   if (*chain_info->pprev == chain->filter_chain) {
+   struct tfc_filter_chain_list_item *item;
+
+   list_for_each_entry(item, >filter_chain_list, list)
+   rcu_assign_pointer(*item->p_filter_chain, tp);
+   }
+

[patch net-next RFC 2/4] net: sched: intruduce qdisc_net helper

[Jiri Pirko]

From: Jiri Pirko 

There is going to be need to be able to obtain net structure for
a qdisc. So introduce helper to do it.

Signed-off-by: Jiri Pirko 
---
 include/net/pkt_sched.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index 2579c20..da85ad0 100644
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -4,7 +4,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #define DEFAULT_TX_QUEUE_LEN   1000
 
@@ -132,4 +134,9 @@ static inline unsigned int psched_mtu(const struct 
net_device *dev)
return dev->mtu + dev->hard_header_len;
 }
 
+static inline struct net *qdisc_net(struct Qdisc *q)
+{
+   return dev_net(q->dev_queue->dev);
+}
+
 #endif
-- 
2.9.3

Re: [RFC] get_compat_bpf_fprog(): don't copyin field-by-field

[Daniel Borkmann]

On 07/08/2017 08:22 PM, Al Viro wrote:

Signed-off-by: Al Viro 


Acked-by: Daniel Borkmann 

(Looks like ppp_sock_fprog_ioctl_trans() is another such candidate.)

[PATCH net] samples/bpf: fix a build issue

[Yonghong Song]

From: Yonghong Song 

With latest net-next:

clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not found
 ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in tools/testing/selftests/bpf/bpf_endian.h
and move it to samples/bpf/ directory so that it can used by
both selftests/bpf and samples/bpf. The existing samples/bpf/bpf_helpers.h
is already used by both.

Signed-off-by: Yonghong Song 
---
 {tools/testing/selftests => samples}/bpf/bpf_endian.h | 14 ++
 tools/testing/selftests/bpf/Makefile  |  3 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)
 rename {tools/testing/selftests => samples}/bpf/bpf_endian.h (73%)

diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/samples/bpf/bpf_endian.h
similarity index 73%
rename from tools/testing/selftests/bpf/bpf_endian.h
rename to samples/bpf/bpf_endian.h
index 487cbfb..74af266 100644
--- a/tools/testing/selftests/bpf/bpf_endian.h
+++ b/samples/bpf/bpf_endian.h
@@ -23,11 +23,19 @@
 # define __bpf_htons(x)__builtin_bswap16(x)
 # define __bpf_constant_ntohs(x)   ___constant_swab16(x)
 # define __bpf_constant_htons(x)   ___constant_swab16(x)
+# define __bpf_ntohl(x)__builtin_bswap32(x)
+# define __bpf_htonl(x)__builtin_bswap32(x)
+# define __bpf_constant_ntohl(x)   ___constant_swab32(x)
+# define __bpf_constant_htonl(x)   ___constant_swab32(x)
 #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 # define __bpf_ntohs(x)(x)
 # define __bpf_htons(x)(x)
 # define __bpf_constant_ntohs(x)   (x)
 # define __bpf_constant_htons(x)   (x)
+# define __bpf_ntohl(x)(x)
+# define __bpf_htonl(x)(x)
+# define __bpf_constant_ntohl(x)   (x)
+# define __bpf_constant_htonl(x)   (x)
 #else
 # error "Fix your compiler's __BYTE_ORDER__?!"
 #endif
@@ -38,5 +46,11 @@
 #define bpf_ntohs(x)   \
(__builtin_constant_p(x) ?  \
 __bpf_constant_ntohs(x) : __bpf_ntohs(x))
+#define bpf_htonl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_htonl(x) : __bpf_htonl(x))
+#define bpf_ntohl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_ntohl(x) : __bpf_ntohl(x))
 
 #endif /* __BPF_ENDIAN__ */
diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index 2ca51a8..f263c6b 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -8,7 +8,8 @@ ifneq ($(wildcard $(GENHDR)),)
   GENFLAGS := -DHAVE_GENHDR
 endif
 
-CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include
+CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include \
+   -I../../../../samples/bpf
 LDLIBS += -lcap -lelf
 
 TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map 
test_progs \
-- 
2.9.4

[patch iproute2/net-next RFC] tc: Implement filter block sharing to ingress and clsact qdiscs

[Jiri Pirko]

From: Jiri Pirko 

Signed-off-by: Jiri Pirko 
---
 include/linux/pkt_sched.h | 12 +++
 tc/q_clsact.c | 54 ++-
 tc/q_ingress.c| 32 +---
 3 files changed, 90 insertions(+), 8 deletions(-)

diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index 099bf55..a684087 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -871,4 +871,16 @@ struct tc_pie_xstats {
__u32 maxq; /* maximum queue size */
__u32 ecn_mark; /* packets marked with ecn*/
 };
+
+/* Ingress/clsact */
+
+enum {
+   TCA_CLSACT_UNSPEC,
+   TCA_CLSACT_INGRESS_BLOCK,
+   TCA_CLSACT_EGRESS_BLOCK,
+   __TCA_CLSACT_MAX
+};
+
+#define TCA_CLSACT_MAX (__TCA_CLSACT_MAX - 1)
+
 #endif
diff --git a/tc/q_clsact.c b/tc/q_clsact.c
index e2a1a71..0ecaa63 100644
--- a/tc/q_clsact.c
+++ b/tc/q_clsact.c
@@ -6,23 +6,67 @@
 
 static void explain(void)
 {
-   fprintf(stderr, "Usage: ... clsact\n");
+   fprintf(stderr, "Usage: ... clsact [ingress_block BLOCK_INDEX] 
[egress_block BLOCK_INDEX]\n");
 }
 
 static int clsact_parse_opt(struct qdisc_util *qu, int argc, char **argv,
struct nlmsghdr *n)
 {
-   if (argc > 0) {
-   fprintf(stderr, "What is \"%s\"?\n", *argv);
-   explain();
-   return -1;
+   struct rtattr *tail;
+   unsigned int ingress_block;
+   unsigned int egress_block;
+
+   while (argc > 0) {
+   if (strcmp(*argv, "ingress_block") == 0) {
+   NEXT_ARG();
+   if (get_unsigned(_block, *argv, 0)) {
+   fprintf(stderr, "Illegal \"ingress_block\"\n");
+   return -1;
+   }
+   } else if (strcmp(*argv, "egress_block") == 0) {
+   NEXT_ARG();
+   if (get_unsigned(_block, *argv, 0)) {
+   fprintf(stderr, "Illegal \"egress_block\"\n");
+   return -1;
+   }
+   } else {
+   fprintf(stderr, "What is \"%s\"?\n", *argv);
+   explain();
+   return -1;
+   }
+   NEXT_ARG_FWD();
}
 
+   tail = NLMSG_TAIL(n);
+   addattr_l(n, 1024, TCA_OPTIONS, NULL, 0);
+   if (ingress_block)
+   addattr32(n, 1024, TCA_CLSACT_INGRESS_BLOCK, ingress_block);
+   if (egress_block)
+   addattr32(n, 1024, TCA_CLSACT_EGRESS_BLOCK, egress_block);
+   tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
return 0;
 }
 
 static int clsact_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
 {
+   struct rtattr *tb[TCA_CLSACT_MAX + 1];
+   unsigned int block;
+
+   if (!opt)
+   return 0;
+
+   parse_rtattr_nested(tb, TCA_CLSACT_MAX, opt);
+
+   if (tb[TCA_CLSACT_INGRESS_BLOCK] &&
+   RTA_PAYLOAD(tb[TCA_CLSACT_INGRESS_BLOCK]) >= sizeof(__u32)) {
+   block = rta_getattr_u32(tb[TCA_CLSACT_INGRESS_BLOCK]);
+   fprintf(f, "ingress_block %u ", block);
+   }
+   if (tb[TCA_CLSACT_EGRESS_BLOCK] &&
+   RTA_PAYLOAD(tb[TCA_CLSACT_EGRESS_BLOCK]) >= sizeof(__u32)) {
+   block = rta_getattr_u32(tb[TCA_CLSACT_EGRESS_BLOCK]);
+   fprintf(f, "egress_block %u ", block);
+   }
return 0;
 }
 
diff --git a/tc/q_ingress.c b/tc/q_ingress.c
index 31699a8..b973e1b 100644
--- a/tc/q_ingress.c
+++ b/tc/q_ingress.c
@@ -17,30 +17,56 @@
 
 static void explain(void)
 {
-   fprintf(stderr, "Usage: ... ingress\n");
+   fprintf(stderr, "Usage: ... ingress [block BLOCK_INDEX]\n");
 }
 
 static int ingress_parse_opt(struct qdisc_util *qu, int argc, char **argv,
 struct nlmsghdr *n)
 {
+   struct rtattr *tail;
+   unsigned int block;
+
while (argc > 0) {
if (strcmp(*argv, "handle") == 0) {
NEXT_ARG();
-   argc--; argv++;
+   } else if (strcmp(*argv, "block") == 0) {
+   NEXT_ARG();
+   if (get_unsigned(, *argv, 0)) {
+   fprintf(stderr, "Illegal \"block\"\n");
+   return -1;
+   }
} else {
fprintf(stderr, "What is \"%s\"?\n", *argv);
explain();
return -1;
}
+   NEXT_ARG_FWD();
}
 
+   tail = NLMSG_TAIL(n);
+   addattr_l(n, 1024, TCA_OPTIONS, NULL, 0);
+   if (block)
+   addattr32(n, 1024, TCA_CLSACT_INGRESS_BLOCK, block);
+   tail->rta_len = (void *) NLMSG_TAIL(n) - (void *) tail;
return 0;
 }
 
 

Re: [RFC PATCH 00/12] Implement XDP bpf_redirect vairants

[Jesper Dangaard Brouer]

On Sat, 8 Jul 2017 21:06:17 +0200
Jesper Dangaard Brouer  wrote:

> On Sat, 08 Jul 2017 10:46:18 +0100 (WEST)
> David Miller  wrote:
> 
> > From: John Fastabend 
> > Date: Fri, 07 Jul 2017 10:48:36 -0700
> >   
> > > On 07/07/2017 10:34 AM, John Fastabend wrote:
> > >> This series adds two new XDP helper routines bpf_redirect() and
> > >> bpf_redirect_map(). The first variant bpf_redirect() is meant
> > >> to be used the same way it is currently being used by the cls_bpf
> > >> classifier. An xdp packet will be redirected immediately when this
> > >> is called.
> > > 
> > > Also other than the typo in the title there ;) I'm going to CC
> > > the driver maintainers working on XDP (makes for a long CC list but)
> > > because we would want to try and get support in as many as possible in
> > > the next merge window.
> > > 
> > > For this rev I just implemented on ixgbe because I wrote the
> > > original XDP support there. I'll volunteer to do virtio as well.
> > 
> > I went over this series a few times and it looks great to me.
> > You didn't even give me some coding style issues to pick on :-)  
> 
> We (Daniel, Andy and I) have been reviewing and improving on this
> patchset the last couple of weeks ;-).  We had some stability issues,
> which is why it wasn't published earlier. My plan is to test this
> latest patchset again, Monday and Tuesday. I'll try to assess stability
> and provide some performance numbers.


Damn, I though it was stable, I have been running a lot of performance
tests, and then this just happened :-(

[11357.149486] BUG: unable to handle kernel NULL pointer dereference at 
0210
[11357.157393] IP: __dev_map_flush+0x58/0x90
[11357.161446] PGD 3ff685067 
[11357.161446] P4D 3ff685067 
[11357.164199] PUD 3ff684067 
[11357.166947] PMD 0 
[11357.170396] 
[11357.173981] Oops:  [#1] PREEMPT SMP
[11357.177859] Modules linked in: coretemp kvm_intel kvm irqbypass intel_cstate 
intel_uncore intel_rapl_perf mxm_wmi i2c_i801 pcspkr sg i2c_co]
[11357.203021] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.12.0-net-next-xdp_redirect02-rfc+ #135
[11357.211706] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 
Extreme4, BIOS P2.10 05/12/2015
[11357.221606] task: 81c0e480 task.stack: 81c0
[11357.227568] RIP: 0010:__dev_map_flush+0x58/0x90
[11357.232138] RSP: 0018:88041fa03de0 EFLAGS: 00010286
[11357.237409] RAX:  RBX: 8803fc996600 RCX: 0003
[11357.244589] RDX: 88040d0bf480 RSI:  RDI: 81d901d8
[11357.251767] RBP: 88041fa03df8 R08: fffc R09: 00070008
[11357.258940] R10: 813f11d0 R11: 0040 R12: e8c014a0
[11357.266119] R13: 0003 R14: 003c R15: 8803fc9c26c0
[11357.273294] FS:  () GS:88041fa0() 
knlGS:
[11357.281454] CS:  0010 DS:  ES:  CR0: 80050033
[11357.287244] CR2: 0210 CR3: 0003fc41e000 CR4: 001406f0
[11357.294423] Call Trace:
[11357.296912]  
[11357.298967]  xdp_do_flush_map+0x36/0x40
[11357.302847]  ixgbe_poll+0x7ea/0x1370 [ixgbe]
[11357.307160]  net_rx_action+0x247/0x3e0
[11357.310957]  __do_softirq+0x106/0x2cb
[11357.314664]  irq_exit+0xbe/0xd0
[11357.317851]  do_IRQ+0x4f/0xd0
[11357.320858]  common_interrupt+0x86/0x86
[11357.324733] RIP: 0010:poll_idle+0x2f/0x5a
[11357.328781] RSP: 0018:81c03dd0 EFLAGS: 0246 ORIG_RAX: 
ff8e
[11357.336426] RAX:  RBX: 81d689e0 RCX: 0020
[11357.343605] RDX:  RSI: 81c0e480 RDI: 88041fa22800
[11357.350783] RBP: 81c03dd0 R08: 03c5 R09: 0018
[11357.357958] R10: 0327 R11: 0390 R12: 88041fa22800
[11357.365135] R13: 81d689f8 R14:  R15: 81d689e0
[11357.372311]  
[11357.374453]  cpuidle_enter_state+0xf2/0x2e0
[11357.378678]  cpuidle_enter+0x17/0x20
[11357.382299]  call_cpuidle+0x23/0x40
[11357.385834]  do_idle+0xe8/0x190
[11357.389024]  cpu_startup_entry+0x1d/0x20
[11357.392993]  rest_init+0xd5/0xe0
[11357.396268]  start_kernel+0x3d7/0x3e4
[11357.399979]  x86_64_start_reservations+0x2a/0x2c
[11357.404641]  x86_64_start_kernel+0x178/0x18b
[11357.408959]  secondary_startup_64+0x9f/0x9f
[11357.413186]  ? secondary_startup_64+0x9f/0x9f
[11357.417589] Code: 41 89 c5 48 8b 53 60 44 89 e8 48 8d 14 c2 48 8b 12 48 85 
d2 74 23 48 8b 3a f0 49 0f b3 04 24 48 85 ff 74 15 48 8b 87 e0 0 
[11357.436565] RIP: __dev_map_flush+0x58/0x90 RSP: 88041fa03de0
[11357.442613] CR2: 0210
[11357.445972] ---[ end trace f7ed232095169a98 ]---
[11357.450637] Kernel panic - not syncing: Fatal exception in interrupt
[11357.457038] Kernel Offset: disabled
[11357.460566] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

(gdb) list 

[patch net-next RFC 3/4] net: sched: introduce shared filter blocks infrastructure

[Jiri Pirko]

From: Jiri Pirko 

Allow qdiscs to share filter blocks among them. Each qdisc type has to
use block get/put modifications that enable sharing. Shared blocks are
tracked within each net namespace and identified by u32 value. This
value is auto-generated in case user did not pass it from userspace. If
user passes value that is not used, new block is created. If user passes
value that is already used, the existing block will be re-used.

Signed-off-by: Jiri Pirko 
---
 include/net/pkt_cls.h |  22 +-
 include/net/sch_generic.h |   2 +
 net/sched/cls_api.c   | 180 ++
 3 files changed, 189 insertions(+), 15 deletions(-)

diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index 537d0a0..4381cbc 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -23,7 +23,12 @@ struct tcf_chain *tcf_chain_get(struct tcf_block *block, u32 
chain_index,
 void tcf_chain_put(struct tcf_chain *chain);
 int tcf_block_get(struct tcf_block **p_block,
  struct tcf_proto __rcu **p_filter_chain);
+int tcf_block_get_shared(struct tcf_block **p_block,
+struct net *net, u32 block_index,
+struct tcf_proto __rcu **p_filter_chain);
 void tcf_block_put(struct tcf_block *block);
+void tcf_block_put_shared(struct tcf_block *block, struct net *net,
+ struct tcf_proto __rcu **p_filter_chain);
 int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
 struct tcf_result *res, bool compat_mode);
 
@@ -35,7 +40,22 @@ int tcf_block_get(struct tcf_block **p_block,
return 0;
 }
 
-static inline void tcf_block_put(struct tcf_block *block)
+static inline
+int tcf_block_get_shared(struct tcf_block **p_block,
+struct net *net, u32 block_index,
+struct tcf_proto __rcu **p_filter_chain)
+{
+   return 0;
+}
+
+static inline
+void tcf_block_put(struct tcf_block *block)
+{
+}
+
+static inline
+void tcf_block_put_shared(struct tcf_block *block, struct net *net,
+ struct tcf_proto __rcu **p_filter_chain)
 {
 }
 
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 7396de8..cbc7313 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -266,6 +266,8 @@ struct tcf_chain {
 
 struct tcf_block {
struct list_head chain_list;
+   u32 index; /* block index for shared blocks */
+   unsigned int refcnt;
 };
 
 static inline void qdisc_cb_private_validate(const struct sk_buff *skb, int sz)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index 411f5577..098b9a2 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -286,52 +287,175 @@ tcf_chain_filter_chain_ptr_del(struct tcf_chain *chain,
WARN_ON(1);
 }
 
-static struct tcf_chain *tcf_block_chain_zero(struct tcf_block *block)
+struct tcf_net {
+   struct idr idr;
+};
+
+static unsigned int tcf_net_id;
+
+static int tcf_block_insert(struct tcf_block *block, struct net *net,
+   u32 block_index)
 {
-   return list_first_entry(>chain_list, struct tcf_chain, list);
+   struct tcf_net *tn = net_generic(net, tcf_net_id);
+   int idr_start;
+   int idr_end;
+   int index;
+
+   if (block_index >= INT_MAX)
+   return -EINVAL;
+   idr_start = block_index ? block_index : 1;
+   idr_end = block_index ? block_index + 1 : INT_MAX;
+
+   index = idr_alloc(>idr, block, idr_start, idr_end, GFP_KERNEL);
+   if (index < 0)
+   return index;
+   block->index = index;
+   return 0;
 }
 
-int tcf_block_get(struct tcf_block **p_block,
- struct tcf_proto __rcu **p_filter_chain)
+static void tcf_block_remove(struct tcf_block *block, struct net *net)
+{
+   struct tcf_net *tn = net_generic(net, tcf_net_id);
+
+   idr_remove(>idr, block->index);
+}
+
+static struct tcf_block *tcf_block_create(void)
 {
-   struct tcf_block *block = kzalloc(sizeof(*block), GFP_KERNEL);
+   struct tcf_block *block;
struct tcf_chain *chain;
int err;
 
+   block = kzalloc(sizeof(*block), GFP_KERNEL);
if (!block)
-   return -ENOMEM;
+   return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(>chain_list);
+   block->refcnt = 1;
+
/* Create chain 0 by default, it has to be always present. */
chain = tcf_chain_create(block, 0);
if (!chain) {
err = -ENOMEM;
goto err_chain_create;
}
-   tcf_chain_filter_chain_ptr_add(chain, p_filter_chain);
-   *p_block = block;
-   return 0;
+   return block;
 
 err_chain_create:
kfree(block);
+   return ERR_PTR(err);
+}
+
+static void tcf_block_destroy(struct tcf_block *block)
+{
+   struct 

Re: [PATCH net-next RFC 10/12] net: dsa: Move FDB dump implementation inside DSA

[Vivien Didelot]

Hi Arkadi,

Arkadi Sharshevsky  writes:

> +struct dsa_slave_dump_ctx {
> + struct net_device *dev;
> + struct sk_buff *skb;
> + struct netlink_callback *cb;
> + int idx;
> +};
> +
>  struct dsa_switch_ops {
>   /*
>* Legacy probing.
> @@ -392,9 +399,7 @@ struct dsa_switch_ops {
>   int (*port_fdb_del)(struct dsa_switch *ds, int port,
>   const unsigned char *addr, u16 vid);
>   int (*port_fdb_dump)(struct dsa_switch *ds, int port,
> -  struct switchdev_obj_port_fdb *fdb,
> -   switchdev_obj_dump_cb_t *cb);
> -
> +  struct dsa_slave_dump_ctx *dump);

I would prefer to pass a callback to the driver, so that we can call
port_fdb_dump for other interfaces like debugfs, and for non exposed
switch ports (CPU and DSA links) as well. Something like:

typedef int dsa_fdb_dump_cb_t(const unsigned char *addr, u16 vid,
  bool is_static, void *data);

int (*port_fdb_dump)(struct dsa_switch *ds, int port,
 dsa_fdb_dump_cb_t *cb, void *data);

Then dsa_slave_dump_ctx and dsa_slave_port_fdb_do_dump can be static to
net/dsa/slave.c.

> +int dsa_slave_port_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb,
> + struct net_device *dev,
> + struct net_device *filter_dev, int *idx)
> +{
> + struct dsa_slave_dump_ctx dump = {
> + .dev = dev,
> + .skb = skb,
> + .cb = cb,
> + .idx = *idx,
> + };
> + struct dsa_slave_priv *p = netdev_priv(dev);
> + struct dsa_port *dp = p->dp;
> + struct dsa_switch *ds = dp->ds;
> + int err;
> +
> + if (!ds->ops->port_fdb_dump) {
> + err = -EOPNOTSUPP;
> + goto out;
> + }
> +
> + err = ds->ops->port_fdb_dump(ds, dp->index, );
> +out:
> + *idx = dump.idx;
> + return err;

There is no need to reassign *idx in case of error:

if (!ds->ops->port_fdb_dump)
return -EOPNOTSUPP;

err = ds->ops->port_fdb_dump(ds, dp->index, );
*idx = dump.idx;

return err;

> + .ndo_fdb_dump   = dsa_slave_port_fdb_dump,

And s/dsa_slave_port_fdb_dump/dsa_slave_fdb_dump/ here will be even
better ;-)


Thanks,

Vivien

[PATCH] dpaa_eth: use correct device for DMA mapping API

[Arnd Bergmann]

Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
as a result of the driver calling set_dma_ops(). While we can
fix the build error in the dma-mapping implementation, there is
another problem in this driver:

The configuration for the DMA is done by the platform code,
looking up information about the system from the device tree.
This copies the information only in an incomplete way, setting
the dma_map_ops and forcing a specific mask, but ignoring all
settings regarding IOMMU, coherence etc.

A better way to avoid the problem is to only ever pass a device
into the dma_mapping implementation that has been setup by the
platform code. In this case, that is the parent device, so we
can get that pointer at probe time. Fortunately, we already have
a pointer in the device specific structure for that, so we only
need to modify that.

Fixes: fb52728a9294 ("dpaa_eth: reuse the dma_ops provided by the FMan MAC 
device")
Signed-off-by: Arnd Bergmann 
---
Not tested, please see if this works before applying!
---
 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 757b873735a5..f7b0b928cd53 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2646,14 +2646,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
priv->buf_layout[RX].priv_data_size = DPAA_RX_PRIV_DATA_SIZE; /* Rx */
priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /* Tx */
 
-   /* device used for DMA mapping */
-   set_dma_ops(dev, get_dma_ops(>dev));
-   err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
-   if (err) {
-   dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
-   goto dev_mask_failed;
-   }
-
/* bp init */
for (i = 0; i < DPAA_BPS_NUM; i++) {
int err;
@@ -2665,7 +2657,8 @@ static int dpaa_eth_probe(struct platform_device *pdev)
dpaa_bps[i]->raw_size = bpool_buffer_raw_size(i, DPAA_BPS_NUM);
/* avoid runtime computations by keeping the usable size here */
dpaa_bps[i]->size = dpaa_bp_size(dpaa_bps[i]->raw_size);
-   dpaa_bps[i]->dev = dev;
+   /* DMA operations are done on the platform-provided device */
+   dpaa_bps[i]->dev = dev->parent;
 
err = dpaa_bp_alloc_pool(dpaa_bps[i]);
if (err < 0) {
-- 
2.9.0

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

[Robin Murphy]

On 10/07/17 15:56, Christoph Hellwig wrote:
> This looks reasonable to me, I'd be happy to pick it up.  Can you send
> it as a series with the reverts?

The fact remains that the FSL driver is still doing the wrong thing
though - set_dma_ops(dev1, get_dma_ops(dev2)) is just a hack which
happens to work on platforms which don't keep other arch-internal DMA
info as well. I did start writing a patch somewhere to fix this thing to
actually do proper DMA configuration (originally in the context of not
abusing arch_setup_dma_ops()), but Arnd's fix is probably simpler.

I don't think it makes an awful lot of sense for code without a DMA API
dependency to be calling set_dma_ops() - AFAIU the only reason it's
available to drivers at all is for particular RDMA cases which know that
their "DMA" is actually done by CPU threads, and want to optimise for that.

Robin.

Re: [PATCH iproute2 V3 0/4] RDMAtool

[Leon Romanovsky]

On Mon, Jul 10, 2017 at 10:02:30AM +0200, Jiri Pirko wrote:
> Tue, Jul 04, 2017 at 09:55:37AM CEST, l...@kernel.org wrote:
> >Hi,
> >
> >This is third version of series implementing the RDAMtool -  the tool
> >to configure RDMA devices. The initial proposal was sent as RFC [1] and
> >was based on sysfs entries as POC.
> >
> >The current series was rewritten completely to work with RDMA netlinks as
> >a source of user<->kernel communications. In order to achieve that, the
> >RDMA netlinks were extensively refactored and modernized [2, 3, 4 and 5].
> >
> >The following is an example of various runs on my machine with 5 devices
> >(4 in IB mode and one in Ethernet mode)
> >
> >### Without parameters
> >$ rdma
> >Usage: rdma [ OPTIONS ] OBJECT { COMMAND | help }
> >where  OBJECT := { dev | link | help }
> >   OPTIONS := { -V[ersion] | -d[etails]}
>
> What about json output? You will need it sooner than later. It will
> prevent you from a lot of headaches if you implement it right away.
> Lesson learned...

I'm planning to do it in the coming kernel cycle.

Thanks


signature.asc
Description: PGP signature

Re: net: Fix inconsistent teardown and release of private netdev state.

[Cong Wang]

On Sun, Jul 9, 2017 at 7:07 PM, Jason A. Donenfeld  wrote:
> On Sat, Jul 8, 2017 at 12:39 AM, Cong Wang  wrote:
>> On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld  wrote:
>>> list_add(>list, _of_things);
>>>
>>> ret = register_netdevice(); // if ret is < 0, then destruct above 
>>> is automatically called
>>>
>>> // RACE WITH LIST_ADD/LIST_DEL!! It's impossible to call list_add 
>>> only after
>>> // things are brought up successfully. This is problematic.
>>>
>>> if (!ret)
>>> pr_info("Yay it worked!\n");
>>
>> I fail to understand what you mean by RACE here.
>>
>> Here you should already have RTNL lock, so it can't race with any other
>> newlink() calls. In fact you can't acquire RTNL lock in your destructor
>> since register_netdevice() already gets it. Perhaps you mean
>> netdev_run_todo() calls it without RTNL lock?
>>
>> I don't know why you reorder the above list_add(), you can order it
>> as it was before, aka, call it after register_netdevice(), but you have to
>> init the priv->list now for the list_del() on error path.
>
> The race is that there's a state in which priv->list is part of
> list_of_things before the interface is actually successfully setup and
> ready to go.
>
> And no, it's not possible to order it _after_ register_netdevice,
> since register_netdevice might call priv_destructor, and
> priv_destructor calls list_del, so if it's not already on the list,
> we'll OOPS. In otherwords, API problem.


As I said, you have to initialize it, list_del() on an empty head
is literally a nop, why oops?

Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

[Russell Joyce]

> 1) I think most of it should be some cfg80211 shareable code.

I’m not sure exactly what you mean by this, could you please clarify?

> 2) This "rxtx" while surely present in other places sounds like a
> workaround for LED subsystem limitation. Maybe it's time to finally
> rework LED triggers.

I agree that it’s not an ideal way to do things, but I couldn’t think of a
better alternative. I think that having a combined trigger is useful though, for
situations like using the single LED on a Raspberry Pi to show Wi-Fi activity.


> On 10 Jul 2017, at 10:48, Rafał Miłecki  wrote:
> 
> On 7 July 2017 at 16:09, Russell Joyce  wrote:
>> Add three basic LED triggers to brcmfmac, based on those in mac80211: one
>> for transmit, one for receive, and one for combined transmit/receive.
>> 
>> Signed-off-by: Russell Joyce 
> 
> 1) I think most of it should be some cfg80211 shareable code.
> 2) This "rxtx" while surely present in other places sounds like a
> workaround for LED subsystem limitation. Maybe it's time to finally
> rework LED triggers.

Re: [Patch] mqueue: fix netlink sock refcnt and skb refcnt

[Cong Wang]

On Sun, Jul 9, 2017 at 10:08 PM, Cong Wang  wrote:
> netlink_sendskb() is problematic, it releases sock refcnt
> silently which could cause troubles we can call it multiple
> times. info->notify_sock is a good example where we
> setup once and use it to send netlink skb's for many times.
> It should not hold or release any refcnt, but needs to rely
> on netlink_attachskb()/netlink_detachskb() to hold/release
> the corresponding refcnt.
>
> Same for the skb attached to this sock, it is allocated once
> and used for multiple times, so we should hold its refcnt
> in netlink_attachskb().
>
> At last, we need to call netlink_detachskb() to release
> both refcnt's after we remove the notification.

Hmm, the info->notify_owner is NULL'ed after sending
the notification, so probably we don't put the sock refcnt
repeatly. Not sure about the skb though...

Re: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

[Joe Perches]

On Mon, 2017-07-10 at 10:24 +, Ilan Tayari wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
> > 
> > The new IPSec offload code introduced a build error:
> > 
> > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> > `mlx5e_ipsec_build_inverse_table':
> > ipsec_rxtx.c:(.text+0x556): undefined reference
> > 
> > Another patch was added on top to fix the build error, but
> > that introduced a new bug, as we now use the remainder of
> > the division rather than the result.

Is it possible to return noise in mlx5e_ipsec_mss_inv ?

What clamps skb_shinfo(skb)->gso_size to MAX_LSO
(the size of inverse_table)?

#define MAX_LSO_MSS 2048
static __be16 mlx5e_ipsec_inverse_table[MAX_LSO_MSS];

static inline __be16 mlx5e_ipsec_mss_inv(struct sk_buff *skb)
{
return mlx5e_ipsec_inverse_table[skb_shinfo(skb)->gso_size];
}

Re: [RFC PATCH 03/12] xdp: add bpf_redirect helper function

[John Fastabend]

On 07/09/2017 06:37 AM, Saeed Mahameed wrote:
> 
> 
> On 7/7/2017 8:35 PM, John Fastabend wrote:
>> This adds support for a bpf_redirect helper function to the XDP
>> infrastructure. For now this only supports redirecting to the egress
>> path of a port.
>>
>> In order to support drivers handling a xdp_buff natively this patches
>> uses a new ndo operation ndo_xdp_xmit() that takes pushes a xdp_buff
>> to the specified device.
>>
>> If the program specifies either (a) an unknown device or (b) a device
>> that does not support the operation a BPF warning is thrown and the
>> XDP_ABORTED error code is returned.
>>
>> Signed-off-by: John Fastabend 
>> Acked-by: Daniel Borkmann 
>> ---

[...]

>>
>> +static int __bpf_tx_xdp(struct net_device *dev, struct xdp_buff *xdp)
>> +{
>> +if (dev->netdev_ops->ndo_xdp_xmit) {
>> +dev->netdev_ops->ndo_xdp_xmit(dev, xdp);
> 
> Hi John,
> 
> I have some concern here regarding synchronizing between the
> redirecting device and the target device:
> 
> if the target device's NAPI is also doing XDP_TX on the same XDP TX
> ring which this NDO might be redirecting xdp packets into the same
> ring, there would be a race accessing this ring resources (buffers
> and descriptors). Maybe you addressed this issue in the device driver
> implementation of this ndo or with some NAPI tricks/assumptions, I
> guess we have the same issue for if you run the same program to
> redirect traffic from multiple netdevices into one netdevice, how do
> you synchronize accessing this TX ring ?

The implementation uses a per cpu TX ring to resolve these races. And
the pair of driver interface API calls, xdp_do_redirect() and xdp_do_flush_map()
must be completed in a single poll() handler.

This comment was included in the header file to document this,

/* The pair of xdp_do_redirect and xdp_do_flush_map MUST be called in the
 * same cpu context. Further for best results no more than a single map
 * for the do_redirect/do_flush pair should be used. This limitation is
 * because we only track one map and force a flush when the map changes.
 * This does not appear to be a real limitation for existing software.
 */

In general some documentation about implementing XDP would probably be
useful to add in Documentation/networking but this IMO goes beyond just
this patch series.

> 
> Maybe we need some clear guidelines in this ndo documentation stating
> how to implement this ndo and what are the assumptions on those XDP
> TX redirect rings or from which context this ndo can run.
> 
> can you please elaborate.

I think the best implementation is to use a per cpu TX ring as I did in
this series. If your device is limited by the number of queues for some
reason some other scheme would need to be devised. Unfortunately, the only
thing I've come up for this case (using only this series) would both impact
performance and make the code complex.

A nice solution might be to constrain networking "tasks" to only a subset
of cores. For 64+ core systems this might be a good idea. It would allow
avoiding locking using per_cpu logic but also avoid networking consuming
slices of every core in the system. As core count goes up I think we will
eventually need to address this.I believe Eric was thinking along these
lines with his netconf talk iirc. Obviously this work is way outside the
scope of this series though.


> Thanks,
> Saeed.
> 

Re: Investment Consideration

[John Hanan]

Thank you for your time,

We are looking for clients in your country with good business or project that 
requires financing to execute.

Please get back to me if you are interested in this or you know anybody who has 
good business ideas but lack the necessary capital to fund his projects so we 
can establish working relationship.

Sincerely,

John Hanan, MBA, CFA
General Investment Consultant

Re: [PATCH v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

[Geert Uytterhoeven]

On Mon, Jul 10, 2017 at 5:32 PM, Biju Das  wrote:
> Add a new compatible string for the RZ/G1M (R8A7743) SoC.
>
> Signed-off-by: Biju Das 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] dpaa_eth: use correct device for DMA mapping API

[Robin Murphy]

On 10/07/17 16:14, Arnd Bergmann wrote:
> Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
> as a result of the driver calling set_dma_ops(). While we can
> fix the build error in the dma-mapping implementation, there is
> another problem in this driver:
> 
> The configuration for the DMA is done by the platform code,
> looking up information about the system from the device tree.
> This copies the information only in an incomplete way, setting
> the dma_map_ops and forcing a specific mask, but ignoring all
> settings regarding IOMMU, coherence etc.
> 
> A better way to avoid the problem is to only ever pass a device
> into the dma_mapping implementation that has been setup by the
> platform code. In this case, that is the parent device, so we
> can get that pointer at probe time. Fortunately, we already have
> a pointer in the device specific structure for that, so we only
> need to modify that.
> 
> Fixes: fb52728a9294 ("dpaa_eth: reuse the dma_ops provided by the FMan MAC 
> device")
> Signed-off-by: Arnd Bergmann 

Acked-by: Robin Murphy 

Assuming all the DPAA subcomponents have the same DMA capabilities
(which to the best of my knowledge they probably do), this is a neater
approach than what I started a while back in the context of cleaning up
arch_setup_dma_ops() abuse. FWIW, that looked like this:

->8-
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index e2ca107f9d94..8eef0db5db30 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2539,10 +2539,9 @@ static int dpaa_eth_probe(struct platform_device
*pdev)
priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /*
Tx */

/* device used for DMA mapping */
-   arch_setup_dma_ops(dev, 0, 0, NULL, false);
-   err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
+   err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(40));
if (err) {
-   dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
+   dev_err(dev, "dma_set_mask_and_coherent() failed\n");
goto dev_mask_failed;
}

diff --git a/drivers/net/ethernet/freescale/fman/mac.c
b/drivers/net/ethernet/freescale/fman/mac.c
index 0b31f8502ada..c81efbfa99c2 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -627,6 +627,10 @@ static struct platform_device
*dpaa_eth_add_device(int fman_id,
if (ret)
goto err;

+   ret = of_dma_configure(>dev, node);
+   if (ret)
+   goto err;
+
ret = platform_device_add(pdev);
if (ret)
goto err;
-8<-

We might possibly need to revisit this if and when the question of IOMMU
support in the fsl-mc driver comes up (all this stuff is completely
paged out of my head at the moment, so I'm not certain), but for now I
don't see any reason no to go with your patch.

Robin.

> ---
> Not tested, please see if this works before applying!
> ---
>  drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 757b873735a5..f7b0b928cd53 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2646,14 +2646,6 @@ static int dpaa_eth_probe(struct platform_device *pdev)
>   priv->buf_layout[RX].priv_data_size = DPAA_RX_PRIV_DATA_SIZE; /* Rx */
>   priv->buf_layout[TX].priv_data_size = DPAA_TX_PRIV_DATA_SIZE; /* Tx */
>  
> - /* device used for DMA mapping */
> - set_dma_ops(dev, get_dma_ops(>dev));
> - err = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(40));
> - if (err) {
> - dev_err(dev, "dma_coerce_mask_and_coherent() failed\n");
> - goto dev_mask_failed;
> - }
> -
>   /* bp init */
>   for (i = 0; i < DPAA_BPS_NUM; i++) {
>   int err;
> @@ -2665,7 +2657,8 @@ static int dpaa_eth_probe(struct platform_device *pdev)
>   dpaa_bps[i]->raw_size = bpool_buffer_raw_size(i, DPAA_BPS_NUM);
>   /* avoid runtime computations by keeping the usable size here */
>   dpaa_bps[i]->size = dpaa_bp_size(dpaa_bps[i]->raw_size);
> - dpaa_bps[i]->dev = dev;
> + /* DMA operations are done on the platform-provided device */
> + dpaa_bps[i]->dev = dev->parent;
>  
>   err = dpaa_bp_alloc_pool(dpaa_bps[i]);
>   if (err < 0) {
> 

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Joe Perches]

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by  work
> with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.

Re: [PATCH net-next RFC 08/12] net: dsa: Remove support for bypass bridge port attributes/vlan set

[Vivien Didelot]

Hi Florian, Arkadi,

Florian Fainelli  writes:

> I would be more comfortable if we still had a way to dump HW entries by
> calling into drivers, because it's useful for debugging, and doing that
> using standard tools plus an additional flag for instance:
>
> bridge fdb show
>
> would dump the SW-maintained VLANs, but:
>
> bridge fdb show hw

I don't think this makes much sense because the network hardware
architecture must be abstracted to the user, who only deals with user
network interfaces. This is also only needed for development and debug.

> would dump the HW-maintained VLANs, or any flag name really, but the
> point is that we can keep using a standard tool to expose debugging
> features. debugfs (or something else) could be used, but was rejected by
> David.

IIRC, what David is opposed to is having a *driver specific* debugfs
interface, i.e. debugfs for only mv88e6xxx. But he was opened to having
a *generic* debugfs interface in net/dsa/ from which any DSA chip
(e.g. lan9303, b53, qca8k, etc.) would benefit.

That makes even more sense for CPU and DSA ports which are not exposed
to userspace. Andrew played with dpipe but that wasn't quite satisfying
if I'm not mistaken. What we need for development and debug is a compile
time enableable interface to simply call into dsa_switch_ops directly.

So far here's what I have: port's VLAN, FDB, MDB, regs, stats, and
switch fabric topology (symlinks between interfaces): http://ix.io/yq0

I can split and submit this as RFC and see if I get slapped.


Thanks,

Vivien

Re: [PATCH v2 0/9] Remove spin_unlock_wait()

[Manfred Spraul]

Hi Alan,

On 07/08/2017 06:21 PM, Alan Stern wrote:

Pardon me for barging in, but I found this whole interchange extremely
confusing...

On Sat, 8 Jul 2017, Ingo Molnar wrote:


* Paul E. McKenney  wrote:


On Sat, Jul 08, 2017 at 10:35:43AM +0200, Ingo Molnar wrote:

* Manfred Spraul  wrote:


Hi Ingo,

On 07/07/2017 10:31 AM, Ingo Molnar wrote:

There's another, probably just as significant advantage: 
queued_spin_unlock_wait()
is 'read-only', while spin_lock()+spin_unlock() dirties the lock cache line. On
any bigger system this should make a very measurable difference - if
spin_unlock_wait() is ever used in a performance critical code path.

At least for ipc/sem:
Dirtying the cacheline (in the slow path) allows to remove a smp_mb() in the
hot path.
So for sem_lock(), I either need a primitive that dirties the cacheline or
sem_lock() must continue to use spin_lock()/spin_unlock().

This statement doesn't seem to make sense.  Did Manfred mean to write
"smp_mb()" instead of "spin_lock()/spin_unlock()"?

Option 1:
fastpath:
spin_lock(local_lock)
smp_mb(); [[1]]
smp_load_acquire(global_flag);
slow path:
global_flag = 1;
smp_mb();


Option 2:
fastpath:
spin_lock(local_lock);
smp_load_acquire(global_flag)
slow path:
global_flag = 1;
spin_lock(local_lock);spin_unlock(local_lock).

Rational:
The ACQUIRE from spin_lock is at the read of local_lock, not at the write.
i.e.: Without the smp_mb() at [[1]], the CPU can do:
read local_lock;
read global_flag;
write local_lock;
For Option 2, the smp_mb() is not required, because fast path and slow 
path acquire the same lock.



Technically you could use spin_trylock()+spin_unlock() and avoid the lock 
acquire
spinning on spin_unlock() and get very close to the slow path performance of a
pure cacheline-dirtying behavior.

This is even more confusing.  Did Ingo mean to suggest using
"spin_trylock()+spin_unlock()" in place of "spin_lock()+spin_unlock()"
could provide the desired ordering guarantee without delaying other
CPUs that may try to acquire the lock?  That seems highly questionable.

I agree :-)

--
Manfred

Re: [PATCH] dpaa_eth: use correct device for DMA mapping API

[Geert Uytterhoeven]

Hi Arnd,

On Mon, Jul 10, 2017 at 5:14 PM, Arnd Bergmann  wrote:
> Geert Uytterhoeven ran into a build error without CONFIG_HAS_DMA,
> as a result of the driver calling set_dma_ops(). While we can
> fix the build error in the dma-mapping implementation, there is
> another problem in this driver:
>
> The configuration for the DMA is done by the platform code,
> looking up information about the system from the device tree.
> This copies the information only in an incomplete way, setting
> the dma_map_ops and forcing a specific mask, but ignoring all
> settings regarding IOMMU, coherence etc.
>
> A better way to avoid the problem is to only ever pass a device
> into the dma_mapping implementation that has been setup by the
> platform code. In this case, that is the parent device, so we
> can get that pointer at probe time. Fortunately, we already have
> a pointer in the device specific structure for that, so we only
> need to modify that.

Thank you, that looks like a much better solution!

> Fixes: fb52728a9294 ("dpaa_eth: reuse the dma_ops provided by the FMan MAC 
> device")
> Signed-off-by: Arnd Bergmann 

Acked-by: Geert Uytterhoeven 

> Not tested, please see if this works before applying!

Indeed, please test first.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v2] dt-bindings: net: ravb : Add support for r8a7743 SoC

[Biju Das]

Add a new compatible string for the RZ/G1M (R8A7743) SoC.

Signed-off-by: Biju Das 
---
v1->v2
* Changed the subject
* re-formatted the required properties

 .../devicetree/bindings/net/renesas,ravb.txt   | 29 +-
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt 
b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index b519503..4717bc2 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -4,19 +4,24 @@ This file provides information on what the device node for 
the Ethernet AVB
 interface contains.
 
 Required properties:
-- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 
SoC.
- "renesas,etheravb-r8a7791" if the device is a part of R8A7791 SoC.
- "renesas,etheravb-r8a7792" if the device is a part of R8A7792 SoC.
- "renesas,etheravb-r8a7793" if the device is a part of R8A7793 SoC.
- "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC.
- "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC.
- "renesas,etheravb-r8a7796" if the device is a part of R8A7796 SoC.
- "renesas,etheravb-rcar-gen2" for generic R-Car Gen 2 compatible 
interface.
- "renesas,etheravb-rcar-gen3" for generic R-Car Gen 3 compatible 
interface.
+- compatible: Must contain one or more of the following:
+  - "renesas,etheravb-r8a7743" for the R8A7743 SoC.
+  - "renesas,etheravb-r8a7790" for the R8A7790 SoC.
+  - "renesas,etheravb-r8a7791" for the R8A7791 SoC.
+  - "renesas,etheravb-r8a7792" for the R8A7792 SoC.
+  - "renesas,etheravb-r8a7793" for the R8A7793 SoC.
+  - "renesas,etheravb-r8a7794" for the R8A7794 SoC.
+  - "renesas,etheravb-rcar-gen2" as a fallback for the above
+   R-Car Gen2 and RZ/G1 devices.
 
- When compatible with the generic version, nodes must list the
- SoC-specific version corresponding to the platform first
- followed by the generic version.
+  - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
+  - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
+  - "renesas,etheravb-rcar-gen3" as a fallback for the above
+   R-Car Gen3 devices.
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first followed by
+   the generic version.
 
 - reg: offset and length of (1) the register block and (2) the stream buffer.
 - interrupts: A list of interrupt-specifiers, one for each entry in
-- 
1.9.1

Re: [Patch] mqueue: fix netlink sock refcnt and skb refcnt

[Linus Torvalds]

This thing is definitely not cc'd to the right people:

On Sun, Jul 9, 2017 at 10:08 PM, Cong Wang  wrote:
>
> Cc: Linus Torvalds 
> Cc: Andrew Morton 
> Cc: Manfred Spraul 
> Signed-off-by: Cong Wang 

Unlike your previous patch, this seems to be more of a generic netlink
interface issue, so you should primarily talk to the networking
people, I'm not sure it makes much sense to cc me/Andrew/Manfred.

 Linus

Re: [PATCH 1/3] net: stmmac: Fix error handling path in 'alloc_dma_rx_desc_resources()'

[Giuseppe CAVALLARO]

On 7/8/2017 9:46 AM, Christophe JAILLET wrote:

If the first 'kmalloc_array' within the loop fails, we should free what
as already been allocated, as done in all other error handling path.

Fixes: 54139cf3bb33 ("net: stmmac: adding multiple buffers for rx")
Signed-off-by: Christophe JAILLET 


Acked-by: Giuseppe Cavallaro 


---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 19bba6281dab..4322fa4a13e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1498,7 +1498,7 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv 
*priv)
sizeof(dma_addr_t),
GFP_KERNEL);
if (!rx_q->rx_skbuff_dma)
-   return -ENOMEM;
+   goto err_dma;
  
  		rx_q->rx_skbuff = kmalloc_array(DMA_RX_SIZE,

sizeof(struct sk_buff *),

Re: [PATCH 3/3] net: stmmac: Make 'alloc_dma_[rt]x_desc_resources()' look even closer

[Giuseppe CAVALLARO]

On 7/8/2017 9:46 AM, Christophe JAILLET wrote:

'alloc_dma_[rt]x_desc_resources()' functions look very close.
Remove a useless initialization and use the same label name for error
handling path in order to get them even closer.

Signed-off-by: Christophe JAILLET 


Acked-by: Giuseppe Cavallaro 


---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 07d486a70118..1853f7ff6657 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1449,7 +1449,7 @@ static void free_dma_rx_desc_resources(struct stmmac_priv 
*priv)
  static void free_dma_tx_desc_resources(struct stmmac_priv *priv)
  {
u32 tx_count = priv->plat->tx_queues_to_use;
-   u32 queue = 0;
+   u32 queue;
  
  	/* Free TX queue resources */

for (queue = 0; queue < tx_count; queue++) {
@@ -1561,13 +1561,13 @@ static int alloc_dma_tx_desc_resources(struct 
stmmac_priv *priv)

sizeof(*tx_q->tx_skbuff_dma),
GFP_KERNEL);
if (!tx_q->tx_skbuff_dma)
-   goto err_dma_buffers;
+   goto err_dma;
  
  		tx_q->tx_skbuff = kmalloc_array(DMA_TX_SIZE,

sizeof(struct sk_buff *),
GFP_KERNEL);
if (!tx_q->tx_skbuff)
-   goto err_dma_buffers;
+   goto err_dma;
  
  		if (priv->extend_desc) {

tx_q->dma_etx = dma_zalloc_coherent(priv->device,
@@ -1577,7 +1577,7 @@ static int alloc_dma_tx_desc_resources(struct stmmac_priv 
*priv)
_q->dma_tx_phy,
GFP_KERNEL);
if (!tx_q->dma_etx)
-   goto err_dma_buffers;
+   goto err_dma;
} else {
tx_q->dma_tx = dma_zalloc_coherent(priv->device,
   DMA_TX_SIZE *
@@ -1586,13 +1586,13 @@ static int alloc_dma_tx_desc_resources(struct 
stmmac_priv *priv)
   _q->dma_tx_phy,
   GFP_KERNEL);
if (!tx_q->dma_tx)
-   goto err_dma_buffers;
+   goto err_dma;
}
}
  
  	return 0;
  
-err_dma_buffers:

+err_dma:
free_dma_tx_desc_resources(priv);
  
  	return ret;

Re: [PATCH 2/3] net: stmmac: Fix error handling path in 'alloc_dma_tx_desc_resources()'

[Giuseppe CAVALLARO]

On 7/8/2017 9:46 AM, Christophe JAILLET wrote:

If the first 'kmalloc_array' within the loop fails, we should free what
as already been allocated, as done in all other error handling path.

Fixes: ce736788e8a9 ("net: stmmac: adding multiple buffers for TX")
Signed-off-by: Christophe JAILLET 

Acked-by: Giuseppe Cavallaro 

---
  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 4322fa4a13e8..07d486a70118 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1561,7 +1561,7 @@ static int alloc_dma_tx_desc_resources(struct stmmac_priv 
*priv)

sizeof(*tx_q->tx_skbuff_dma),
GFP_KERNEL);
if (!tx_q->tx_skbuff_dma)
-   return -ENOMEM;
+   goto err_dma_buffers;
  
  		tx_q->tx_skbuff = kmalloc_array(DMA_TX_SIZE,

sizeof(struct sk_buff *),

Re: [iproute PATCH] ip netns: Make sure netns name is sane

[Stephen Hemminger]

On Mon, 10 Jul 2017 13:19:12 +0200
Phil Sutter  wrote:

> +static bool is_basename(const char *name)
> +{
> + char *name_dup = strdup(name);
> + bool rc = true;
> +
> + if (!name_dup)
> + return false;
> +
> + if (strcmp(basename(name_dup), name))
> + rc = false;
> +
> + free(name_dup);
> + return rc;
> +}

Why not just:

static bool is_basename(const char *name)
{
return strchr(name '/') == NULL;
}

bug in "PCI: Support INTx masking on ConnectX-4 with firmware x.14.1100+"?

[Denys Vlasenko]

+   /* Reading from resource space should be 32b aligned */
+   fw_maj_min = ioread32be(fw_ver);
+   fw_sub_min = ioread32be(fw_ver + 1);
+   fw_major = fw_maj_min & 0x;
+   fw_minor = fw_maj_min >> 16;
+   fw_subminor = fw_sub_min & 0x;

Maybe second read should be ioread32be(fw_ver + 4)?

Re: [RFC PATCH 10/12] xdp: Add batching support to redirect map

[John Fastabend]

On 07/10/2017 10:53 AM, Jesper Dangaard Brouer wrote:
> On Fri, 07 Jul 2017 10:37:59 -0700
> John Fastabend  wrote:
> 
>> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
>> index 36dc13de..656e334 100644
>> --- a/kernel/bpf/devmap.c
>> +++ b/kernel/bpf/devmap.c
> [...]
>>  
>> +void __dev_map_insert_ctx(struct bpf_map *map, u32 key)
>> +{
>> +struct bpf_dtab *dtab = container_of(map, struct bpf_dtab, map);
>> +unsigned long *bitmap = this_cpu_ptr(dtab->flush_needed);
>> +
>> +set_bit(key, bitmap);
>> +}
> 
> I don't like that this adds an atomic op (set_bit) per packet on a fast-path.
> It shows up on a perf top #6 with xdp_redirect_map.
> 

Its a per cpu bitmap so __set_bit() should be fine here.

Thanks,
John

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

Hi Joe,


On Monday 10 July 2017 10:30 PM, Joe Perches wrote:

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.

Once again, I will send all of patch together, But I have doubt. If it's 
having
different maintainer. Example- 'net:' subsystem is having a different 
different
maintainer. So do i need to add all the maintainer in single list. Which 
can confuse

what patch is for what maintainer. Please suggest me.

Thanks ,
~arvind

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Joe Perches]

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:
> Hi Joe,
> 
> 
> On Monday 10 July 2017 10:30 PM, Joe Perches wrote:
> > On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:
> > > attribute_groups are not supposed to change at runtime. All functions
> > > working with attribute_groups provided by  work
> > > with const attribute_group. So mark the non-const structs as const.
> > 
> > I think it's good you are doing all of these.
> > 
> > Instead of individually sending these patches, could you
> > please send a patch series for all of these attribute_group
> > patches with a cover letter at the same time?
> > 
> > That could make it easier for a trivial maintainer to apply
> > all of these at once and not get some applied and others
> > ignored or dropped on the floor.
> > 
> 
> Once again, I will send all of patch together, But I have doubt. If it's 
> having
> different maintainer. Example- 'net:' subsystem is having a different 
> different
> maintainer. So do i need to add all the maintainer in single list. Which 
> can confuse
> what patch is for what maintainer. Please suggest me.

Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:

[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group

Re: [PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

Hi Joe,


On Tuesday 11 July 2017 11:17 AM, Joe Perches wrote:

On Tue, 2017-07-11 at 11:11 +0530, Arvind Yadav wrote:

Hi Joe,


On Monday 10 July 2017 10:30 PM, Joe Perches wrote:

On Mon, 2017-07-10 at 16:04 +0530, Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

I think it's good you are doing all of these.

Instead of individually sending these patches, could you
please send a patch series for all of these attribute_group
patches with a cover letter at the same time?

That could make it easier for a trivial maintainer to apply
all of these at once and not get some applied and others
ignored or dropped on the floor.


Once again, I will send all of patch together, But I have doubt. If it's
having
different maintainer. Example- 'net:' subsystem is having a different
different
maintainer. So do i need to add all the maintainer in single list. Which
can confuse
what patch is for what maintainer. Please suggest me.

Please send individual patches, one per maintainer/subsystem
as a series with a cover letter like:

[PATCH 0/N] treewide: constify attribute_group structures
[PATCH 1/N] chelsio: cxgb3: constify attribute_group
[PATCH 2/N] chelsio: cxgb4: constify attribute_group
...
[PATCH N/N] subsystem: constify attribute_group


Thank you, I will follow as per your suggestion.

Regards,
~arvind

Re: meson-gxbb-p200 4.12.0 network TCP transfer stalls

[Marc Duponcheel]

 I use NBD for fast building and savif SD card and, sadly, the TV box crashes 
after few min of building

On 2017 Jul 11, Marc Duponcheel wrote:
>  FYI
> 
> I changed 4.12.0 drivers/net/phy/realtek.c RTL8211F code to equal the
> 3.14.29 amlogic/ethernet/phy/am_realtek.c code and now the networking
> works without TCP stalls.
> 
> I don't say below patch should be considered mainstream (as maybe some
> 4.12.0 rtl8211f_config_init code should not be removed) but sure
> someone could figure out what best patch is...

--
 Marc Duponcheel
 Velodroomstraat 74 - 2600 Berchem - Belgium
 +32 (0)478 68 10 91 - m...@offline.be

Re: [RFC PATCH 00/12] Implement XDP bpf_redirect vairants

[John Fastabend]

On 07/10/2017 11:30 AM, Jesper Dangaard Brouer wrote:
> On Sat, 8 Jul 2017 21:06:17 +0200
> Jesper Dangaard Brouer  wrote:
> 
>> On Sat, 08 Jul 2017 10:46:18 +0100 (WEST)
>> David Miller  wrote:
>>
>>> From: John Fastabend 
>>> Date: Fri, 07 Jul 2017 10:48:36 -0700
>>>   
 On 07/07/2017 10:34 AM, John Fastabend wrote:
> This series adds two new XDP helper routines bpf_redirect() and
> bpf_redirect_map(). The first variant bpf_redirect() is meant
> to be used the same way it is currently being used by the cls_bpf
> classifier. An xdp packet will be redirected immediately when this
> is called.

 Also other than the typo in the title there ;) I'm going to CC
 the driver maintainers working on XDP (makes for a long CC list but)
 because we would want to try and get support in as many as possible in
 the next merge window.

 For this rev I just implemented on ixgbe because I wrote the
 original XDP support there. I'll volunteer to do virtio as well.
>>>
>>> I went over this series a few times and it looks great to me.
>>> You didn't even give me some coding style issues to pick on :-)  
>>
>> We (Daniel, Andy and I) have been reviewing and improving on this
>> patchset the last couple of weeks ;-).  We had some stability issues,
>> which is why it wasn't published earlier. My plan is to test this
>> latest patchset again, Monday and Tuesday. I'll try to assess stability
>> and provide some performance numbers.
> 
> 
> Damn, I though it was stable, I have been running a lot of performance
> tests, and then this just happened :-(

Thanks, I'll take a look through the code and see if I can come up with
why this might happen. I haven't hit it on my tests yet though.

.John

Re: [PATCH net] samples/bpf: fix a build issue

[Daniel Borkmann]

On 07/10/2017 10:12 PM, Yonghong Song wrote:

From: Yonghong Song 

With latest net-next:

clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not found
  ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in tools/testing/selftests/bpf/bpf_endian.h
and move it to samples/bpf/ directory so that it can used by
both selftests/bpf and samples/bpf. The existing samples/bpf/bpf_helpers.h
is already used by both.

Signed-off-by: Yonghong Song 
---
  {tools/testing/selftests => samples}/bpf/bpf_endian.h | 14 ++


samples/bpf/Makefile already does:

  HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/

If needed we should rather extend the sample's Makefile to pull in
bpf_endian.h also for clang generated files, but not the other way
round. It's both kind of messy, but kernel selftests should not need
to include or depend upon some sample code.

Other than that looks good to me.


  tools/testing/selftests/bpf/Makefile  |  3 ++-
  2 files changed, 16 insertions(+), 1 deletion(-)
  rename {tools/testing/selftests => samples}/bpf/bpf_endian.h (73%)

diff --git a/tools/testing/selftests/bpf/bpf_endian.h b/samples/bpf/bpf_endian.h
similarity index 73%
rename from tools/testing/selftests/bpf/bpf_endian.h
rename to samples/bpf/bpf_endian.h
index 487cbfb..74af266 100644
--- a/tools/testing/selftests/bpf/bpf_endian.h
+++ b/samples/bpf/bpf_endian.h
@@ -23,11 +23,19 @@
  # define __bpf_htons(x)   __builtin_bswap16(x)
  # define __bpf_constant_ntohs(x)  ___constant_swab16(x)
  # define __bpf_constant_htons(x)  ___constant_swab16(x)
+# define __bpf_ntohl(x)__builtin_bswap32(x)
+# define __bpf_htonl(x)__builtin_bswap32(x)
+# define __bpf_constant_ntohl(x)   ___constant_swab32(x)
+# define __bpf_constant_htonl(x)   ___constant_swab32(x)
  #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
  # define __bpf_ntohs(x)   (x)
  # define __bpf_htons(x)   (x)
  # define __bpf_constant_ntohs(x)  (x)
  # define __bpf_constant_htons(x)  (x)
+# define __bpf_ntohl(x)(x)
+# define __bpf_htonl(x)(x)
+# define __bpf_constant_ntohl(x)   (x)
+# define __bpf_constant_htonl(x)   (x)
  #else
  # error "Fix your compiler's __BYTE_ORDER__?!"
  #endif
@@ -38,5 +46,11 @@
  #define bpf_ntohs(x)  \
(__builtin_constant_p(x) ?  \
 __bpf_constant_ntohs(x) : __bpf_ntohs(x))
+#define bpf_htonl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_htonl(x) : __bpf_htonl(x))
+#define bpf_ntohl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_ntohl(x) : __bpf_ntohl(x))

  #endif /* __BPF_ENDIAN__ */
diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index 2ca51a8..f263c6b 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -8,7 +8,8 @@ ifneq ($(wildcard $(GENHDR)),)
GENFLAGS := -DHAVE_GENHDR
  endif

-CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include
+CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include \
+   -I../../../../samples/bpf
  LDLIBS += -lcap -lelf

  TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map 
test_progs \

Re: [PATCH net] samples/bpf: fix a build issue

[Yonghong Song]

On 7/10/17 1:27 PM, Daniel Borkmann wrote:

On 07/10/2017 10:12 PM, Yonghong Song wrote:

From: Yonghong Song 

With latest net-next:

clang  -nostdinc -isystem 
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/include -I./arch/x86/include 
-I./arch/x86/include/generated/uapi -I./arch/x86/include/generated  
-I./include -I./arch/x86/include/uapi -I./include/uapi 
-I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \

-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc 
-march=bpf -filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file 
not found

  ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in 
tools/testing/selftests/bpf/bpf_endian.h

and move it to samples/bpf/ directory so that it can used by
both selftests/bpf and samples/bpf. The existing 
samples/bpf/bpf_helpers.h

is already used by both.

Signed-off-by: Yonghong Song 
---
  {tools/testing/selftests => samples}/bpf/bpf_endian.h | 14 
++


samples/bpf/Makefile already does:

   HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/

If needed we should rather extend the sample's Makefile to pull in
bpf_endian.h also for clang generated files, but not the other way
round. It's both kind of messy, but kernel selftests should not need
to include or depend upon some sample code.


Sounds good. I will then move bpf_helpers.h to selftests as well so
samples/bpf will depend on selftests/bpf, but not the other way around.



Other than that looks good to me.


  tools/testing/selftests/bpf/Makefile  |  3 ++-
  2 files changed, 16 insertions(+), 1 deletion(-)
  rename {tools/testing/selftests => samples}/bpf/bpf_endian.h (73%)

diff --git a/tools/testing/selftests/bpf/bpf_endian.h 
b/samples/bpf/bpf_endian.h

similarity index 73%
rename from tools/testing/selftests/bpf/bpf_endian.h
rename to samples/bpf/bpf_endian.h
index 487cbfb..74af266 100644
--- a/tools/testing/selftests/bpf/bpf_endian.h
+++ b/samples/bpf/bpf_endian.h
@@ -23,11 +23,19 @@
  # define __bpf_htons(x)__builtin_bswap16(x)
  # define __bpf_constant_ntohs(x)___constant_swab16(x)
  # define __bpf_constant_htons(x)___constant_swab16(x)
+# define __bpf_ntohl(x)__builtin_bswap32(x)
+# define __bpf_htonl(x)__builtin_bswap32(x)
+# define __bpf_constant_ntohl(x)___constant_swab32(x)
+# define __bpf_constant_htonl(x)___constant_swab32(x)
  #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
  # define __bpf_ntohs(x)(x)
  # define __bpf_htons(x)(x)
  # define __bpf_constant_ntohs(x)(x)
  # define __bpf_constant_htons(x)(x)
+# define __bpf_ntohl(x)(x)
+# define __bpf_htonl(x)(x)
+# define __bpf_constant_ntohl(x)(x)
+# define __bpf_constant_htonl(x)(x)
  #else
  # error "Fix your compiler's __BYTE_ORDER__?!"
  #endif
@@ -38,5 +46,11 @@
  #define bpf_ntohs(x)\
  (__builtin_constant_p(x) ?\
   __bpf_constant_ntohs(x) : __bpf_ntohs(x))
+#define bpf_htonl(x)\
+(__builtin_constant_p(x) ?\
+ __bpf_constant_htonl(x) : __bpf_htonl(x))
+#define bpf_ntohl(x)\
+(__builtin_constant_p(x) ?\
+ __bpf_constant_ntohl(x) : __bpf_ntohl(x))

  #endif /* __BPF_ENDIAN__ */
diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile

index 2ca51a8..f263c6b 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -8,7 +8,8 @@ ifneq ($(wildcard $(GENHDR)),)
GENFLAGS := -DHAVE_GENHDR
  endif

-CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include
+CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include \

+-I../../../../samples/bpf
  LDLIBS += -lcap -lelf

  TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map 
test_lpm_map test_progs \

Re: [PATCH net] samples/bpf: fix a build issue

[Daniel Borkmann]

On 07/10/2017 10:51 PM, Yonghong Song wrote:

On 7/10/17 1:27 PM, Daniel Borkmann wrote:

On 07/10/2017 10:12 PM, Yonghong Song wrote:

From: Yonghong Song 

With latest net-next:

clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h 
-Isamples/bpf \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not found
  ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in tools/testing/selftests/bpf/bpf_endian.h
and move it to samples/bpf/ directory so that it can used by
both selftests/bpf and samples/bpf. The existing samples/bpf/bpf_helpers.h
is already used by both.

Signed-off-by: Yonghong Song 
---
  {tools/testing/selftests => samples}/bpf/bpf_endian.h | 14 ++


samples/bpf/Makefile already does:

   HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/

If needed we should rather extend the sample's Makefile to pull in
bpf_endian.h also for clang generated files, but not the other way
round. It's both kind of messy, but kernel selftests should not need
to include or depend upon some sample code.


Sounds good. I will then move bpf_helpers.h to selftests as well so
samples/bpf will depend on selftests/bpf, but not the other way around.


Okay, that's fine by me. (We can later also move some of the test
cases over to selftests, so that they get generally more coverage.)
Thanks, Yonghong!

Re: [PATCH net-next RFC 05/12] net: dsa: Add support for learning FDB through notification

[Vivien Didelot]

Hi Arkadi,

Arkadi Sharshevsky  writes:

>>> +   err = dsa_port_fdb_add(p->dp, fdb_info->addr, fdb_info->vid);
>>> +   if (err) {
>>> +   netdev_dbg(dev, "fdb add failed err=%d\n", err);
>>> +   break;
>>> +   }
>>> +   call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED, dev,
>>> +_info->info);
>>> +   break;
>>> +
>>> +   case SWITCHDEV_FDB_DEL_TO_DEVICE:
>>> +   fdb_info = _work->fdb_info;
>>> +   err = dsa_port_fdb_del(p->dp, fdb_info->addr, fdb_info->vid);
>>> +   if (err)
>>> +   netdev_dbg(dev, "fdb del failed err=%d\n", err);
>> 
>> OK I must have missed from the off-list discussion why we are not
>> calling the switchdev notifier here?
>
> We do not agree on it actually, that is why it was moved to the list.
> I think that delete should succeed, you should retry until succession.
>
> The deletion is done under spinlock in the bridge so you cannot block,
> thus delete cannot fail due to hardware failure. Calling it here doesn't
> make sense because the bridge probably already deleted this FDB.

So as we discussed, the problem here is that if dsa_port_fdb_del fails
for some probable reasons (MDIO timeout, weak GPIO lines, etc.), Linux
bridge will delete the entry in software, dumping bridge fdb will show
nothing, but the entry would still be programmed in hardware and the
network can thus be inconsistent, unsupposedly switching frames.

IMHO the correct way for bridge to use the notification chain is to make
SWITCHDEV_FDB_DEL_TO_DEVICE symmetrical to SWITCHDEV_FDB_ADD_TO_DEVICE:
if an entry has been marked as offloaded, bridge must mark the entry as
to-be-deleted and do not delete the software entry until the driver
notifies back the successful deletion.

If that is hardly feasible due to some bridge limitations, we must
explain this in a comment and use something more explosive than a simple
netdev_dbg to warn the user about the broken network setup...


Thanks,

Vivien

[PATCH net v2] samples/bpf: fix a build issue

[Yonghong Song]

With latest net-next:

clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not found
  ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in tools/testing/selftests/bpf/bpf_endian.h.
Also move bpf_helpers.h from samples/bpf to selftests/bpf and change
compiler include logic so that programs in samples/bpf can access the headers
in selftests/bpf, but not the other way around.

Signed-off-by: Yonghong Song 
---
 samples/bpf/Makefile   |  1 +
 tools/testing/selftests/bpf/Makefile   |  1 -
 tools/testing/selftests/bpf/bpf_endian.h   | 14 ++
 {samples => tools/testing/selftests}/bpf/bpf_helpers.h |  0
 4 files changed, 15 insertions(+), 1 deletion(-)
 rename {samples => tools/testing/selftests}/bpf/bpf_helpers.h (100%)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 9c65058..87246be 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -207,6 +207,7 @@ $(obj)/tracex5_kern.o: $(obj)/syscall_nrs.h
 # useless for BPF samples.
 $(obj)/%.o: $(src)/%.c
$(CLANG) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) -I$(obj) \
+   -I$(srctree)/tools/testing/selftests/bpf/ \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value 
-Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index 2ca51a8..153c3a1 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -37,6 +37,5 @@ CLANG ?= clang
 
 %.o: %.c
$(CLANG) -I. -I./include/uapi -I../../../include/uapi \
-   -I../../../../samples/bpf/ \
-Wno-compare-distinct-pointer-types \
-O2 -target bpf -c $< -o $@
diff --git a/tools/testing/selftests/bpf/bpf_endian.h 
b/tools/testing/selftests/bpf/bpf_endian.h
index 487cbfb..74af266 100644
--- a/tools/testing/selftests/bpf/bpf_endian.h
+++ b/tools/testing/selftests/bpf/bpf_endian.h
@@ -23,11 +23,19 @@
 # define __bpf_htons(x)__builtin_bswap16(x)
 # define __bpf_constant_ntohs(x)   ___constant_swab16(x)
 # define __bpf_constant_htons(x)   ___constant_swab16(x)
+# define __bpf_ntohl(x)__builtin_bswap32(x)
+# define __bpf_htonl(x)__builtin_bswap32(x)
+# define __bpf_constant_ntohl(x)   ___constant_swab32(x)
+# define __bpf_constant_htonl(x)   ___constant_swab32(x)
 #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 # define __bpf_ntohs(x)(x)
 # define __bpf_htons(x)(x)
 # define __bpf_constant_ntohs(x)   (x)
 # define __bpf_constant_htons(x)   (x)
+# define __bpf_ntohl(x)(x)
+# define __bpf_htonl(x)(x)
+# define __bpf_constant_ntohl(x)   (x)
+# define __bpf_constant_htonl(x)   (x)
 #else
 # error "Fix your compiler's __BYTE_ORDER__?!"
 #endif
@@ -38,5 +46,11 @@
 #define bpf_ntohs(x)   \
(__builtin_constant_p(x) ?  \
 __bpf_constant_ntohs(x) : __bpf_ntohs(x))
+#define bpf_htonl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_htonl(x) : __bpf_htonl(x))
+#define bpf_ntohl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_ntohl(x) : __bpf_ntohl(x))
 
 #endif /* __BPF_ENDIAN__ */
diff --git a/samples/bpf/bpf_helpers.h 
b/tools/testing/selftests/bpf/bpf_helpers.h
similarity index 100%
rename from samples/bpf/bpf_helpers.h
rename to tools/testing/selftests/bpf/bpf_helpers.h
-- 
2.9.3

Re: [PATCH net v2] samples/bpf: fix a build issue

[Daniel Borkmann]

On 07/10/2017 11:04 PM, Yonghong Song wrote:

With latest net-next:

clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \
 -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
 -Wno-compare-distinct-pointer-types \
 -Wno-gnu-variable-sized-type-not-at-end \
 -Wno-address-of-packed-member -Wno-tautological-compare \
 -Wno-unknown-warning-option \
 -O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not found
   ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in tools/testing/selftests/bpf/bpf_endian.h.
Also move bpf_helpers.h from samples/bpf to selftests/bpf and change
compiler include logic so that programs in samples/bpf can access the headers
in selftests/bpf, but not the other way around.

Signed-off-by: Yonghong Song 


LGTM, thanks!

Acked-by: Daniel Borkmann 

Re: WARN_ON_ONCE(work > weight) in napi_poll()

[Ryan Hsu]

On 07/04/2017 08:59 AM, Andrey Ryabinin wrote:

> On 07/04/2017 04:49 PM, Kalle Valo wrote:
>> Andrey Ryabinin  writes:
>>
>>> I occasionally hit WARN_ON_ONCE(work > weight); in napi_poll() on a
>>> laptop with ath10k card.
>>>
>>>
>>> [37207.593370] [ cut here ]
>>> [37207.593380] WARNING: CPU: 0 PID: 7 at ../net/core/dev.c:5274
>>> net_rx_action+0x258/0x360
>>> [37207.593381] Modules linked in: snd_hda_codec_realtek snd_soc_skl
>>> snd_hda_codec_generic snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp
>>> snd_hda_ext_core snd_soc_sst_match snd_soc_core rtsx_pci_sdmmc
>>> mmc_core snd_pcm_dmaengine x86_pkg_temp_thermal snd_hda_intel uvcvideo
>>> kvm_intel videobuf2_vmalloc kvm snd_hda_codec snd_hwdep btusb
>>> videobuf2_memops btintel snd_hda_core videobuf2_v4l2 bluetooth
>>> irqbypass snd_pcm videobuf2_core crc32c_intel videodev mei_me mei
>>> rtsx_pci intel_lpss_pci intel_lpss_acpi intel_vbtn intel_lpss mfd_core
>>> tpm_tis intel_hid tpm_tis_core tpm efivarfs
>>> [37207.593430] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.11.7 #28
>>> [37207.593432] Hardware name: Dell Inc. XPS 13 9360/0839Y6, BIOS 1.3.5 
>>> 05/08/2017
>> What firmware and hardware versions exactly? The dmesg output when
>> ath10k loads is preferred. As you are using XPS 13 I'm guessing it's one
>> of QCA6174 family.
>>
> Yes it's qca6174.
>
> $ dmesg |grep ath10
> [0.624828] ath10k_pci :3a:00.0: enabling device ( -> 0002)
> [0.626370] ath10k_pci :3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 
> 0 reset_mode 0
> [0.837862] ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 
> chip_id 0x00340aff sub 1a56:1535
> [0.837863] ath10k_pci :3a:00.0: kconfig debug 0 debugfs 1 tracing 0 
> dfs 0 testmode 0
> [0.838388] ath10k_pci :3a:00.0: firmware ver 
> WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad 
> crc32 75dee6c5
> [0.900606] ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 
> 19644295
> [3.020681] ath10k_pci :3a:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal 
> otp max-sta 32 raw 0 hwcrypto 1
> [9.574087] ath10k_pci :3a:00.0 wlp58s0: renamed from wlan0
>

I can't reproduce of this past few days, not sure if this is due to the amsdu 
packets received from AP, would you mind share what Ap you're using?
And if there any specific steps you're doing?

Also WLAN.RM.2.0-00180-QCARMSWPZ-1 firmware is a bit old, could you also update 
firmware to give it a try?
https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0/4.4

-- 
Ryan Hsu

Re: [PATCH net] samples/bpf: fix a build issue

[Lawrence Brakmo]

Thank you for fixing it.

On 7/10/17, 1:12 PM, "Yonghong Song"  wrote:

From: Yonghong Song 

With latest net-next:

clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
-Isamples/bpf \
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c samples/bpf/tcp_synrto_kern.c -o -| llc -march=bpf 
-filetype=obj -o samples/bpf/tcp_synrto_kern.o
samples/bpf/tcp_synrto_kern.c:20:10: fatal error: 'bpf_endian.h' file not 
found
 ^~
1 error generated.


net has the same issue.

Add support for ntohl and htonl in tools/testing/selftests/bpf/bpf_endian.h
and move it to samples/bpf/ directory so that it can used by
both selftests/bpf and samples/bpf. The existing samples/bpf/bpf_helpers.h
is already used by both.

Signed-off-by: Yonghong Song y...@fb.com

Acked-by: Lawrence Brakmo 

---
 {tools/testing/selftests => samples}/bpf/bpf_endian.h | 14 ++
 tools/testing/selftests/bpf/Makefile  |  3 ++-
 2 files changed, 16 insertions(+), 1 deletion(-)
 rename {tools/testing/selftests => samples}/bpf/bpf_endian.h (73%)

diff --git a/tools/testing/selftests/bpf/bpf_endian.h 
b/samples/bpf/bpf_endian.h
similarity index 73%
rename from tools/testing/selftests/bpf/bpf_endian.h
rename to samples/bpf/bpf_endian.h
index 487cbfb..74af266 100644
--- a/tools/testing/selftests/bpf/bpf_endian.h
+++ b/samples/bpf/bpf_endian.h
@@ -23,11 +23,19 @@
 # define __bpf_htons(x)__builtin_bswap16(x)
 # define __bpf_constant_ntohs(x)   ___constant_swab16(x)
 # define __bpf_constant_htons(x)   ___constant_swab16(x)
+# define __bpf_ntohl(x)__builtin_bswap32(x)
+# define __bpf_htonl(x)__builtin_bswap32(x)
+# define __bpf_constant_ntohl(x)   ___constant_swab32(x)
+# define __bpf_constant_htonl(x)   ___constant_swab32(x)
 #elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
 # define __bpf_ntohs(x)(x)
 # define __bpf_htons(x)(x)
 # define __bpf_constant_ntohs(x)   (x)
 # define __bpf_constant_htons(x)   (x)
+# define __bpf_ntohl(x)(x)
+# define __bpf_htonl(x)(x)
+# define __bpf_constant_ntohl(x)   (x)
+# define __bpf_constant_htonl(x)   (x)
 #else
 # error "Fix your compiler's __BYTE_ORDER__?!"
 #endif
@@ -38,5 +46,11 @@
 #define bpf_ntohs(x)   \
(__builtin_constant_p(x) ?  \
 __bpf_constant_ntohs(x) : __bpf_ntohs(x))
+#define bpf_htonl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_htonl(x) : __bpf_htonl(x))
+#define bpf_ntohl(x)   \
+   (__builtin_constant_p(x) ?  \
+__bpf_constant_ntohl(x) : __bpf_ntohl(x))
 
 #endif /* __BPF_ENDIAN__ */
diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index 2ca51a8..f263c6b 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -8,7 +8,8 @@ ifneq ($(wildcard $(GENHDR)),)
   GENFLAGS := -DHAVE_GENHDR
 endif
 
-CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include
+CFLAGS += -Wall -O2 -I$(APIDIR) -I$(LIBDIR) -I$(GENDIR) $(GENFLAGS) 
-I../../../include \
+   -I../../../../samples/bpf
 LDLIBS += -lcap -lelf
 
 TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map 
test_lpm_map test_progs \
-- 
2.9.4

[PATCH] wireless: ipw2200: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 9368abd..c311b1a 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11500,7 +11500,7 @@ static int ipw_wdev_init(struct net_device *dev)
NULL
 };
 
-static struct attribute_group ipw_attribute_group = {
+static const struct attribute_group ipw_attribute_group = {
.name = NULL,   /* put in device directory */
.attrs = ipw_sysfs_entries,
 };
-- 
1.9.1

[PATCH] wireless: ipw2100: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index aaaca4d..ccbe745 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4324,7 +4324,7 @@ static ssize_t store_rf_kill(struct device *d, struct 
device_attribute *attr,
NULL,
 };
 
-static struct attribute_group ipw2100_attribute_group = {
+static const struct attribute_group ipw2100_attribute_group = {
.attrs = ipw2100_sysfs_entries,
 };
 
-- 
1.9.1

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

[Richard Cochran]

On Mon, Jul 10, 2017 at 12:38:16PM +0300, Dan Carpenter wrote:
> There were two buggy commits so I chose the ealier one.  The other buggy

No, you are mistaken.  In the original patch, NULL or PTR_ERR were
returned on error, and that was not a bug.

If you want to correct the present version of ptp_clock_register() to
always return a valid pointer or PTR_ERR (like the kerneldoc says), be
my guest, but please say that in the change log and reference the
correct commit (namely the one related to disabling POSIX clocks.)

Thanks,
Richard

Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

[Rafał Miłecki]

On 7 July 2017 at 16:09, Russell Joyce  wrote:
> Add three basic LED triggers to brcmfmac, based on those in mac80211: one
> for transmit, one for receive, and one for combined transmit/receive.
>
> Signed-off-by: Russell Joyce 

1) I think most of it should be some cfg80211 shareable code.
2) This "rxtx" while surely present in other places sounds like a
workaround for LED subsystem limitation. Maybe it's time to finally
rework LED triggers.

RE: [PATCH iproute2] ip: change flag names to an array

[David Laight]

From:  Stephen Hemminger
> Sent: 07 July 2017 16:40
> For the most of the address flags, use a table of bit values rather
> than open coding every value.  This allows for easier inevitable
> expansion of flags.
> 
> This also fixes the missing stable-privacy flag.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  ip/ipaddress.c | 152 
> -
>  1 file changed, 65 insertions(+), 87 deletions(-)
> 
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index f06f5829fb61..b4efb9fedcd2 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -1013,14 +1013,67 @@ static unsigned int get_ifa_flags(struct ifaddrmsg 
> *ifa,
>   ifa->ifa_flags;
>  }
> 
> +
> +static const char *ifa_flag_names[] = {
> + "secondary",
> + "nodad",
> + "optimistic",
> + "dadfailed",
> + "home",
> + "deprecated",
> + "tentative",
> + "permanent",
> + "mngtmpaddr",
> + "noprefixroute",
> + "autojoin",
> + "stable-privacy",
> +};

It would be safer to set up a table of the constant - string pairs
instead of relying on the table being in the right order.

David

[PATCH] wireless: iwlegacy: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c 
b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index 38bf403..329f3a6 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -3464,7 +3464,7 @@ static DEVICE_ATTR(antenna, S_IWUSR | S_IRUGO, 
il3945_show_antenna,
NULL
 };
 
-static struct attribute_group il3945_attribute_group = {
+static const struct attribute_group il3945_attribute_group = {
.name = NULL,   /* put in device directory */
.attrs = il3945_sysfs_entries,
 };
-- 
1.9.1

[PATCH] wireless: iwlegacy: Constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c 
b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
index 5b51fba..de9b652 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
@@ -4654,7 +4654,7 @@ static DEVICE_ATTR(tx_power, S_IWUSR | S_IRUGO, 
il4965_show_tx_power,
NULL
 };
 
-static struct attribute_group il_attribute_group = {
+static const struct attribute_group il_attribute_group = {
.name = NULL,   /* put in device directory */
.attrs = il_sysfs_entries,
 };
-- 
1.9.1

Re: [PATCH 2/2 net] cxgb4: ptp_clock_register() returns error pointers

[Richard Cochran]

On Mon, Jul 10, 2017 at 10:16:15AM +0300, Dan Carpenter wrote:
> We're checking ptp_clock_register() for NULL but we should be checking
> for error pointers.

No.

> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
> index 50517cfd9671..c24313a103c6 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ptp.c
> @@ -441,7 +441,7 @@ void cxgb4_ptp_init(struct adapter *adapter)
>  
>   adapter->ptp_clock = ptp_clock_register(>ptp_clock_info,
>   >pdev->dev);
> - if (!adapter->ptp_clock) {

Yeah, that is wrong, but the fix is to check to IS_ERR or NULL.

Thanks,
Richard

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

Hi Casey:

On 2017/7/8 10:04, Casey Leedom wrote:
>   Okay, thanks for the note Alexander.I'll have to look more closely 
> at
> the patch on Monday and try it out on one of the targeted systems to verify
> the semantics you describe.
> 

All the modification is only clearing the device's Device Control{Relaxed 
Ordering
Enable]bit when distinguish that the platform should not support RO and did 
nothing
to the RC configuration, so I don't think it will break anything compare to the
first version from yours.

>   However, that said, there is no way to tell a priori where a device will
> send TLPs.  To simply assume that all TLPs will be directed towards the Root
> Complex is a big assumption.  Only the device and the code controlling it
> know where the TLPs will be directed.  That's why there are changes required
> in the cxgb4 driver.  For instance, the code in
> drivers/net/ethernet/chelsio./cxgb4/sge.c: t4_sge_alloc_rxq() knows that
> it's allocating Free List Buffers in Host Memory and that the RX Queues that
> it's allocating in the Hardware will eventually send Ingress Data to those
> Free List Buffers.  (And similarly for the Free List Buffer Pointer Queue
> with respect to DMA Reads from the host.)  In that routine we explicitly
> configure the Hardware to use/not-use the Relaxed Ordering Attribute via the
> FW_IQ_CMD_FL0FETCHRO and FW_IQ_CMD_FL0DATARO flags.  Basically we're
> conditionally setting them based on the desirability of sending Relaxed
> Ordering TLPs to the Root Complex.  (And we would perform the same kind of
> check for an nVME application ... which brings us to ...)
> 
>   And what would be the code using these patch APIs to set up a Peer-to-Peer
> nVME-style application?In that case we'd need the Chelsio adapter's 
> PCIe
> Capability Device Control[Relaxed Ordering Enable] set for the nVME
> application ... and we would avoid programming the Chelsio Hardware to use
> Relaxed Ordering for TLPs directed at the Root Complex.Thus we would 
> be in
> a position where some TLPs being emitted by the device to Peer devices would
> have Relaxed Ordering set and some directed at the Root Complex would not.
> And the only way for that to work is if the source device's Device
> Control[Relaxed Ordering Enable] is set ...
> 
>   Finally, setting aside my disagreements with the patch, we still have the
> code in the cxgb4 driver which explicitly turns on its own Device
> Control[Relaxed Ordering Enable] in cxgb4_main.c:
> enable_pcie_relaxed_ordering().  So the patch is something of a loop if all
> we're doing is testing our own Relaxed Ordering Enable state ...
>  
> Casey
> 
> .
> 

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

[Richard Cochran]

On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote:
> The ptp_clock_register() function returns NULL when it's #ifdefed out
> because CONFIG_PTP_1588_CLOCK is disabled.  Otherwise, it's intended to
> return error pointers.  Unfortunately, there are a couple paths where we
> forget to set the error code.  It means that we could result in NULL
> pointer dereferences in the callers.
> 
> Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.")

This "Fixes" tag references the wrong commit.  Please correct it.

Thanks,
Richard

Re: [PATCH v 1/2] ravb: Add support for r8a7743 SoC

[Sergei Shtylyov]

Hello!

On 7/10/2017 4:20 AM, Rob Herring wrote:


Add support for Gigabit Ethernet E-MAC on r8a7743 (RZ/G1M) SoC.
Renesas RZ/G1M (R8A7743) SoC Ethernet AVB IP is identical to the R-Car Gen2
family.


For the subject: "dt-bindings: net: ..."



Signed-off-by: Biju Das 
Reviewed-by: Chris Paterson 
---
  Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
  drivers/net/ethernet/renesas/ravb_main.c   | 1 +
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt 
b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index b519503..bc692ab 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -4,7 +4,8 @@ This file provides information on what the device node for the 
Ethernet AVB
  interface contains.
  
  Required properties:

-- compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 
SoC.
+- compatible: "renesas,etheravb-r8a7743" if the device is a part of R8A7743 
SoC.
+ "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC.


Please re-format like this:

- compatible: Must be one of:
...

So it's a one line change to add new compatibles.


   Note that the common gen2/3 values are at end of this list, so they'll 
need different treating if you add these words.


MBR, Sergei

Re: [GIT] Networking

[Herbert Xu]

On Sun, Jul 09, 2017 at 09:40:43PM +0100, David Miller wrote:
>
> > It look like PF_ALG sets up a ->sk in alg_create() (but this
> > would get over-written in alg_accept()?) 

No it does not.  The struct socket comes from sys_accept() and
AFAICS it doesn't carry a struck sock with it.

> > Cc'ing Herbert to see if this is expected behavior (and PF_ALG
> > somehow does the right thing with the refcount for the ->sk
> > set up in alg_create) in which case I suppose we should drop the 
> > WARN_ON. 
> 
> I think we've found yet another socket leak, this time in
> AF_ALG.

Hmm, I can't see the problem in af_alg_accept.  The struct socket
comes directly from sys_accept() which creates it using sock_alloc.

So the only thing I can think of is that the memory returned by
sock_alloc is not zeroed and therefore the WARN_ON is just reading
garbage.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] arcnet: com20020-pci: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   3409 948  2843851121 drivers/net/arcnet/com20020-pci.o

File size After adding 'const':
   textdata bss dec hex filename
   3473 884  2843851121 drivers/net/arcnet/com20020-pci.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/arcnet/com20020-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/arcnet/com20020-pci.c 
b/drivers/net/arcnet/com20020-pci.c
index 01cab95..eb7f767 100644
--- a/drivers/net/arcnet/com20020-pci.c
+++ b/drivers/net/arcnet/com20020-pci.c
@@ -109,7 +109,7 @@ static ssize_t backplane_mode_show(struct device *dev,
NULL,
 };
 
-static struct attribute_group com20020_state_group = {
+static const struct attribute_group com20020_state_group = {
.name = NULL,
.attrs = com20020_state_attrs,
 };
-- 
1.9.1

[PATCH] net: bonding: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   45121472   059841760 drivers/net/bonding/bond_sysfs.o

File size After adding 'const':
   textdata bss dec hex filename
   45761408   059841760 drivers/net/bonding/bond_sysfs.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/bonding/bond_sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 770623a..040b493 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -759,7 +759,7 @@ static DEVICE_ATTR(ad_user_port_key, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group bonding_group = {
+static const struct attribute_group bonding_group = {
.name = "bonding",
.attrs = per_bond_attrs,
 };
-- 
1.9.1

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

[Dan Carpenter]

On Mon, Jul 10, 2017 at 11:48:06AM +0200, Richard Cochran wrote:
> On Mon, Jul 10, 2017 at 12:38:16PM +0300, Dan Carpenter wrote:
> > There were two buggy commits so I chose the ealier one.  The other buggy
> 
> No, you are mistaken.  In the original patch, NULL or PTR_ERR were
> returned on error, and that was not a bug.
> 

The "goto no_pps" was a bug you introduced.

But I feel like you're being rude, so I'm not going to resend these
patches.  Please fix them yourself.

regards,
dan carpenter

[PATCH] net: chelsio: cxgb3: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  28720 985  12   297177415 drivers/net/.../cxgb3/cxgb3_main.o

File size After adding 'const':
   textdata bss dec hex filename
  28848 857  12   297177415 drivers/net/.../cxgb3/cxgb3_main.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c 
b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index 0bc6a4f..6a01536 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -793,7 +793,9 @@ static DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show_##name, 
store_method)
NULL
 };
 
-static struct attribute_group cxgb3_attr_group = {.attrs = cxgb3_attrs };
+static const struct attribute_group cxgb3_attr_group = {
+   .attrs = cxgb3_attrs,
+};
 
 static ssize_t tm_attr_show(struct device *d,
char *buf, int sched)
@@ -880,7 +882,9 @@ static DEVICE_ATTR(name, S_IRUGO | S_IWUSR, show_##name, 
store_##name)
NULL
 };
 
-static struct attribute_group offload_attr_group = {.attrs = offload_attrs };
+static const struct attribute_group offload_attr_group = {
+   .attrs = offload_attrs,
+};
 
 /*
  * Sends an sk_buff to an offload queue driver
-- 
1.9.1

[iproute PATCH] ip netns: Make sure netns name is sane

[Phil Sutter]

In order to keep track of created netns, 'ip netns' creates a mount
point inside NETNS_RUN_DIR. By not checking the user-specified name, it
allowed to create that mount point outside of NETNS_RUN_DIR and hence
lose track of it afterwards:

| # ip netns add ../../tmp/foobar
| # ip netns list
| # mount | grep foobar
| nsfs on /tmp/foobar type nsfs (rw)

Prevent this by making sure basename() does not see a need to alter the
given netns name.

Fixes: 0dc34c7713bb7 ("iproute2: Add processless network namespace support")
Signed-off-by: Phil Sutter 
---
 ip/ipnetns.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 0b0378ab6560c..4eee85e146b3d 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -595,6 +595,21 @@ static int create_netns_dir(void)
return 0;
 }
 
+static bool is_basename(const char *name)
+{
+   char *name_dup = strdup(name);
+   bool rc = true;
+
+   if (!name_dup)
+   return false;
+
+   if (strcmp(basename(name_dup), name))
+   rc = false;
+
+   free(name_dup);
+   return rc;
+}
+
 static int netns_add(int argc, char **argv)
 {
/* This function creates a new network namespace and
@@ -616,6 +631,11 @@ static int netns_add(int argc, char **argv)
}
name = argv[0];
 
+   if (!is_basename(name)) {
+   fprintf(stderr, "Invalid netns name: contains path 
components\n");
+   return -1;
+   }
+
snprintf(netns_path, sizeof(netns_path), "%s/%s", NETNS_RUN_DIR, name);
 
if (create_netns_dir())
-- 
2.13.1

Re: [PATCH 1/2] netdevice: add netdev_pub helper function

[Jason A. Donenfeld]

On Mon, Jul 10, 2017 at 10:04 AM, David Miller  wrote:
> I disagree.  Assuming one can go from the driver private to the netdev
> object trivially is a worse assumption than the other way around, and
> locks us into the current implementation of how the netdev and driver
> private memory is allocated.
>
> If you want to style your driver such that the private is passed
> around instead of the netdev, put a pointer back to the netdev object
> in your private data structure.

I'm surprised you're okay with the memory waste of that, but you bring
up the ability to change the interface later, which is a great point.
I'll submit a patch for that random driver, and I'll also refactor
WireGuard to do the same. Thanks for the guidance.

Jason

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

[Richard Cochran]

On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote:
> The ptp_clock_register() function returns NULL when it's #ifdefed out
> because CONFIG_PTP_1588_CLOCK is disabled.  Otherwise, it's intended to
> return error pointers.  Unfortunately, there are a couple paths where we
> forget to set the error code.  It means that we could result in NULL
> pointer dereferences in the callers.

Actually, this description is bogus.  Callers will not dereference
NULL, because they are required to check the returned pointer:

/**
 * ptp_clock_register() - register a PTP hardware clock driver
 *
 * @info:   Structure describing the new clock.
 * @parent: Pointer to the parent device of the new clock.
 *
 * Returns a valid pointer on success or PTR_ERR on failure.  If PHC
 * support is missing at the configuration level, this function
 * returns NULL, and drivers are expected to gracefully handle that
 * case separately.
 */

Thanks,
Richard

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

[Dan Carpenter]

On Mon, Jul 10, 2017 at 11:21:03AM +0200, Richard Cochran wrote:
> On Mon, Jul 10, 2017 at 10:11:37AM +0300, Dan Carpenter wrote:
> > The ptp_clock_register() function returns NULL when it's #ifdefed out
> > because CONFIG_PTP_1588_CLOCK is disabled.  Otherwise, it's intended to
> > return error pointers.  Unfortunately, there are a couple paths where we
> > forget to set the error code.  It means that we could result in NULL
> > pointer dereferences in the callers.
> > 
> > Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.")
> 
> This "Fixes" tag references the wrong commit.  Please correct it.
> 

There were two buggy commits so I chose the ealier one.  The other buggy
commit is 85a66e550195 ("ptp: create "pins" together with the rest of
attributes").  I should have CC'd Dmitry as well.  I can resend.

regards,
dan carpenter

[PATCH] net/mlx5: IPSec, fix 64-bit division correctly

[Arnd Bergmann]

The new IPSec offload code introduced a build error:

drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function 
`mlx5e_ipsec_build_inverse_table':
ipsec_rxtx.c:(.text+0x556): undefined reference

Another patch was added on top to fix the build error, but
that introduced a new bug, as we now use the remainder of
the division rather than the result.

This makes it use the correct helper function instead.

Fixes: 5dfd87b67cd9 ("net/mlx5: IPSec, Fix 64-bit division on 32-bit builds")
Fixes: 2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data path")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
index 7d06c673851a..4614ddfa91eb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
@@ -363,7 +363,6 @@ void mlx5e_ipsec_build_inverse_table(void)
 {
u16 mss_inv;
u32 mss;
-   u64 n;
 
/* Calculate 1/x inverse table for use in GSO data path.
 * Using this table, we provide the IPSec accelerator with the value of
@@ -373,8 +372,7 @@ void mlx5e_ipsec_build_inverse_table(void)
 */
mlx5e_ipsec_inverse_table[1] = htons(0x);
for (mss = 2; mss < MAX_LSO_MSS; mss++) {
-   n = 1ULL << 32;
-   mss_inv = do_div(n, mss) >> 16;
+   mss_inv = div_u64(1ULL << 32, mss) >> 16;
mlx5e_ipsec_inverse_table[mss] = htons(mss_inv);
}
 }
-- 
2.9.0

Re: [PATCH v2] net: axienet: add support for standard phy-mode binding

[Alvaro Gamez Machado]

On Fri, Jul 07, 2017 at 10:16:31AM -0700, Florian Fainelli wrote:
> On 07/06/2017 11:50 PM, Alvaro Gamez Machado wrote:
> > Keep supporting proprietary "xlnx,phy-type" attribute and add support for
> > MII connectivity to the PHY.
> > 
> > Signed-off-by: Alvaro Gamez Machado 
> > ---
> > diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h 
> > b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> > index af27f7d1cbf3..48e939a5fa31 100644
> > --- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
> > +++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> > @@ -389,7 +389,7 @@ struct axidma_bd {
> >   * @dma_err_tasklet: Tasklet structure to process Axi DMA errors
> >   * @tx_irq:Axidma TX IRQ number
> >   * @rx_irq:Axidma RX IRQ number
> > - * @phy_type:  Phy type to identify between MII/GMII/RGMII/SGMII/1000 
> > Base-X
> > + * @phy_mode:  Phy type to identify between MII/GMII/RGMII/SGMII/1000 
> > Base-X
> >   * @options:   AxiEthernet option word
> >   * @last_link: Phy link state in which the PHY was negotiated earlier
> >   * @features:  Stores the extended features supported by the axienet hw
> > @@ -432,7 +432,7 @@ struct axienet_local {
> >  
> > int tx_irq;
> > int rx_irq;
> > -   u32 phy_type;
> > +   u32 phy_mode;
> 
> Can you use phy_interface_t here for storing this value?

Sure!

> 
> > @@ -1539,7 +1532,38 @@ static int axienet_probe(struct platform_device 
> > *pdev)
> >  * the device-tree and accordingly set flags.
> >  */
> > of_property_read_u32(pdev->dev.of_node, "xlnx,rxmem", >rxmem);
> > -   of_property_read_u32(pdev->dev.of_node, "xlnx,phy-type", >phy_type);
> > +
> > +   /* Start with the proprietary, and broken phy_type */
> > +   ret = of_property_read_u32(pdev->dev.of_node, "xlnx,phy-type", );
> > +   if (!ret) {
> > +   netdev_warn(ndev, "Please upgrade your device tree binary blob 
> > to use phy-mode");
> > +   switch (value) {
> > +   case XAE_PHY_TYPE_MII:
> > +   lp->phy_mode = PHY_INTERFACE_MODE_MII;
> > +   break;
> > +   case XAE_PHY_TYPE_GMII:
> > +   lp->phy_mode = PHY_INTERFACE_MODE_GMII;
> > +   break;
> > +   case XAE_PHY_TYPE_RGMII_2_0:
> > +   lp->phy_mode = PHY_INTERFACE_MODE_RGMII;
> 
> This should be PHY_INTERFACE_MODE_RGMII_ID.

Yes, thank you, Andrew already noticed that. Sorry I didn't see it myself.

Since Andrew told me that netdev is closed for patches right now, I'll wait
until next week to send these changes.

Thanks to both of you for your assistance on this small patch!

-- 
Alvaro G. M.

RE: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

[Ilan Tayari]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
> 
> The new IPSec offload code introduced a build error:
> 
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> `mlx5e_ipsec_build_inverse_table':
> ipsec_rxtx.c:(.text+0x556): undefined reference
> 
> Another patch was added on top to fix the build error, but
> that introduced a new bug, as we now use the remainder of
> the division rather than the result.
> 
> This makes it use the correct helper function instead.
> 
> Fixes: 5dfd87b67cd9 ("net/mlx5: IPSec, Fix 64-bit division on 32-bit
> builds")
> Fixes: 2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data
> path")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
> index 7d06c673851a..4614ddfa91eb 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c
> @@ -363,7 +363,6 @@ void mlx5e_ipsec_build_inverse_table(void)
>  {
>   u16 mss_inv;
>   u32 mss;
> - u64 n;
> 
>   /* Calculate 1/x inverse table for use in GSO data path.
>* Using this table, we provide the IPSec accelerator with the value
> of
> @@ -373,8 +372,7 @@ void mlx5e_ipsec_build_inverse_table(void)
>*/
>   mlx5e_ipsec_inverse_table[1] = htons(0x);
>   for (mss = 2; mss < MAX_LSO_MSS; mss++) {
> - n = 1ULL << 32;
> - mss_inv = do_div(n, mss) >> 16;
> + mss_inv = div_u64(1ULL << 32, mss) >> 16;

Thanks Arnd, 

:o
I'm surprised... let me check this...

>   mlx5e_ipsec_inverse_table[mss] = htons(mss_inv);
>   }
>  }
> --
> 2.9.0

RE: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly

[Ilan Tayari]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Subject: [PATCH] net/mlx5: IPSec, fix 64-bit division correctly
> 
> The new IPSec offload code introduced a build error:
> 
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.o: In function
> `mlx5e_ipsec_build_inverse_table':
> ipsec_rxtx.c:(.text+0x556): undefined reference
> 
> Another patch was added on top to fix the build error, but
> that introduced a new bug, as we now use the remainder of
> the division rather than the result.
> 
> This makes it use the correct helper function instead.
> 
> Fixes: 5dfd87b67cd9 ("net/mlx5: IPSec, Fix 64-bit division on 32-bit
> builds")
> Fixes: 2ac9cfe78223 ("net/mlx5e: IPSec, Add Innova IPSec offload TX data
> path")
> Signed-off-by: Arnd Bergmann 

This is a good fix. Values are now generated correctly.
Sorry for the mixup.

Thank you Arnd!

Reviewed-by: Ilan Tayari 

Re: [PATCH 1/2 net] ptp: fix error codes in ptp_clock_register()

[Richard Cochran]

On Mon, Jul 10, 2017 at 01:29:20PM +0300, Dan Carpenter wrote:
> The "goto no_pps" was a bug you introduced.

I took a second look, and yes, the original commit should not have
returned NULL, and the original callers did not expect NULL either.
 
> But I feel like you're being rude, so I'm not going to resend these
> patches.  Please fix them yourself.

Sorry you feel that way.  Your first patch, although now more or less
cosmetic, would be okay.  The second patch is still wrong.

Thanks,
Richard

Re: [PATCH] netns: avoid directory traversal (was: ip netns: Make sure netns name is sane)

[Phil Sutter]

Hi Matteo,

On Mon, Jul 10, 2017 at 02:08:31PM +0200, Matteo Croce wrote:
> I noticed that your patch still leaves an uncovered scenario, the one where 
> the
> namespace name is "." or "..".
> Calling 'ip netns del ..' will remove /var/run which is a symlink to /run on
> most systems causing some daemons, eg. dbus, to fail.

Oh, indeed. My patch even checks the name for 'ip netns add' only!

> ip netns doesn't validate input, allowing creation and deletion of files
> relatives to /var/run/netns.
> This patch denies creation or deletion of namespaces with names contaning
> "/" or that matches exactly "." or "..".

You might want to have a look at --scissors option to git-am for a more
elegant way of sending a reply with attached patch.

[...]
>  int do_netns(int argc, char **argv)
>  {
>   netns_nsid_socket_init();
> @@ -775,6 +780,11 @@ int do_netns(int argc, char **argv)
>   return netns_list(0, NULL);
>   }
>  
> + if (argc > 1 && invalid_name(argv[1])) {
> + fprintf(stderr, "Invalid netns name \"%s\"\n", argv[1]);
> + exit(-1);
> + }

Maybe worth noting, this assumes argv[1] will be used for the netns name
which doesn't hold for 'ip netns identify' command. It doesn't matter
though, since netns_identify() enforces the parameter to be either
"self" or a decimal number. Yet, in future a new subcommand might be
added which requires this check to be refactored.

Thanks, Phil

[PATCH] ioc3-eth: store pointer to net_device for priviate area

[Jason A. Donenfeld]

Computing the alignment manually for going from priv to pub is probably
not such a good idea, and in general the assumption that going from priv
to pub is possible trivially could change, so rather than relying on
that, we change things to just store a pointer to pub. This was sugested
by DaveM in [1].

[1] http://www.spinics.net/lists/netdev/msg443992.html

Signed-off-by: Jason A. Donenfeld 
---
Ralf - I don't have the platform to test this out, so you might want to
briefly put it through the paces before giving it your sign-off.

 drivers/net/ethernet/sgi/ioc3-eth.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/sgi/ioc3-eth.c 
b/drivers/net/ethernet/sgi/ioc3-eth.c
index b607936e1b3e..9c0488e0f08e 100644
--- a/drivers/net/ethernet/sgi/ioc3-eth.c
+++ b/drivers/net/ethernet/sgi/ioc3-eth.c
@@ -90,17 +90,13 @@ struct ioc3_private {
spinlock_t ioc3_lock;
struct mii_if_info mii;
 
+   struct net_device *dev;
struct pci_dev *pdev;
 
/* Members used by autonegotiation  */
struct timer_list ioc3_timer;
 };
 
-static inline struct net_device *priv_netdev(struct ioc3_private *dev)
-{
-   return (void *)dev - ((sizeof(struct net_device) + 31) & ~31);
-}
-
 static int ioc3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
 static void ioc3_set_multicast_list(struct net_device *dev);
 static int ioc3_start_xmit(struct sk_buff *skb, struct net_device *dev);
@@ -427,7 +423,7 @@ static void ioc3_get_eaddr_nic(struct ioc3_private *ip)
nic[i] = nic_read_byte(ioc3);
 
for (i = 2; i < 8; i++)
-   priv_netdev(ip)->dev_addr[i - 2] = nic[i];
+   ip->dev->dev_addr[i - 2] = nic[i];
 }
 
 /*
@@ -439,7 +435,7 @@ static void ioc3_get_eaddr(struct ioc3_private *ip)
 {
ioc3_get_eaddr_nic(ip);
 
-   printk("Ethernet address is %pM.\n", priv_netdev(ip)->dev_addr);
+   printk("Ethernet address is %pM.\n", ip->dev->dev_addr);
 }
 
 static void __ioc3_set_mac_address(struct net_device *dev)
@@ -790,13 +786,12 @@ static void ioc3_timer(unsigned long data)
  */
 static int ioc3_mii_init(struct ioc3_private *ip)
 {
-   struct net_device *dev = priv_netdev(ip);
int i, found = 0, res = 0;
int ioc3_phy_workaround = 1;
u16 word;
 
for (i = 0; i < 32; i++) {
-   word = ioc3_mdio_read(dev, i, MII_PHYSID1);
+   word = ioc3_mdio_read(ip->dev, i, MII_PHYSID1);
 
if (word != 0x && word != 0x) {
found = 1;
@@ -1276,6 +1271,7 @@ static int ioc3_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
SET_NETDEV_DEV(dev, >dev);
 
ip = netdev_priv(dev);
+   ip->dev = dev;
 
dev->irq = pdev->irq;
 
-- 
2.13.2

[PATCH] netns: avoid directory traversal (was: ip netns: Make sure netns name is sane)

[Matteo Croce]

Hi Phil,

I noticed that your patch still leaves an uncovered scenario, the one where the
namespace name is "." or "..".
Calling 'ip netns del ..' will remove /var/run which is a symlink to /run on
most systems causing some daemons, eg. dbus, to fail.

ip netns doesn't validate input, allowing creation and deletion of files
relatives to /var/run/netns.
This patch denies creation or deletion of namespaces with names contaning
"/" or that matches exactly "." or "..".
---
 ip/ipnetns.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 0b0378a..4254994 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -766,6 +766,11 @@ static int netns_monitor(int argc, char **argv)
return 0;
 }
 
+static int invalid_name(const char *name)
+{
+   return strchr(name, '/') || !strcmp(name, ".") || !strcmp(name, "..");
+}
+
 int do_netns(int argc, char **argv)
 {
netns_nsid_socket_init();
@@ -775,6 +780,11 @@ int do_netns(int argc, char **argv)
return netns_list(0, NULL);
}
 
+   if (argc > 1 && invalid_name(argv[1])) {
+   fprintf(stderr, "Invalid netns name \"%s\"\n", argv[1]);
+   exit(-1);
+   }
+
if ((matches(*argv, "list") == 0) || (matches(*argv, "show") == 0) ||
(matches(*argv, "lst") == 0)) {
netns_map_init();
-- 
2.9.4

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

[Andrew Lunn]

On Mon, Jul 10, 2017 at 02:35:23PM +0200, Martin Blumenstingl wrote:
> mdio_mux_init parses the child nodes of the MDIO mux. When using
> "mdio-mux-mmioreg" the child nodes are describing the register value
> that is written to switch between the MDIO busses.
> 
> The change which makes the error messages more verbose changed the
> parsing of the "reg" property from a simple of_property_read_u32 call
> to of_mdio_parse_addr. On a Khadas VIM (based on the Meson GXL SoC,
> which uses mdio-mux-mmioreg) this prevents registering the MDIO mux
> (because the "reg" values on the MDIO mux child nodes are 0x2009087f
> and 0xe40908ff) and leads to the following errors:
>   mdio-mux-mmioreg c883455c.eth-phy-mux: 
> /soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff PHY address -469169921 is too 
> large
>   mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child 
> /soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff
>   mdio-mux-mmioreg c883455c.eth-phy-mux: 
> /soc/periphs@c8834000/eth-phy-mux/mdio@2009087f PHY address 537462911 is too 
> large
>   mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child 
> /soc/periphs@c8834000/eth-phy-mux/mdio@2009087f
>   mdio-mux-mmioreg c883455c.eth-phy-mux: Error: No acceptable child buses 
> found
>   mdio-mux-mmioreg c883455c.eth-phy-mux: failed to register mdio-mux bus 
> /soc/periphs@c8834000/eth-phy-mux
> (as a result of that ethernet is not working, because the PHY which is
> connected through the mux' child MDIO bus, which is not being
> registered).
> 
> Fix this by reverting the change from of_mdio_parse_addr to
> of_mdio_parse_addr.

Reviewed-by: Andrew Lunn 

Yes, validating the reg property needs to be done separately in each
user of the generic mdio-mix code. The reg for the gpio mux must be <=
number of gpios, mmioreg must be somewhere within the address space,
bcm-iproc < 1024?

Jon, please feel free to add such code.

Andrew

Re: [GIT] Networking

[Sowmini Varadhan]

On (07/10/17 18:05), Herbert Xu wrote:
> 
> Hmm, I can't see the problem in af_alg_accept.  The struct socket
> comes directly from sys_accept() which creates it using sock_alloc.
> 
> So the only thing I can think of is that the memory returned by
> sock_alloc is not zeroed and therefore the WARN_ON is just reading
> garbage.

Then it is odd that this WARN_ON is not triggered for other sockets
(e.g., for TCP sockets), though it happens easily with AF_ALG. 

But it's not sock_alloc() - that function is returning a properly
zeroed ->sk.

The reason that the WARN_ON is triggered is that af_alg_accept() calls
sock_init_data() which does 

   2636 if (sock) {
:
   2639 sock->sk=   sk;


So we can do one of the following:

1. drop the WARN_ON(), which makes true leaks hard to detect
2. change the WARN_ON() to WARN_ON(parent->sk && parent->sk != sk)

#2 assumes that all the refcount book-keeping is being done
correctly (there is the danger that we end up taking 2 refs on the sk) 

--Sowmini

[PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

[Martin Blumenstingl]

mdio_mux_init parses the child nodes of the MDIO mux. When using
"mdio-mux-mmioreg" the child nodes are describing the register value
that is written to switch between the MDIO busses.

The change which makes the error messages more verbose changed the
parsing of the "reg" property from a simple of_property_read_u32 call
to of_mdio_parse_addr. On a Khadas VIM (based on the Meson GXL SoC,
which uses mdio-mux-mmioreg) this prevents registering the MDIO mux
(because the "reg" values on the MDIO mux child nodes are 0x2009087f
and 0xe40908ff) and leads to the following errors:
  mdio-mux-mmioreg c883455c.eth-phy-mux: 
/soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff PHY address -469169921 is too 
large
  mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child 
/soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff
  mdio-mux-mmioreg c883455c.eth-phy-mux: 
/soc/periphs@c8834000/eth-phy-mux/mdio@2009087f PHY address 537462911 is too 
large
  mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child 
/soc/periphs@c8834000/eth-phy-mux/mdio@2009087f
  mdio-mux-mmioreg c883455c.eth-phy-mux: Error: No acceptable child buses found
  mdio-mux-mmioreg c883455c.eth-phy-mux: failed to register mdio-mux bus 
/soc/periphs@c8834000/eth-phy-mux
(as a result of that ethernet is not working, because the PHY which is
connected through the mux' child MDIO bus, which is not being
registered).

Fix this by reverting the change from of_mdio_parse_addr to
of_mdio_parse_addr.

Fixes: 342fa1964439 ("mdio: mux: make child bus walking more permissive and 
errors more verbose")
Signed-off-by: Martin Blumenstingl 
---
 drivers/net/phy/mdio-mux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index 00755b6a42cf..c608e1dfaf09 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -135,8 +135,8 @@ int mdio_mux_init(struct device *dev,
for_each_available_child_of_node(dev->of_node, child_bus_node) {
int v;
 
-   v = of_mdio_parse_addr(dev, child_bus_node);
-   if (v < 0) {
+   r = of_property_read_u32(child_bus_node, "reg", );
+   if (r) {
dev_err(dev,
"Error: Failed to find reg for child %s\n",
of_node_full_name(child_bus_node));
-- 
2.13.2

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

[Neil Armstrong]

On 07/10/2017 02:35 PM, Martin Blumenstingl wrote:
> mdio_mux_init parses the child nodes of the MDIO mux. When using
> "mdio-mux-mmioreg" the child nodes are describing the register value
> that is written to switch between the MDIO busses.
> 
> The change which makes the error messages more verbose changed the
> parsing of the "reg" property from a simple of_property_read_u32 call
> to of_mdio_parse_addr. On a Khadas VIM (based on the Meson GXL SoC,
> which uses mdio-mux-mmioreg) this prevents registering the MDIO mux
> (because the "reg" values on the MDIO mux child nodes are 0x2009087f
> and 0xe40908ff) and leads to the following errors:
>   mdio-mux-mmioreg c883455c.eth-phy-mux: 
> /soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff PHY address -469169921 is too 
> large
>   mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child 
> /soc/periphs@c8834000/eth-phy-mux/mdio@e40908ff
>   mdio-mux-mmioreg c883455c.eth-phy-mux: 
> /soc/periphs@c8834000/eth-phy-mux/mdio@2009087f PHY address 537462911 is too 
> large
>   mdio-mux-mmioreg c883455c.eth-phy-mux: Error: Failed to find reg for child 
> /soc/periphs@c8834000/eth-phy-mux/mdio@2009087f
>   mdio-mux-mmioreg c883455c.eth-phy-mux: Error: No acceptable child buses 
> found
>   mdio-mux-mmioreg c883455c.eth-phy-mux: failed to register mdio-mux bus 
> /soc/periphs@c8834000/eth-phy-mux
> (as a result of that ethernet is not working, because the PHY which is
> connected through the mux' child MDIO bus, which is not being
> registered).
> 
> Fix this by reverting the change from of_mdio_parse_addr to
> of_mdio_parse_addr.
> 
> Fixes: 342fa1964439 ("mdio: mux: make child bus walking more permissive and 
> errors more verbose")
> Signed-off-by: Martin Blumenstingl 
> ---
>  drivers/net/phy/mdio-mux.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
> index 00755b6a42cf..c608e1dfaf09 100644
> --- a/drivers/net/phy/mdio-mux.c
> +++ b/drivers/net/phy/mdio-mux.c
> @@ -135,8 +135,8 @@ int mdio_mux_init(struct device *dev,
>   for_each_available_child_of_node(dev->of_node, child_bus_node) {
>   int v;
>  
> - v = of_mdio_parse_addr(dev, child_bus_node);
> - if (v < 0) {
> + r = of_property_read_u32(child_bus_node, "reg", );
> + if (r) {
>   dev_err(dev,
>   "Error: Failed to find reg for child %s\n",
>   of_node_full_name(child_bus_node));
> 

I was going to push this, thanks martin !!

Acked-by: Neil Armstrong 

Neil

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

[Arnd Bergmann]

On Sun, Jul 9, 2017 at 9:33 PM, Geert Uytterhoeven  wrote:
> Adding a dummy for set_dma_ops() allows to compile (sub)drivers that
> don't actually use the DMA API, but propagate DMA ops configuration to a
> second driver that may or may not use the DMA API.  Of course the second
> driver does have to depend on HAS_DMA if it uses the DMA API.
>
> An example is commit 5567e989198b5a8d ("fsl/fman: propagate dma_ops").
>
> This allows to revert commit 85688d9adf685572 ("fsl/fman: add dependency
> on HAS_DMA").
>
> Signed-off-by: Geert Uytterhoeven 

I can't think of any correct use case for this new helper. IMO a device
driver should never set the dma_map_ops for any device, and we should
instead for the fman driver correctly.

   Arnd