Re: [RFC PATCH] xfrm: Add option to reset oif in xfrm lookup

I need to do some additional testing next week (taking PTO the next 2 days), but this should fix your problem. Can you confirm? This is better than a sysctl to handle the known use cases, but it does not handle a combination of the 2 known use cases (e.g., throw your use case into a VRF). diff

RE: [PATCH] vmxnet3: Move PCI Id to pci_ids.h

On Fri, Aug 05, 2016 11:23:41AM -0700, Bjorn Helgaas wrote: > On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > > driver. Moved it to the shared location in pci_ids.h and updated the > >

[PATCH net 1/2] bpf: restore behavior of bpf_map_update_elem

The introduction of pre-allocated hash elements inadvertently broke the behavior of bpf hash maps where users expected to call bpf_map_update_elem() without considering that the map can be full. Some programs do: old_value = bpf_map_lookup_elem(map, key); if (old_value) { ... prepare new_value

[PATCH net 2/2] samples/bpf: add bpf_map_update_elem() tests

increase test coverage to check previously missing 'update when full' Signed-off-by: Alexei Starovoitov --- samples/bpf/test_maps.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/samples/bpf/test_maps.c b/samples/bpf/test_maps.c index

[PATCH 1/1] brcmfmac: fix pmksa->bssid usage

The struct cfg80211_pmksa defines its bssid field as: const u8 *bssid; contrary to struct brcmf_pmksa, which uses: u8 bssid[ETH_ALEN]; Therefore in brcmf_cfg80211_del_pmksa(), >bssid takes the address of this field (of type u8**), not the one of its content (which would be u8*).

Re: [PATCH 1/1] RDS: add __printf format attribute to error reporting functions

On 8/5/2016 1:11 PM, Nicolas Iooss wrote: This is helpful to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- OK. Acked-by: Santosh Shilimkar

[PATCH 1/1] RDS: add __printf format attribute to error reporting functions

This is helpful to detect at compile-time errors related to format strings. Signed-off-by: Nicolas Iooss --- net/rds/ib.h | 1 + net/rds/rds.h | 1 + 2 files changed, 2 insertions(+) diff --git a/net/rds/ib.h b/net/rds/ib.h index 046f7508c06b..45ac8e8e58f4 100644

Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver

Rob Herring wrote: Sounds like 2 different h/w. The compatible property should distinguish this. So I changed it to this: - compatible : Should be "qcom,fsm9900-emac" or "qcom,qdf2432-emac", depending on the version of the internal PHY. "qcom,fsm9900-emac" is for v1, and

Re: [PATCH] vmxnet3: Move PCI Id to pci_ids.h

On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > driver. Moved it to the shared location in pci_ids.h and updated the > driver version. > > Suggested-by: Leon Romanovsky > Signed-off-by: Adit

[PATCH] vmxnet3: Move PCI Id to pci_ids.h

The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA driver. Moved it to the shared location in pci_ids.h and updated the driver version. Suggested-by: Leon Romanovsky Signed-off-by: Adit Ranadive --- drivers/net/vmxnet3/vmxnet3_int.h | 7

Re: [PATCH 1/1] VSOCK: remove more space available check filling TX vq

On 08/05/2016 07:34 PM, ggar...@abra.uab.cat wrote: From: Gerard Garcia Remove unnecessary use of enable/disable callback notifications and the incorrect more space available check. The virtio_transport_tx_work handles when the TX virtqueue has more buffers available.

[PATCH 1/1] VSOCK: remove more space available check filling TX vq

From: Gerard Garcia Remove unnecessary use of enable/disable callback notifications and the incorrect more space available check. The virtio_transport_tx_work handles when the TX virtqueue has more buffers available. Signed-off-by: Gerard Garcia ---

Re: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

On Fri, Aug 5, 2016 at 8:33 AM, David Laight wrote: > From: Alexander Duyck >> Sent: 05 August 2016 16:15 > ... >> > >> > interesting idea. Like dma_map 1GB region and then allocate >> > pages from it only? but the rest of the kernel won't be able >> > to use them? so

RE: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

From: Alexander Duyck > Sent: 05 August 2016 16:15 ... > > > > interesting idea. Like dma_map 1GB region and then allocate > > pages from it only? but the rest of the kernel won't be able > > to use them? so only some smaller region then? or it will be > > a boot time flag to reserve this

Re: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

On Thu, Aug 4, 2016 at 8:55 PM, Alexei Starovoitov wrote: > On Thu, Aug 04, 2016 at 05:30:56PM -0700, Alexander Duyck wrote: >> On Thu, Aug 4, 2016 at 9:19 AM, Jesper Dangaard Brouer >> wrote: >> > >> > On Wed, 3 Aug 2016 10:45:13 -0700 Alexei

Re: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue

On Thu, Aug 4, 2016 at 5:17 PM, Daniel Borkmann wrote: > On 08/05/2016 12:54 AM, Andi Kleen wrote: >>> >>> +1, I tried to bring this up here [1] in the last spin. I think only very >>> few changes would be needed, f.e. on eBPF side to add a queue setting >>> helper function

Re: [PATCH 3/3] net: ethernet: ti: cpsw: split common driver data and private net data

On 05.08.16 15:14, Grygorii Strashko wrote: On 08/05/2016 12:14 AM, Ivan Khoronzhuk wrote: Simplify driver by splitting common driver data and net dev private data. In case of dual_emac mode 2 networks devices are created, each of them contains its own private data. But 2 net devices share a

RE: [RFC V2 PATCH 17/25] net/netpolicy: introduce netpolicy_pick_queue

> > On Thu, Aug 4, 2016 at 12:36 PM, wrote: > > From: Kan Liang > > > > To achieve better network performance, the key step is to distribute > > the packets to dedicated queues according to policy and system run > > time status. > > > > This patch

RE: [RFC V2 PATCH 00/25] Kernel NET policy

> > > 5. Why disable IRQ balance? > > A: Disabling IRQ balance is a common way (recommend way for some > devices) to > >tune network performance. > > I appreciate that network tuning is hard, most people get it wrong, and > nobody agrees on the right answer. > > So rather than

RE: [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

From: Arvind Yadav > Sent: 04 August 2016 17:53 > IS_ERR_VALUE() assumes that parameter is an unsigned long. > It can not be used to check if 'unsigned int' is passed insted. > Which tends to reflect an error. > In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8. > IS_ERR_VALUE(x) is

pull-request: mac80211 2016-08-05

Hi Dave, Here's a first set of fixes for the current cycle. See the tag message for more information. I'll probably have a follow-up fix for the real problem in mac80211 that caused the crash later, but for now we have this patch and it makes sense and fixes the crash, even if the behaviour

Re: Microsemi VSC 8531/41 PHY Driver

Hello, I added all review comments and re-sending for review. >From a5017f5878a92d2acec86a6a29b1498c457cb73a Mon Sep 17 00:00:00 2001 From: Nagaraju Lakkaraju Date: Wed, 3 Aug 2016 18:28:24 +0530 Subject: [PATCH v2] net: phy: Add drivers for Microsemi PHYs

Re: [PATCH 3/3] net: ethernet: ti: cpsw: split common driver data and private net data

On 08/05/2016 12:14 AM, Ivan Khoronzhuk wrote: > Simplify driver by splitting common driver data and net dev > private data. In case of dual_emac mode 2 networks devices > are created, each of them contains its own private data. > But 2 net devices share a bunch of h/w resources, that shouldn't >

Re: Buggy rhashtable walking

On 08/05/2016 03:50 AM, Johannes Berg wrote: On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote: On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: Hm. Would you rather allocate a separate head entry for the hashtable, or chain the entries? My plan is to build support for

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

On 8/5/2016 2:38 PM, Julia Lawall wrote: Use of_property_read_bool to check for the existence of a property. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S2,S1; @@ - if (of_get_property(e1,e2,NULL)) + if

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

On Fri, 5 Aug 2016, Sergei Shtylyov wrote: > Hello. > > On 8/5/2016 11:56 AM, Julia Lawall wrote: > > > Use of_property_read_bool to check for the existence of a property. > > > > The semantic patch that makes this change is as follows: > > (http://coccinelle.lip6.fr/) > > > > // > > @@ > >

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

Hello. On 8/5/2016 11:56 AM, Julia Lawall wrote: Use of_property_read_bool to check for the existence of a property. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S2,S1; @@ - if (of_get_property(e1,e2,NULL)) +

[PATCH 08/11 v2] net/fsl: use of_property_read_bool

Use of_property_read_bool to check for the existence of a property. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2,x; @@ - if (of_get_property(e1,e2,NULL)) - x = true; - else - x = false; +

RE: [RFC 3/4] security/checmate: Add Checmate sample

Sorry have to resend from normal mail client due to gmail stupid interface. I am not able to find plain text button anywhere anymore... >On Fri, 5 Aug 2016 at 13:49 Elena Reshetova >wrote: >The Checmate sample installs a policy barring new AF_INET connections >to

Re: [RFC V2 PATCH 04/25] net/netpolicy: get CPU information

Hello. On 8/4/2016 10:36 PM, kan.li...@intel.com wrote: From: Kan Liang Net policy also needs to know CPU information. Currently, online CPU number is enough. s/number/count/. Or "the number of online CPUs". Signed-off-by: Kan Liang ---

Re: Buggy rhashtable walking

On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote: > On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: > > > > Hm. Would you rather allocate a separate head entry for the > > hashtable, > > or chain the entries? > > My plan is to build support for this directly into rhashtable. >

Re: Buggy rhashtable walking

On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: > > Hm. Would you rather allocate a separate head entry for the hashtable, > or chain the entries? My plan is to build support for this directly into rhashtable. So I'm adding a struct rhlist_head that would be used in place of

[v5.2] ucc_slow: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

IS_ERR_VALUE() assumes that parameter is an unsigned long. It can not be used to check if 'unsigned int' is passed insted. Which tends to reflect an error. In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8. IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095). IS_ERR_VALUE() of 'unsigned

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

On Fri, 2016-08-05 at 12:08 +0200, Julia Lawall wrote: >  > Can I do the same for: > > if (of_property_read_bool(np, "phy-clk-valid")) >     pdata->check_phy_clk_valid = 1; > else >     pdata->check_phy_clk_valid = 0; > > The type is not bool, but: > >

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

On Fri, 5 Aug 2016, Johannes Berg wrote: > On Fri, 2016-08-05 at 12:08 +0200, Julia Lawall wrote: > >  > > Can I do the same for: > > > > if (of_property_read_bool(np, "phy-clk-valid")) > >     pdata->check_phy_clk_valid = 1; > > else > >    

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

On Fri, 5 Aug 2016, Johannes Berg wrote: > > > - if (of_get_property(pdev->dev.of_node, > > - "little-endian", NULL)) > > + if (of_property_read_bool(pdev->dev.of_node, "little- > > endian")) > >   priv->is_little_endian = true; > >   else > >  

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

On Fri, 5 Aug 2016, Johannes Berg wrote: > > > - if (of_get_property(pdev->dev.of_node, > > - "little-endian", NULL)) > > + if (of_property_read_bool(pdev->dev.of_node, "little- > > endian")) > >   priv->is_little_endian = true; > >   else > >  

Re: [PATCH 08/11] net/fsl: use of_property_read_bool

> - if (of_get_property(pdev->dev.of_node, > - "little-endian", NULL)) > + if (of_property_read_bool(pdev->dev.of_node, "little- > endian")) >   priv->is_little_endian = true; >   else >   priv->is_little_endian = false; > Perhaps,

[PATCH 00/11] use of_property_read_bool

Use of_property_read_bool to check for the existence of a property. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S2,S1; @@ - if (of_get_property(e1,e2,NULL)) + if (of_property_read_bool(e1,e2)) S1

[PATCH 08/11] net/fsl: use of_property_read_bool

Use of_property_read_bool to check for the existence of a property. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @@ expression e1,e2; statement S2,S1; @@ - if (of_get_property(e1,e2,NULL)) + if (of_property_read_bool(e1,e2)) S1

Re: [PATCH] VSOCK: fix vhost virtio_vsock_pkt use-after-free

On Thu, Aug 04, 2016 at 07:34:43PM +0300, Michael S. Tsirkin wrote: > On Thu, Aug 04, 2016 at 02:52:53PM +0100, Stefan Hajnoczi wrote: > > Stash the packet length in a local variable before handing over > > ownership of the packet to virtio_transport_recv_pkt() or > > virtio_transport_free_pkt().

Re: [v5.1] ucc_fast: Fix to avoid IS_ERR_VALUE abuses and dead code on 64bit systems.

On Friday 05 August 2016 02:01 AM, Arnd Bergmann wrote: On Thursday, August 4, 2016 10:22:43 PM CEST Arvind Yadav wrote: index df8ea79..ada9070 100644 --- a/include/soc/fsl/qe/ucc_fast.h +++ b/include/soc/fsl/qe/ucc_fast.h @@ -165,10 +165,12 @@ struct ucc_fast_private { int

Re: [RFC 2/4] bpf, security: Add Checmate

Sure. Why are preempt_disable and rcu_read_lock used here? is there a great benefit of dong this? On Fri, Aug 5, 2016 at 3:05 PM, Sargun Dhillon wrote: > On Thu, Aug 04, 2016 at 05:34:32PM +0800, zhuyj wrote: >> Sure. >> Is it better to add >> #ifndef CONFIG_PREEMPT_RCU ? >>

Re: order-0 vs order-N driver allocation. Was: [PATCH v10 07/12] net/mlx4_en: add page recycle to prepare rx ring for tx support

On Thu, 2016-08-04 at 18:19 +0200, Jesper Dangaard Brouer wrote: > I actually agree, that we should switch to order-0 allocations. > > *BUT* this will cause performance regressions on platforms with > expensive DMA operations (as they no longer amortize the cost of > mapping a larger page). We

Re: [RFC 2/4] bpf, security: Add Checmate

On Thu, Aug 04, 2016 at 05:34:32PM +0800, zhuyj wrote: > Sure. > Is it better to add > #ifndef CONFIG_PREEMPT_RCU ? > > On Thu, Aug 4, 2016 at 4:28 PM, Eric Dumazet wrote: > > Please do not top post > > > > On Thu, 2016-08-04 at 16:08 +0800, zhuyj wrote: > >> +void

RE: [RFC PATCH v3 1/2] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

Hi Rob, Thanks for the review... > > +XILINX GMIITORGMII Converter Driver Device Tree Bindings > > + > > + > > +The Gigabit Media Independent Interface (GMII) to Reduced Gigabit > > +Media Independent Interface (RGMII) core

[PATCH v2] net: phy: micrel: Add specific suspend

Disable all interrupts when suspend, they will be enabled when resume. Otherwise, the suspend/resume process will be blocked occasionally. Signed-off-by: Wenyou Yang Acked-by: Nicolas Ferre --- Changes in v2: - Use fairly generic

RE: [RFC PATCH v3 2/2] net: phy: Add gmiitorgmii converter support

Hi zhuyj, Thanks for the review... > > + switch (phydev->speed) { > + case SPEED_1000: > + val |= BMCR_SPEED1000; > + case SPEED_100: > + val |= BMCR_SPEED100; > + } > > Are there only 2 kinds of speed? Converter supports 3 different

Re: [RFC PATCH v3 2/2] net: phy: Add gmiitorgmii converter support

+ switch (phydev->speed) { + case SPEED_1000: + val |= BMCR_SPEED1000; + case SPEED_100: + val |= BMCR_SPEED100; + } Are there only 2 kinds of speed? On Thu, Aug 4, 2016 at 8:13 PM, Kedareswara rao Appana wrote: >

RE: [PATCH v1] net: phy: micrel: Add specific suspend

Hi Florian, > -Original Message- > From: Florian Fainelli [mailto:f.faine...@gmail.com] > Sent: 2016年8月4日 11:33 > To: Wenyou Yang > Cc: netdev@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; Alexandre Belloni

Re: Buggy rhashtable walking

> So I'm going to fix this by consolidating identical objects into > a single rhashtable entry which also lets us get rid of the > insecure_elasticity setting. Hm. Would you rather allocate a separate head entry for the hashtable, or chain the entries? (Luckily) the colliding key case