Re: [PATCH 15/15] ethernet: ti: davinci_emac: add missing of_node_put after calling of_parse_phandle

[Mugunthan V N]

On Wednesday 27 July 2016 07:50 AM, Peter Chen wrote:
> of_node_put needs to be called when the device node which is got
> from of_parse_phandle has finished using.
> 
> Signed-off-by: Peter Chen 
> ---
>  drivers/net/ethernet/ti/davinci_emac.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c 
> b/drivers/net/ethernet/ti/davinci_emac.c
> index c6c5465..d8cb9d0 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -1571,6 +1571,7 @@ static int emac_dev_open(struct net_device *ndev)
>   if (priv->phy_node) {
>   phydev = of_phy_connect(ndev, priv->phy_node,
>   _adjust_link, 0, 0);
> + of_node_put(priv->phy_node);
>   if (!phydev) {
>   dev_err(emac_dev, "could not connect to phy %s\n",
>   priv->phy_node->full_name);
> 

phy_node is accessed in case of of_phy_connect() returns error, so it
has to be moved after the dev_err log

Regards
Mugunthan V N

RE: [PATCH net] be2net: perform temperature query in adapter regardless of its interface state

[Sathya Perla]

> -Original Message-
> From: Guilherme G. Piccoli [mailto:gpicc...@linux.vnet.ibm.com]
>
> The be2net driver performs fw temperature queries on be_worker()
routine, which is executed each second for
> each be_adapter. There is a frequency threshold to avoid fw query to
happens at each call to be_worker();
> instead, currently a fw query occurs once in 64 runs of the procedure.
>
> Nevertheless, this fw temperature query is invoked only for adapters
which interface is up, so we can see I/O
> errors on read of hwmon counters from userspace (from tools like
lm-sensors) in case we have adapters'
> functions which interface is down.
>
> This patch moves the fw query code to be invoked even if interface is
down.
> No functional changes were introduced.
>
> Signed-off-by: Guilherme G. Piccoli 

Acked-by: Sathya Perla 

Re: [PATCH] xfrm: use printk instead of WARN for bad policy reporting

[Herbert Xu]

On Wed, Jul 20, 2016 at 01:53:12PM +0200, Vegard Nossum wrote:
> On 07/20/2016 10:32 AM, Vegard Nossum wrote:
> >AFAICT this message is just printed whenever input validation fails.
> >This is a normal failure and we shouldn't be dumping the stack over it.
> >
> >Looks like it was originally a printk that was maybe incorrectly
> >upgraded to a WARN:
> >
> >commit 62db5cfd70b1ef53aa21f144a806fe3b78c84fab
> >Author: stephen hemminger 
> >Date:   Wed May 12 06:37:06 2010 +
> >
> > xfrm: add severity to printk
> 
> Just FYI I'm also running into the
> 
> // reset the timers here?
> WARN(1, "Don't know what to do with soft policy expire\n");
> 
> in xfrm_add_pol_expire() from the same commit, but that looks
> potentially somewhat more serious (or at least it looks like we might
> want to do some sort of cleaning up), so I won't touch it for now.

It certainly shouldn't be a WARN, it probably shouldn't print
anything either.

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

linux-next: manual merge of the net-next tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi

between commit:

  cafc4cd0c8b8 ("arm64: dts: apm: Use lowercase consistently for hex constants")

from the arm-soc tree and commit:

  8e694cd2762c ("dtb: xgene: Add MDIO node")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 21028b145d91,2e1e5daa1dc7..
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@@ -628,9 -636,9 +636,9 @@@
sgenet0: ethernet@1f61 {
compatible = "apm,xgene2-sgenet";
status = "disabled";
-   reg = <0x0 0x1f61 0x0 0x1>,
+   reg = <0x0 0x1f61 0x0 0xd100>,
 -<0x0 0x1f60 0x0 0Xd100>,
 -<0x0 0x2000 0x0 0X2>;
 +<0x0 0x1f60 0x0 0xd100>,
 +<0x0 0x2000 0x0 0x2>;
interrupts = <0 96 4>,
 <0 97 4>;
dma-coherent;

[PATCH 14/15] ethernet: stmicro: stmmac: stmmac_platform: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index f7dfc0a..8d88782 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -113,8 +113,10 @@ static struct stmmac_axi *stmmac_axi_setup(struct 
platform_device *pdev)
return NULL;
 
axi = kzalloc(sizeof(*axi), GFP_KERNEL);
-   if (!axi)
+   if (!axi) {
+   of_node_put(np);
return ERR_PTR(-ENOMEM);
+   }
 
axi->axi_lpi_en = of_property_read_bool(np, "snps,lpi_en");
axi->axi_xit_frm = of_property_read_bool(np, "snps,xit_frm");
@@ -127,6 +129,7 @@ static struct stmmac_axi *stmmac_axi_setup(struct 
platform_device *pdev)
of_property_read_u32(np, "snps,wr_osr_lmt", >axi_wr_osr_lmt);
of_property_read_u32(np, "snps,rd_osr_lmt", >axi_rd_osr_lmt);
of_property_read_u32_array(np, "snps,blen", axi->axi_blen, AXI_BLEN);
+   of_node_put(np);
 
return axi;
 }
-- 
1.9.1

[PATCH 15/15] ethernet: ti: davinci_emac: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/ti/davinci_emac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ti/davinci_emac.c 
b/drivers/net/ethernet/ti/davinci_emac.c
index c6c5465..d8cb9d0 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1571,6 +1571,7 @@ static int emac_dev_open(struct net_device *ndev)
if (priv->phy_node) {
phydev = of_phy_connect(ndev, priv->phy_node,
_adjust_link, 0, 0);
+   of_node_put(priv->phy_node);
if (!phydev) {
dev_err(emac_dev, "could not connect to phy %s\n",
priv->phy_node->full_name);
-- 
1.9.1

[PATCH 12/15] ethernet: renesas: sh_eth: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/renesas/sh_eth.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 7bd910c..799d58d 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1780,6 +1780,7 @@ static int sh_eth_phy_init(struct net_device *ndev)
sh_eth_adjust_link, 0,
mdp->phy_interface);
 
+   of_node_put(pn);
if (!phydev)
phydev = ERR_PTR(-ENOENT);
} else {
-- 
1.9.1

[PATCH 09/15] ethernet: marvell: mvpp2: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/marvell/mvpp2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 0b04717..a86f22b 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5531,6 +5531,7 @@ static int mvpp2_phy_connect(struct mvpp2_port *port)
 
phy_dev = of_phy_connect(port->dev, port->phy_node, mvpp2_link_event, 0,
 port->phy_interface);
+   of_node_put(port->phy_node);
if (!phy_dev) {
netdev_err(port->dev, "cannot connect to phy\n");
return -ENODEV;
@@ -6234,6 +6235,7 @@ err_free_stats:
 err_free_irq:
irq_dispose_mapping(port->irq);
 err_free_netdev:
+   of_node_put(phy_node);
free_netdev(dev);
return err;
 }
-- 
1.9.1

[PATCH 13/15] ethernet: stmicro: stmmac: dwmac-socfpga: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 36 --
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index edd20c3..bec6963 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -135,7 +135,9 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac 
*dwmac, struct device *
 
np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
if (np_splitter) {
-   if (of_address_to_resource(np_splitter, 0, _splitter)) {
+   ret = of_address_to_resource(np_splitter, 0, _splitter);
+   of_node_put(np_splitter);
+   if (ret) {
dev_info(dev, "Missing emac splitter address\n");
return -EINVAL;
}
@@ -159,14 +161,17 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac 
*dwmac, struct device *
dev_err(dev,
"%s: ERROR: missing emac splitter 
address\n",
__func__);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_node_put;
}
 
dwmac->splitter_base =
devm_ioremap_resource(dev, _splitter);
 
-   if (IS_ERR(dwmac->splitter_base))
-   return PTR_ERR(dwmac->splitter_base);
+   if (IS_ERR(dwmac->splitter_base)) {
+   ret = PTR_ERR(dwmac->splitter_base);
+   goto err_node_put;
+   }
}
 
index = of_property_match_string(np_sgmii_adapter, "reg-names",
@@ -178,14 +183,17 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac 
*dwmac, struct device *
dev_err(dev,
"%s: ERROR: failed mapping adapter\n",
__func__);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_node_put;
}
 
dwmac->pcs.sgmii_adapter_base =
devm_ioremap_resource(dev, _sgmii_adapter);
 
-   if (IS_ERR(dwmac->pcs.sgmii_adapter_base))
-   return PTR_ERR(dwmac->pcs.sgmii_adapter_base);
+   if (IS_ERR(dwmac->pcs.sgmii_adapter_base)) {
+   ret = PTR_ERR(dwmac->pcs.sgmii_adapter_base);
+   goto err_node_put;
+   }
}
 
index = of_property_match_string(np_sgmii_adapter, "reg-names",
@@ -197,22 +205,30 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac 
*dwmac, struct device *
dev_err(dev,
"%s: ERROR: failed mapping tse control 
port\n",
__func__);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_node_put;
}
 
dwmac->pcs.tse_pcs_base =
devm_ioremap_resource(dev, _tse_pcs);
 
-   if (IS_ERR(dwmac->pcs.tse_pcs_base))
-   return PTR_ERR(dwmac->pcs.tse_pcs_base);
+   if (IS_ERR(dwmac->pcs.tse_pcs_base)) {
+   ret = PTR_ERR(dwmac->pcs.tse_pcs_base);
+   goto err_node_put;
+   }
}
}
dwmac->reg_offset = reg_offset;
dwmac->reg_shift = reg_shift;
dwmac->sys_mgr_base_addr = sys_mgr_base_addr;
dwmac->dev = dev;
+   of_node_put(np_sgmii_adapter);
 
return 0;
+
+err_node_put:
+   of_node_put(np_sgmii_adapter);
+   return ret;
 }
 
 static int socfpga_dwmac_set_phy_mode(struct socfpga_dwmac *dwmac)
-- 
1.9.1

[PATCH 08/15] ethernet: marvell: mvneta: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index f92018b..16aca9d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4113,6 +4113,7 @@ static int mvneta_probe(struct platform_device *pdev)
if (bm_node && bm_node->data) {
pp->bm_priv = bm_node->data;
err = mvneta_bm_port_init(pdev, pp);
+   of_node_put(bm_node);
if (err < 0) {
dev_info(>dev, "use SW buffer management\n");
pp->bm_priv = NULL;
-- 
1.9.1

[PATCH 11/15] ethernet: renesas: ravb_main: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/renesas/ravb_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 8377d02..1e1cc0f 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1005,6 +1005,7 @@ static int ravb_phy_init(struct net_device *ndev)
}
phydev = of_phy_connect(ndev, pn, ravb_adjust_link, 0,
priv->phy_interface);
+   of_node_put(pn);
if (!phydev) {
netdev_err(ndev, "failed to connect PHY\n");
return -ENOENT;
-- 
1.9.1

[PATCH 06/15] ethernet: hisilicon: hns: hns_dsaf_mac: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index 3fb87e2..18d72ea 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -786,6 +786,7 @@ static int  hns_mac_get_info(struct hns_mac_cb *mac_cb)
np = of_parse_phandle(mac_cb->dev->of_node, "phy-handle",
  mac_cb->mac_id);
mac_cb->phy_dev = of_phy_find_device(np);
+   of_node_put(np);
if (mac_cb->phy_dev) {
/* refcount is held by of_phy_find_device()
 * if the phy_dev is found
@@ -804,6 +805,7 @@ static int  hns_mac_get_info(struct hns_mac_cb *mac_cb)
np = of_parse_phandle(to_of_node(mac_cb->fw_port),
  "phy-handle", 0);
mac_cb->phy_dev = of_phy_find_device(np);
+   of_node_put(np);
if (mac_cb->phy_dev) {
/* refcount is held by of_phy_find_device()
 * if the phy_dev is found
@@ -813,9 +815,10 @@ static int  hns_mac_get_info(struct hns_mac_cb *mac_cb)
mac_cb->mac_id, np->name);
}
 
-   syscon = syscon_node_to_regmap(
-   of_parse_phandle(to_of_node(mac_cb->fw_port),
-"serdes-syscon", 0));
+   np = of_parse_phandle(to_of_node(mac_cb->fw_port),
+   "serdes-syscon", 0);
+   syscon = syscon_node_to_regmap(np);
+   of_node_put(np);
if (IS_ERR_OR_NULL(syscon)) {
dev_err(mac_cb->dev, "serdes-syscon is needed!\n");
return -EINVAL;
-- 
1.9.1

[PATCH 07/15] ethernet: hisilicon: hns: hns_dsaf_main: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 2ef4277..afb5daa 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -51,7 +51,7 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
const char *mode_str;
struct regmap *syscon;
struct resource *res;
-   struct device_node *np = dsaf_dev->dev->of_node;
+   struct device_node *np = dsaf_dev->dev->of_node, *np_temp;
struct platform_device *pdev = to_platform_device(dsaf_dev->dev);
 
if (dev_of_node(dsaf_dev->dev)) {
@@ -102,8 +102,9 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
dsaf_dev->dsaf_tc_mode = HRD_DSAF_4TC_MODE;
 
if (dev_of_node(dsaf_dev->dev)) {
-   syscon = syscon_node_to_regmap(
-   of_parse_phandle(np, "subctrl-syscon", 0));
+   np_temp = of_parse_phandle(np, "subctrl-syscon", 0);
+   syscon = syscon_node_to_regmap(np_temp);
+   of_node_put(np_temp);
if (IS_ERR_OR_NULL(syscon)) {
res = platform_get_resource(pdev, IORESOURCE_MEM,
res_idx++);
-- 
1.9.1

[PATCH 10/15] ethernet: marvell: pxa168_eth: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/marvell/pxa168_eth.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c 
b/drivers/net/ethernet/marvell/pxa168_eth.c
index aeeb2e7..5d5000c 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -1506,6 +1506,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
}
of_property_read_u32(np, "reg", >phy_addr);
pep->phy_intf = of_get_phy_mode(pdev->dev.of_node);
+   of_node_put(np);
}
 
/* Hardware supports only 3 ports */
-- 
1.9.1

[PATCH 04/15] ethernet: aurora: nb8800: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/aurora/nb8800.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/aurora/nb8800.c 
b/drivers/net/ethernet/aurora/nb8800.c
index 0d4ea92..d15d96b 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -1006,6 +1006,7 @@ static int nb8800_stop(struct net_device *dev)
 
netif_stop_queue(dev);
napi_disable(>napi);
+   of_node_put(priv->phy_node);
 
nb8800_dma_stop(dev);
nb8800_mac_rx(dev, false);
@@ -1504,6 +1505,7 @@ static int nb8800_probe(struct platform_device *pdev)
 err_free_dma:
nb8800_dma_free(dev);
 err_free_bus:
+   of_node_put(priv->phy_node);
mdiobus_unregister(bus);
 err_disable_clk:
clk_disable_unprepare(priv->clk);
-- 
1.9.1

[PATCH 05/15] ethernet: cavium: octeon: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c 
b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
index e8bc15b..5eb9d8c 100644
--- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
@@ -960,6 +960,7 @@ static int octeon_mgmt_init_phy(struct net_device *netdev)
phydev = of_phy_connect(netdev, p->phy_np,
octeon_mgmt_adjust_link, 0,
PHY_INTERFACE_MODE_MII);
+   of_node_put(p->phy_np);
 
if (!phydev)
return -ENODEV;
-- 
1.9.1

[PATCH 03/15] ethernet: arc: emac_main: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/arc/emac_main.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/arc/emac_main.c 
b/drivers/net/ethernet/arc/emac_main.c
index 586beda..0e6331c 100644
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -749,14 +749,16 @@ int arc_emac_probe(struct net_device *ndev, int interface)
err = of_address_to_resource(dev->of_node, 0, _regs);
if (err) {
dev_err(dev, "failed to retrieve registers base from device 
tree\n");
-   return -ENODEV;
+   err = -ENODEV;
+   goto out_put_node;
}
 
/* Get IRQ from device tree */
irq = irq_of_parse_and_map(dev->of_node, 0);
if (!irq) {
dev_err(dev, "failed to retrieve  value from device 
tree\n");
-   return -ENODEV;
+   err = -ENODEV;
+   goto out_put_node;
}
 
ndev->netdev_ops = _emac_netdev_ops;
@@ -778,7 +780,7 @@ int arc_emac_probe(struct net_device *ndev, int interface)
err = clk_prepare_enable(priv->clk);
if (err) {
dev_err(dev, "failed to enable clock\n");
-   return err;
+   goto out_put_node;
}
 
clock_frequency = clk_get_rate(priv->clk);
@@ -787,7 +789,8 @@ int arc_emac_probe(struct net_device *ndev, int interface)
if (of_property_read_u32(dev->of_node, "clock-frequency",
 _frequency)) {
dev_err(dev, "failed to retrieve  from 
device tree\n");
-   return -EINVAL;
+   err = -EINVAL;
+   goto out_put_node;
}
}
 
@@ -877,6 +880,9 @@ out_mdio:
 out_clken:
if (priv->clk)
clk_disable_unprepare(priv->clk);
+out_put_node:
+   of_node_put(phy_node);
+
return err;
 }
 EXPORT_SYMBOL_GPL(arc_emac_probe);
-- 
1.9.1

[PATCH 01/15] ethernet: altera: add missing of_node_put

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle (or of_node_get) has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/altera/altera_tse_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/altera/altera_tse_main.c 
b/drivers/net/ethernet/altera/altera_tse_main.c
index 49025e9..bda31f3 100644
--- a/drivers/net/ethernet/altera/altera_tse_main.c
+++ b/drivers/net/ethernet/altera/altera_tse_main.c
@@ -815,6 +815,7 @@ static int init_phy(struct net_device *dev)
phydev = of_phy_connect(dev, phynode,
_tse_adjust_link, 0, priv->phy_iface);
}
+   of_node_put(phynode);
 
if (!phydev) {
netdev_err(dev, "Could not find the PHY\n");
-- 
1.9.1

[PATCH 02/15] ethernet: apm: xgene: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c 
b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index 2f5638f..fb23408 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -758,6 +758,7 @@ static int xgene_enet_phy_connect(struct net_device *ndev)
 
phy_dev = of_phy_connect(ndev, phy_np, _enet_adjust_link,
 0, pdata->phy_mode);
+   of_node_put(phy_np);
if (!phy_dev) {
netdev_err(ndev, "Could not connect to PHY\n");
return -ENODEV;
-- 
1.9.1

[PATCH 00/15] ethernet: add missing of_node_put after calling of_parse_phandle

[Peter Chen]

Hi David,

This patch set fixes missing of_node_put issue at ethernet driver.
of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Thanks.

Peter Chen (15):
  ethernet: altera: add missing of_node_put
  ethernet: apm: xgene: add missing of_node_put after calling
of_parse_phandle
  ethernet: arc: emac_main: add missing of_node_put after calling
of_parse_phandle
  ethernet: aurora: nb8800: add missing of_node_put after calling
of_parse_phandle
  ethernet: cavium: octeon: add missing of_node_put after calling
of_parse_phandle
  ethernet: hisilicon: hns: hns_dsaf_mac: add missing of_node_put after
calling of_parse_phandle
  ethernet: hisilicon: hns: hns_dsaf_main: add missing of_node_put after
calling of_parse_phandle
  ethernet: marvell: mvneta: add missing of_node_put after calling
of_parse_phandle
  ethernet: marvell: mvpp2: add missing of_node_put after calling
of_parse_phandle
  ethernet: marvell: pxa168_eth: add missing of_node_put after calling
of_parse_phandle
  ethernet: renesas: ravb_main: add missing of_node_put after calling
of_parse_phandle
  ethernet: renesas: sh_eth: add missing of_node_put after calling
of_parse_phandle
  ethernet: stmicro: stmmac: dwmac-socfpga: add missing of_node_put
after calling of_parse_phandle
  ethernet: stmicro: stmmac: stmmac_platform: add missing of_node_put
after calling of_parse_phandle
  ethernet: ti: davinci_emac: add missing of_node_put after calling
of_parse_phandle

 drivers/net/ethernet/altera/altera_tse_main.c  |  1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c |  1 +
 drivers/net/ethernet/arc/emac_main.c   | 14 ++---
 drivers/net/ethernet/aurora/nb8800.c   |  2 ++
 drivers/net/ethernet/cavium/octeon/octeon_mgmt.c   |  1 +
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c  |  9 --
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c |  7 +++--
 drivers/net/ethernet/marvell/mvneta.c  |  1 +
 drivers/net/ethernet/marvell/mvpp2.c   |  2 ++
 drivers/net/ethernet/marvell/pxa168_eth.c  |  1 +
 drivers/net/ethernet/renesas/ravb_main.c   |  1 +
 drivers/net/ethernet/renesas/sh_eth.c  |  1 +
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 36 --
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  5 ++-
 drivers/net/ethernet/ti/davinci_emac.c |  1 +
 15 files changed, 62 insertions(+), 21 deletions(-)

-- 
1.9.1

Re: [PATCH] qed: Add and use specific logging functions to reduce object size

[Joe Perches]

On Tue, 2016-07-26 at 14:25 -0700, Joe Perches wrote:
> Current DP_ macros generate a lot of code.
> Using functions with vsprintf extension %pV helps reduce that size.

Yuval, I used the same KERN_ output types, but it
is unusual that DP_INFO outputs at KERN_NOTICE.

Was that a copy/paste defect or should it be emitted at
KERN_INFO and DP_VERBOSE be emitted at KERN_DEBUG?

> define DP_INFO(cdev, fmt, ...)  \
> - do {  \
> - if (unlikely((cdev)->dp_level <= QED_LEVEL_INFO)) {   \
> - pr_notice("[%s:%d(%s)]" fmt,  \
> -   __func__, __LINE__,     \
> -   DP_NAME(cdev) ? DP_NAME(cdev) : "", \
> -   ## __VA_ARGS__);    \
> - }     \
> - } while (0)
[]
> -#define DP_VERBOSE(cdev, module, fmt, ...)   \
> - do {\
> - if (unlikely(((cdev)->dp_level <= QED_LEVEL_VERBOSE) && \
> -  ((cdev)->dp_module & module))) {   \
> - pr_notice("[%s:%d(%s)]" fmt,\
> -   __func__, __LINE__,   \
> -   DP_NAME(cdev) ? DP_NAME(cdev) : "",   \
> -   ## __VA_ARGS__);  \
> - }   \
> - } while (0)

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Christian Lamparter wrote:
> Thanks, I gave the program a try with my WNDA3100 and a WN821N v2 devices.
> I did not see any corruptions in any of the tests though. Can you tell me
> something about your wireless network too? I would like to know what router
> and firmware are you using? Also important: what's your wireless 
> configuration?

The router/access-point is a Comcast-issued Technicolor cable modem, model
TC8305C. The only thing I can find on it that looks like it might identify
a firmware version is this:

System Software Version

eMTA & DOCSIS Software Version: 01.E6.01.22.25
Packet Cable: 2.0

I assume Comcast pushes firmware updates whenever they feel like it.

There is possibly another clue. I get this message from the kernel sometimes:

ieee80211 phy0: invalid plcp cck rate (0).

I had this message appearing long before the data corruption bug started.
It never correlated with any actual problems, so I turned down the priority
level of the message to get it off the console, and forgot about it. I
was unable to discover what a "plcp" or "cck" is so the message means
nothing to me.

> (WPA?, CCMP or TKIP? HT40, HT20 or Legacy rates? ...)
> 
> Probably the quickest and easiest way to get that information is by running
> the following commands as root, when you are connected to your wifi network
> and post the results:
> # iw dev wlan0 link
> # iw dev wlan0 scan dump

Connected to cc:03:fa:bf:e9:ea (on wlan0)
SSID: HOME-E9EA
freq: 2462
RX: 20726719 bytes (106483 packets)
TX: 5902478 bytes (44707 packets)
signal: -43 dBm
tx bitrate: 54.0 MBit/s

bss flags:  short-slot-time
dtim period:1
beacon int: 100

BSS cc:03:fa:bf:e9:ea(on wlan0) -- associated
TSF: 236407205748 usec (2d, 17:40:07)
freq: 2462
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -33.00 dBm
last seen: 634452 ms ago
Information elements from Probe Response frame:
SSID: HOME-E9EA
Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0* 36.0 54.0 
DS Parameter set: channel 11
ERP: 
ERP D4.0: 
RSN: * Version: 1
 * Group cipher: TKIP
 * Pairwise ciphers: CCMP TKIP
 * Authentication suites: PSK
 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
Extended supported rates: 6.0* 9.0 12.0* 48.0 
HT capabilities:
Capabilities: 0x18bd
RX LDPC
HT20
SM Power Save disabled
RX Greenfield
RX HT20 SGI
TX STBC
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-23
HT TX MCS rate indexes are undefined
HT operation:
 * primary channel: 11
 * secondary channel offset: no secondary
 * STA channel width: 20 MHz
 * RIFS: 1
 * HT protection: nonmember
 * non-GF present: 1
 * OBSS non-GF present: 1
 * dual beacon: 0
 * dual CTS protection: 0
 * STBC beacon: 0
 * L-SIG TXOP Prot: 0
 * PCO active: 0
 * PCO phase: 0
WPS: * Version: 1.0
 * Wi-Fi Protected Setup State: 2 (Configured)
 * Response Type: 3 (AP)
 * UUID: 6d1b1911-14a9-391c-cdee-89850a5aa1ef
 * Manufacturer: Technicolor
 * Model: Technicolor
 * Model Number: 123456
 * Serial Number: 001
 * Primary Device Type: 6-0050f204-1
 * Device name: TechnicolorAP
 * Config methods: Display
 * RF Bands: 0x1
 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20
WPA: * Version: 1
 * Group cipher: TKIP
 * Pairwise ciphers: CCMP TKIP
 * Authentication suites: PSK
 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
WMM: * Parameter version 1
 * u-APSD
 * BE: CW 15-1023, AIFSN 3
 * BK: CW 15-1023, AIFSN 7
 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

-- 
Alan Curry

Re: question: tg3 driver/nics and inconsistent RX ring count

[Michael Chan]

On Tue, Jul 26, 2016 at 1:32 PM, Michal Soltys  wrote:
> On 2016-07-26 22:06, Alexander Duyck wrote:
>> On Tue, Jul 26, 2016 at 12:52 PM, Michal Soltys  wrote:
>>> Hi,
>>>
>>> I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520
>>> servers - and all of them have certain peculiarity: they claim to have
>>> up to 4 TX and RX rings (and this can be set/verified just fine through
>>> ethtool -l/-L, with driver defaulting to 4 rings), indirection table
>>> (ethtool -x) looks fine as well:
>>>
>>> RX flow hash indirection table for eth1b with 3 RX ring(s):
>>> 0:  0 1 2 3 0 1 2 3
>>> 8:  0 1 2 3 0 1 2 3
>>> ..
>>>
>>> But this "3 RX ring(s)" is actually a real limit if I try to adjust
>>> anything, for example all those commands would fail:
>>>
>>> ethtool -X eth1b equal 4
>>> ethtool -X eth1b weight 1 1 1 1
>>>
>>> But would work fine for 3 and less rings. This was quickly tested with
>>> different kernel/ethtool combinations, from old 3.16 to 4.6.y with same
>>> exact results. Nothing fancier (-N/-U) is supported either.
>>>
>>> Any hints/comments about the cause of this and/or possible workarounds ?
>>
>> Well a quick look at the driver code makes it seem the problem lies in
>> tg3_get_rxnfc.  I suspect the bug is related to the following lines:
>>
>> /* The first interrupt vector only
>>  * handles link interrupts.
>>  */
>> info->data -= 1;
>>
>> I'm not sure what the number of interrupt vectors has to do with the
>> number of rings.  Perhaps someone more familiar with the driver can
>> point out why you would subtract 1 from tp->rxq_cnt to get the number
>> of queues when it seems like it should be tp->rxq_cnt.
>>
>> Hope that helps.
>>
>> - Alex
>>
>
> Ah thanks, seems to be the case then. Quick git blame shows it's been
> since the very introduction of RSS indirection configurability (ca.
> 2011) in this driver, 90415477bf1356f72acc34063ff52441fc10a754.
>
> I've CCed the author, maybe he will be able to shed some light.

Matt is no longer working here.  The driver should support up to 5
MSIX vectors and 4 RSS rings.  It looks like the code to subtract 1 in
tg3_get_rxnfc() is not correct.  Siva will look further into this.
Thanks for reporting the issue.

Re: [PATCH v2] net/mlx5_core/health: Remove deprecated create_singlethread_workqueue

[David Miller]

From: Bhaktipriya Shridhar 
Date: Tue, 26 Jul 2016 22:38:24 +0530

> The workqueue health->wq was used as per device private health thread.
> This was done to perform delayed work.
> 
> The workqueue has a single workitem(>work) and
> hence doesn't require ordering. It is involved in handling the health of
> the device and is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> Work item has been flushed in mlx5_health_cleanup() to ensure that
> there are no pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Applied.

Re: [PATCH net] l2tp: Correctly return -EBADF from pppol2tp_getname.

[David Miller]

From: Phil Turnbull 
Date: Tue, 26 Jul 2016 15:14:35 -0400

> If 'tunnel' is NULL we should return -EBADF but the 'end_put_sess' path
> unconditionally sets 'error' back to zero. Rework the error path so it
> more closely matches pppol2tp_sendmsg.
> 
> Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp 
> parts")
> Signed-off-by: Phil Turnbull 

Applied.

Re: [PATCH net-next v2] net: ipmr/ip6mr: update lastuse on entry change

[David Miller]

From: Nikolay Aleksandrov 
Date: Tue, 26 Jul 2016 18:54:52 +0200

> Currently lastuse is updated on entry creation and cache hit, but it should
> also be updated on entry change. Since both on add and update the ttl array
> is updated we can simply update the lastuse in ipmr_update_thresholds.
> 
> Signed-off-by: Nikolay Aleksandrov 

Applied.

Re: [PATCH v2] net: davinci_cpdma: remove excessive dump of register values to kernel log

[Ivan Khoronzhuk]

On 26.07.16 17:26, Grygorii Strashko wrote:

+ CC: Ivan

On 07/26/2016 05:09 PM, Grygorii Strashko wrote:

On 07/26/2016 03:57 AM, David Miller wrote:

From: Uwe Kleine-König 
Date: Mon, 25 Jul 2016 11:54:45 +0200


Such a big dump of register values is hardly useful on a production
system.

Another downside of the now removed functions is that calling
emac_dump_regs resulted in at least 87 calls to dev_info while holding a
spinlock and having irqs off which is a big source of latency.

Signed-off-by: Uwe Kleine-König 


Applied.



:( To be honest I was really enjoyed using cpdma_ctlr_dump()
for debug purposed during the past few weeks in cpsw where I've added
calls to this func manually. And I even thinking about adding debug_fs
entry for the same :(

Pretty fast merge :(

At least, partly, for channel stats, for cpsw, I can use ethtool.
But ctrl_dump()... the function would be better to leave, redundant calls can be
removed from davinci_emac.









--
Regards,
Ivan Khoronzhuk

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[Grant Grundler]

On Tue, Jul 26, 2016 at 2:14 PM, Robert Foss  wrote:
...
> Thanks for the feedback (for this patch and the other ones)!
> I'm preparing a v2 and will submit it withing a day or two.

Excellent! very welcome and thanks again for picking this up.

...
>> FTR, current  drivers/net/usb/ax88179_178a.c uses "in_pm" as well.
>
> Ah! Would you like that to be noted in the commit message?

No - I generally do not muck with commit messages that I didn't write.
It's part of the "finger print" of a patch (so one can trace origin
across distro's and kernel versions).

My comment was intended for reviewers and could be included in the
"comments after the commit message". (ie below the "---" marker in the
patch email).

...
>> BTW, I have two additional changes for AX88772x support sitting in my
>> "needs more work" queue (for quite a while already):
>>https://chromium-review.googlesource.com/#/c/229620/
>>"asix: autoneg will set WRITE_MEDIUM reg"
>>
>>https://chromium-review.googlesource.com/#/c/231162/
>>"net: asix: see 802.3 spec for phy reset"
>>
>> I would certainly approve if _anyone_ picked these up, tested them,
>> and then submitted them to netdev.
>
> Unfortunately I am without appropriate hardware at the moment.

That's a risky thing to point out for two reasons:

1) I can send you more HW than you could possibly ever use. :)

2) Reviewers of this patch series are already wondering how you
verified the AX88772x patches work on current kernel.org (or
netdev-next) branches.

Please email me with your shipping address (OFFLIST!) and I'll try to
send you some Asix HW to test with.  I'm located in "Silicon Valley"
(USA) and can easily ship in the US. Other countries is a bit harder
and in some cases not possible.

cheers,
grant

Re: [PATCH net-next V2 0/2] Mellanox 100G mlx5 minimum inline header mode

[David Miller]

From: Hadar Hen Zion 
Date: Tue, 26 Jul 2016 13:30:46 +0300

> In the default case eth_get_headlen() won't be called, it will happen
> only if PF administrator changes the mode from default to L4.
> 
> In L4 mode, we need to copy all the packet headers including L4, do
> you know of a better/cheaper way for doing that?

You can just look straight at the ethernet header in this context.

eth_get_headlen() is expensive and has a complete header parser.  It
is meant to be used when none of the SKB context state has been setup
yet (early RX processing before SKB is allocated, for example).

Re: [PATCH] macsec: ensure rx_sa is set when validation is disabled

[David Miller]

From: Beniamino Galvani 
Date: Tue, 26 Jul 2016 12:24:53 +0200

> macsec_decrypt() is not called when validation is disabled and so
> macsec_skb_cb(skb)->rx_sa is not set; but it is used later in
> macsec_post_decrypt(), ensure that it's always initialized.
> 
> Signed-off-by: Beniamino Galvani 

Applied and queued up for -stable.

Re: [PATCH net-next v2 0/5] tipc: netlink updates for neighbour monitor

[David Miller]

From: Parthasarathy Bhuvaragan 
Date: Tue, 26 Jul 2016 08:47:17 +0200

> This series contains the updates to configure and read the attributes for
> neighbour monitor.
> 
> v2: rebase on top of net-next

Series applied, thanks.

Re: [PATCH v2] net: neigh: disallow transition to NUD_STALE if lladdr is unchanged in neigh_update()

[David Miller]

From: Chunhui He 
Date: Tue, 26 Jul 2016 06:16:52 +

> NUD_STALE is used when the caller(e.g. arp_process()) can't guarantee
> neighbour reachability. If the entry was NUD_VALID and lladdr is unchanged,
> the entry state should not be changed.
> 
> Currently the code puts an extra "NUD_CONNECTED" condition. So if old state
> was NUD_DELAY or NUD_PROBE (they are NUD_VALID but not NUD_CONNECTED), the
> state can be changed to NUD_STALE.
> 
> This may cause problem. Because NUD_STALE lladdr doesn't guarantee
> reachability, when we send traffic, the state will be changed to
> NUD_DELAY. In normal case, if we get no confirmation (by dst_confirm()),
> we will change the state to NUD_PROBE and send probe traffic. But now the
> state may be reset to NUD_STALE again(e.g. by broadcast ARP packets),
> so the probe traffic will not be sent. This situation may happen again and
> again, and packets will be sent to an non-reachable lladdr forever.
> 
> The fix is to remove the "NUD_CONNECTED" condition. After that the
> "NEIGH_UPDATE_F_WEAK_OVERRIDE" condition (used by IPv6) in that branch will
> be redundant, so remove it.
> 
> This change may increase probe traffic, but it's essential since NUD_STALE
> lladdr is unreliable. To ensure correctness, we prefer to resolve lladdr,
> when we can't get confirmation, even while remote packets try to set
> NUD_STALE state.
> 
> Signed-off-by: Chunhui He 

Applied, thanks.

[PATCH] qed: Add and use specific logging functions to reduce object size

[Joe Perches]

Current DP_ macros generate a lot of code.
Using functions with vsprintf extension %pV helps reduce that size.

$ size drivers/net/ethernet/qlogic/built-in.o* (x86-64)
   textdata bss dec hex filename
 165161   28470   32812  226443   3748b 
drivers/net/ethernet/qlogic/built-in.o.defconfig.new
 190473   28470   32812  251755   3d76b 
drivers/net/ethernet/qlogic/built-in.o.defconfig.old
1215984  257822   39712 1513518  17182e 
drivers/net/ethernet/qlogic/built-in.o.allyesconfig.new
1262402  284334   39712 1586448  183510 
drivers/net/ethernet/qlogic/built-in.o.allyesconfig.old

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/qlogic/qed/Makefile   |  2 +-
 drivers/net/ethernet/qlogic/qed/qed_util.c | 82 ++
 include/linux/qed/qed_if.h | 60 +-
 3 files changed, 106 insertions(+), 38 deletions(-)
 create mode 100644 drivers/net/ethernet/qlogic/qed/qed_util.c

diff --git a/drivers/net/ethernet/qlogic/qed/Makefile 
b/drivers/net/ethernet/qlogic/qed/Makefile
index d1f157e..9d7e55f 100644
--- a/drivers/net/ethernet/qlogic/qed/Makefile
+++ b/drivers/net/ethernet/qlogic/qed/Makefile
@@ -2,5 +2,5 @@ obj-$(CONFIG_QED) := qed.o
 
 qed-y := qed_cxt.o qed_dev.o qed_hw.o qed_init_fw_funcs.o qed_init_ops.o \
 qed_int.o qed_main.o qed_mcp.o qed_sp_commands.o qed_spq.o qed_l2.o \
-qed_selftest.o qed_dcbx.o
+qed_selftest.o qed_dcbx.o qed_util.o
 qed-$(CONFIG_QED_SRIOV) += qed_sriov.o qed_vf.o
diff --git a/drivers/net/ethernet/qlogic/qed/qed_util.c 
b/drivers/net/ethernet/qlogic/qed/qed_util.c
new file mode 100644
index 000..2795e63
--- /dev/null
+++ b/drivers/net/ethernet/qlogic/qed/qed_util.c
@@ -0,0 +1,82 @@
+#include 
+#include 
+
+#include "qed.h"
+
+void qed_err(const char *name, int line, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   pr_err("[%ps:%d(%s)] %pV",
+  __builtin_return_address(0), line, name ? name : "",
+   );
+
+   va_end(args);
+}
+
+void qed_notice(u32 level, const char *name, int line, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   if (likely(level > QED_LEVEL_NOTICE))
+   return;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   pr_notice("[%ps:%d(%s)] %pV",
+ __builtin_return_address(0), line, name ? name : "",
+ );
+
+   va_end(args);
+}
+
+void qed_info(u32 level, const char *name, int line, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   if (likely(level > QED_LEVEL_INFO))
+   return;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   pr_notice("[%ps:%d(%s)] %pV",
+ __builtin_return_address(0), line, name ? name : "",
+ );
+
+   va_end(args);
+}
+
+void qed_verbose(u32 level, const char *name, int line,
+const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   if (likely(level > QED_LEVEL_VERBOSE))
+   return;
+
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   pr_notice("[%ps:%d(%s)] %pV",
+ __builtin_return_address(0), line, name ? name : "",
+ );
+
+   va_end(args);
+}
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index b1e3c57..fa3d8c0 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -539,44 +539,30 @@ struct qed_common_ops {
 #define GET_FIELD(value, name) \
(((value) >> (name ## _SHIFT)) & name ## _MASK)
 
-/* Debug print definitions */
-#define DP_ERR(cdev, fmt, ...)  \
-   pr_err("[%s:%d(%s)]" fmt,\
-  __func__, __LINE__,   \
-  DP_NAME(cdev) ? DP_NAME(cdev) : "",   \
-  ## __VA_ARGS__)   \
-
-#define DP_NOTICE(cdev, fmt, ...)\
-   do {  \
-   if (unlikely((cdev)->dp_level <= QED_LEVEL_NOTICE)) { \
-   pr_notice("[%s:%d(%s)]" fmt,  \
- __func__, __LINE__, \
- DP_NAME(cdev) ? DP_NAME(cdev) : "", \
- ## __VA_ARGS__);\
- \
-   } \
-   } while (0)
-
-#define DP_INFO(cdev, fmt, ...)  \
-   do {  

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[Robert Foss]

From: Grant Grundler 


For the record, I believe I am not the author of these patches.

I believe the original author is
Signed-off-by: Freddy Xin 

as recorded in the following code reviews (and testing) that I was
responsible for:

https://chromium-review.googlesource.com/#/q/owner:%22Grant+Grundler%22+status:merged+asix+in_pm

And I would certainly be happy to see this code go upstream and
expected ASIX would submit this change upstream.

Thanks for the feedback (for this patch and the other ones)!
I'm preparing a v2 and will submit it withing a day or two.




In order to R/W registers in suspend/resume functions, in_pm flags are
added to some functions to determine whether the nopm version of usb
functions is called.


FTR, current  drivers/net/usb/ax88179_178a.c uses "in_pm" as well.

Ah! Would you like that to be noted in the commit message?



Save BMCR and ANAR PHY registers in suspend function and restore them
in resume function.

Reset HW in resume function to ensure the PHY works correctly.

Signed-off-by: Grant Grundler 


BTW, I have two additional changes for AX88772x support sitting in my
"needs more work" queue (for quite a while already):
   https://chromium-review.googlesource.com/#/c/229620/
   "asix: autoneg will set WRITE_MEDIUM reg"

   https://chromium-review.googlesource.com/#/c/231162/
   "net: asix: see 802.3 spec for phy reset"

I would certainly approve if _anyone_ picked these up, tested them,
and then submitted them to netdev.

Unfortunately I am without appropriate hardware at the moment.



cheers,
grant


---
 drivers/net/usb/asix.h |  40 +++--
 drivers/net/usb/asix_common.c  | 180 +++-
 drivers/net/usb/asix_devices.c | 373 -
 drivers/net/usb/ax88172a.c |  29 ++--
 4 files changed, 472 insertions(+), 150 deletions(-)

diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index a2d3ea6..d109242 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -46,6 +46,7 @@
 #define AX_CMD_SET_SW_MII  0x06
 #define AX_CMD_READ_MII_REG0x07
 #define AX_CMD_WRITE_MII_REG   0x08
+#define AX_CMD_STATMNGSTS_REG  0x09
 #define AX_CMD_SET_HW_MII  0x0a
 #define AX_CMD_READ_EEPROM 0x0b
 #define AX_CMD_WRITE_EEPROM0x0c
@@ -71,6 +72,17 @@
 #define AX_CMD_SW_RESET0x20
 #define AX_CMD_SW_PHY_STATUS   0x21
 #define AX_CMD_SW_PHY_SELECT   0x22
+#define AX_QCTCTRL 0x2A
+
+#define AX_CHIPCODE_MASK   0x70
+#define AX_AX88772_CHIPCODE0x00
+#define AX_AX88772A_CHIPCODE   0x10
+#define AX_AX88772B_CHIPCODE   0x20
+#define AX_HOST_EN 0x01
+
+#define AX_PHYSEL_PSEL 0x01
+#define AX_PHYSEL_SSMII0
+#define AX_PHYSEL_SSEN 0x10

 #define AX_PHY_SELECT_MASK (BIT(3) | BIT(2))
 #define AX_PHY_SELECT_INTERNAL 0
@@ -173,6 +185,10 @@ struct asix_rx_fixup_info {
 };

 struct asix_common_private {
+   void (*resume)(struct usbnet *dev);
+   void (*suspend)(struct usbnet *dev);
+   u16 presvd_phy_advertise;
+   u16 presvd_phy_bmcr;
struct asix_rx_fixup_info rx_fixup_info;
 };

@@ -182,10 +198,10 @@ extern const struct driver_info ax88172a_info;
 #define FLAG_EEPROM_MAC(1UL << 0)  /* init device MAC from 
eeprom */

 int asix_read_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
- u16 size, void *data);
+ u16 size, void *data, int in_pm);

 int asix_write_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
-  u16 size, void *data);
+  u16 size, void *data, int in_pm);

 void asix_write_cmd_async(struct usbnet *dev, u8 cmd, u16 value,
  u16 index, u16 size, void *data);
@@ -197,27 +213,31 @@ int asix_rx_fixup_common(struct usbnet *dev, struct 
sk_buff *skb);
 struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
  gfp_t flags);

-int asix_set_sw_mii(struct usbnet *dev);
-int asix_set_hw_mii(struct usbnet *dev);
+int asix_set_sw_mii(struct usbnet *dev, int in_pm);
+int asix_set_hw_mii(struct usbnet *dev, int in_pm);

 int asix_read_phy_addr(struct usbnet *dev, int internal);
 int asix_get_phy_addr(struct usbnet *dev);

-int asix_sw_reset(struct usbnet *dev, u8 flags);
+int asix_sw_reset(struct usbnet *dev, u8 flags, int in_pm);

-u16 asix_read_rx_ctl(struct usbnet *dev);
-int asix_write_rx_ctl(struct usbnet *dev, u16 mode);
+u16 asix_read_rx_ctl(struct usbnet *dev, int in_pm);
+int asix_write_rx_ctl(struct usbnet *dev, u16 mode, int in_pm);

-u16 asix_read_medium_status(struct usbnet *dev);
-int asix_write_medium_mode(struct usbnet *dev, u16 mode);
+u16 asix_read_medium_status(struct usbnet *dev, int in_pm);
+int 

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[ivan.khoronzhuk]

On 26.07.16 19:02, Grygorii Strashko wrote:

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:



On 22.07.16 16:58, Grygorii Strashko wrote:

Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
 cpsw_remove()
 - cpdma_ctlr_destroy()
   - spin_lock_irqsave(>lock, flags)
   - cpdma_ctlr_stop()
 - spin_lock_irqsave(>lock, flags); <- deadlock
   - cpdma_chan_destroy()
 - spin_lock_irqsave(>lock, flags); <- deadlock

The issue has not been observed before because CPDMA channels have
been destroyed manually by CPSW until commit d941ebe88a41 ("net:
ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index a68652a..89242e9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -436,7 +436,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 if (!ctlr)
 return -EINVAL;

-spin_lock_irqsave(>lock, flags);

Should ctlr->state be checked under lock?
Seems like here should be used unlocked static versions of
cpdma_ctlr_stop() and cpdma_chan_destroy() instead.


As per my understanding it's not expected the ctlr->state will be changed at 
this
moment as all net devices has been unregistered already.

Seems yes, the race can be only in case of incorrect usage, stop while destroy,
destroy while start...etc..all they are mostly unreal use-cases, you are right,
but such check w/o lock always under eyes control, that always makes you think
that smth wrong.






 if (ctlr->state != CPDMA_STATE_IDLE)


May be I can move above check in cpdma_ctlr_stop() instead.
What do you think?

Yes, it be more clear.
I was thinking about lock deletion also, as under this destroy function the
ctlr destroys it's resources one by one, ok, the channels are destroyed under 
lock,
but pool (it's good that it's destroyed after channels). I see that it 
should never
happen, but ctrl is external structure, who knows as it can be used while 
destroying.
That was my paranoiac point, so don't pay a lot attention to it. In case of 
normal usage,
as it's currently is and should be, the lock can be removed.




 cpdma_ctlr_stop(ctlr);

@@ -444,7 +443,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 cpdma_chan_destroy(ctlr->channels[i]);

 cpdma_desc_pool_destroy(ctlr->pool);
-spin_unlock_irqrestore(>lock, flags);
 return ret;
 }
 EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Kees Cook]

On Tue, Jul 26, 2016 at 10:29 AM, Michael Kerrisk (man-pages)
 wrote:
> On 26 July 2016 at 18:52, Kees Cook  wrote:
>> On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman
>>  wrote:
>>> "Michael Kerrisk (man-pages)"  writes:
>>>
 Hello Eric,

 I realized I had a question after the last mail.

 On 07/21/2016 06:39 PM, Eric W. Biederman wrote:
>
> This patchset addresses two use cases:
> - Implement a sane upper bound on the number of namespaces.
> - Provide a way for sandboxes to limit the attack surface from
>   namespaces.

 Can you say more about the second point? What exactly is the
 problem that is being addressed, and how does the patch series
 address it? (It would be good to have those details in the
 revised commit message...)
>>>
>>> At some point it was reported that seccomp was not sufficient to disable
>>> namespace creation.  I need to go back and look at that claim to see
>>> which set of circumstances that was referring to.  Seccomp doesn't stack
>>> so I can see why it is an issue.
>>
>> seccomp does stack. The trouble usually comes from a perception that
>> seccomp overhead is not trivial, so setting a system-wide policy is a
>> bit of a large hammer for such a limitiation. Also, at the time,
>> seccomp could be bypasses with ptrace, but this (as of v4.8) is no
>> longer true.
>
> Sounds like someone needs to send me a patch for the seccomp.2 man page?

It's on my TODO list, no worries. :) I'm waiting for it to land in
Linus's tree first. It's only been in -next so far.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH net] be2net: perform temperature query in adapter regardless of its interface state

[Guilherme G. Piccoli]

The be2net driver performs fw temperature queries on be_worker() routine,
which is executed each second for each be_adapter. There is a frequency
threshold to avoid fw query to happens at each call to be_worker();
instead, currently a fw query occurs once in 64 runs of the procedure.

Nevertheless, this fw temperature query is invoked only for adapters which
interface is up, so we can see I/O errors on read of hwmon counters from
userspace (from tools like lm-sensors) in case we have adapters' functions
which interface is down.

This patch moves the fw query code to be invoked even if interface is down.
No functional changes were introduced.

Signed-off-by: Guilherme G. Piccoli 
---
 drivers/net/ethernet/emulex/benet/be_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/emulex/benet/be_main.c 
b/drivers/net/ethernet/emulex/benet/be_main.c
index ed98ef1..706fdfa 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4996,6 +4996,10 @@ static void be_worker(struct work_struct *work)
struct be_rx_obj *rxo;
int i;
 
+   if (be_physfn(adapter) &&
+   MODULO(adapter->work_counter, adapter->be_get_temp_freq) == 0)
+   be_cmd_get_die_temperature(adapter);
+
/* when interrupts are not yet enabled, just reap any pending
 * mcc completions
 */
@@ -5014,10 +5018,6 @@ static void be_worker(struct work_struct *work)
be_cmd_get_stats(adapter, >stats_cmd);
}
 
-   if (be_physfn(adapter) &&
-   MODULO(adapter->work_counter, adapter->be_get_temp_freq) == 0)
-   be_cmd_get_die_temperature(adapter);
-
for_all_rx_queues(adapter, rxo, i) {
/* Replenish RX-queues starved due to memory
 * allocation failures.
-- 
2.1.0

Re: question: tg3 driver/nics and inconsistent RX ring count

[Michal Soltys]

On 2016-07-26 22:06, Alexander Duyck wrote:
> On Tue, Jul 26, 2016 at 12:52 PM, Michal Soltys  wrote:
>> Hi,
>>
>> I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520
>> servers - and all of them have certain peculiarity: they claim to have
>> up to 4 TX and RX rings (and this can be set/verified just fine through
>> ethtool -l/-L, with driver defaulting to 4 rings), indirection table
>> (ethtool -x) looks fine as well:
>>
>> RX flow hash indirection table for eth1b with 3 RX ring(s):
>> 0:  0 1 2 3 0 1 2 3
>> 8:  0 1 2 3 0 1 2 3
>> ..
>>
>> But this "3 RX ring(s)" is actually a real limit if I try to adjust
>> anything, for example all those commands would fail:
>>
>> ethtool -X eth1b equal 4
>> ethtool -X eth1b weight 1 1 1 1
>>
>> But would work fine for 3 and less rings. This was quickly tested with
>> different kernel/ethtool combinations, from old 3.16 to 4.6.y with same
>> exact results. Nothing fancier (-N/-U) is supported either.
>>
>> Any hints/comments about the cause of this and/or possible workarounds ?
> 
> Well a quick look at the driver code makes it seem the problem lies in
> tg3_get_rxnfc.  I suspect the bug is related to the following lines:
> 
> /* The first interrupt vector only
>  * handles link interrupts.
>  */
> info->data -= 1;
> 
> I'm not sure what the number of interrupt vectors has to do with the
> number of rings.  Perhaps someone more familiar with the driver can
> point out why you would subtract 1 from tp->rxq_cnt to get the number
> of queues when it seems like it should be tp->rxq_cnt.
> 
> Hope that helps.
> 
> - Alex
> 

Ah thanks, seems to be the case then. Quick git blame shows it's been
since the very introduction of RSS indirection configurability (ca.
2011) in this driver, 90415477bf1356f72acc34063ff52441fc10a754.

I've CCed the author, maybe he will be able to shed some light.

Re: [PATCH net-next 1/2] be2net: set temperature value for all adapter's functions

[Guilherme G. Piccoli]

On 07/26/2016 05:26 AM, Sathya Perla wrote:

-Original Message-
From: Guilherme G. Piccoli [mailto:gpicc...@linux.vnet.ibm.com]

On 07/25/2016 07:48 AM, Sathya Perla wrote:

-Original Message-
From: Guilherme G. Piccoli [mailto:gpicc...@linux.vnet.ibm.com]

Temperature values on be2net driver are made available to userspace
via

hwmon abstraction, so tools like lm-

sensors can present them to the user.
The driver provides hwmon structures for each adapter's function.
Nevertheless, the temperature information come from fw queries
performed

by

be_worker() with some frequency, and this procedure is called with a

single function as argument; this means

that the temperature value is updated only in the specific function
that

was passed to be_worker().


This can lead to incongruency in reported temperature by a function,
or

in a worse scenario, some functions

might be unable to provide temperature info to userspace, if they

weren't fed with this information from fw in

be_worker() run.


Hi, I'm wondering if you are OK with the temperature value being 128s
old
(2/2 patch), then why is it a problem
if two different functions report a temperature value that is queried
a few seconds apart?
Also, you'll not have a scenario where the FW cmd succeeds for one
function and fails for other functions.
It's a common FW for the entire adapter.



This patch changes the way temperature is set in be2net driver. At

anytime the fw query is performed, it will set

the temperature value for all functions of the adapter, instead of
only

setting the temperature of the function

passed to be_worker().

If the possible inconsistency across functions is indeed a problem,
then a simpler solution would be to issue the FW cmd synchronously
when the sysfs attr is read, i.e., in
be_hwmon_show_temp() routine itself.



Hi Sathya, thanks very much for your quick reply. I agree with you that an
1 or 2 sec inconsistency wouldn't
harm, but the main problem we're seeing is that be_worker() is being
called with a single function as a parameter
- in our case, the last function is being passed as argument to
be_worker() multiple times in a row, and then we
have its temperature updated but the other functions' temperature set as
invalid.


Hi Guilherme, this doesn't sound right to me and is not expected. The
be_worker() routine must execute for *each* function every second.
Can you pls share the driver/fw version and any debug logs (with prints) you
may have and also lspci output.


Hi Sathya, indeed...this is _not right_...from my side heheh
Unfortunately I made a mistake in my analysis and ended up 
over-engineering a "solution" to an issue which root cause wasn't clear 
to me! I want to thank you for your relevant questions and the 
information you provided, which helped a lot to figure exactly what's 
going on.


Our issue is seen because some adapter's functions (3 out of 4) have 
their interface down, and the fw temperature queries are performed only 
for functions which interface is up. The following conditional avoids fw 
query to occur whenever adapter's interface is down:


  if (!netif_running(adapter->netdev))
[be_main.c:5002, kernel v4.7]

It seems harmless to change the fw query location to perform temperature 
read for all functions regardless the state of its interface - this will 
solve our issue. I wrote a simple patch (to "net", and not "net-next" 
anymore) to improve this driver's behavior.

I'll send it right after this message, please let me know what you think.

Again, thanks very much for your attention and sorry for my confusion.
Cheers,


Guilherme




Regarding the temperature update run on be_hwmon_show_temp(), it was an
idea too, but I was afraid in delay
this output too much - imagine some userspace tool reads hwmon attributes
for all functions almost at "same
time", supposing the fw command can't run in parallel, the "last" read
would need to wait 4 fw commands to
complete before showing it's output.


I don't see any issue even if the sensors program queries each function one
after another. These calls would only be
a few milli-seconds apart.


Besides, in a worse scenario, some "not-friendly" tool might issue lots of
reads to hwmon per second then
issuing lots of fw commands, which does not seem a good idea. Of course
this last case we can avoid by
implementing a counter or timer on be_hwmon_show_temp() to allow maximum
number of fw cmds in a time
frame.

Yes, this is not an issue. If the hwmon read is issued with-in a few seconds
of the previous read then you can just return the old temperature value.
We are anyway querying this value only once in 64s now.
But, I'd like to root-cause the issue you are seeing above before we "fix"
anything.

thanks,
-Sathya

Re: [PATCH v2 09/10] netns: Add a limit on the number of net namespaces

[Eric W. Biederman]

Andrei Vagin  writes:

> On Thu, Jul 21, 2016 at 9:40 AM, Eric W. Biederman  
> wrote:
>> index 2c2eb1b629b1..a489f192d619 100644
>> --- a/net/core/net_namespace.c
>> +++ b/net/core/net_namespace.c
>> @@ -266,6 +266,16 @@ struct net *get_net_ns_by_id(struct net *net, int id)
>> return peer;
>>  }
>>
>> +static bool inc_net_namespaces(struct user_namespace *ns)
>> +{
>> +   return inc_ucount(ns, UCOUNT_NET_NAMESPACES);
>> +}
>> +
>> +static void dec_net_namespaces(struct user_namespace *ns)
>> +{
>> +   dec_ucount(ns, UCOUNT_NET_NAMESPACES);
>> +}
>> +
>>  /*
>>   * setup_net runs the initializers for the network namespace object.
>>   */
>> @@ -276,6 +286,9 @@ static __net_init int setup_net(struct net *net, struct 
>> user_namespace *user_ns)
>> int error = 0;
>> LIST_HEAD(net_exit_list);
>>
>> +   if (!inc_net_namespaces(user_ns))
>> +   return -ENFILE;
>
> I think you need to move this check after initilizing  net->passive.
> When setup_net returns an error, net_drop_ns is called:
>
Good point.  Ouch!

> void net_drop_ns(void *p)
> {
> struct net *ns = p;
> if (ns && atomic_dec_and_test(>passive))
> net_free(ns);
> }
>
> Actually, I think it would be better to make this check before
> net_alloc().

You are probably right.  I seem to be trying to be entirely too clever
putting that in setup_net so I can cover the initial network namespace.
Which really does not need to be counted.  As clearly I also goofed up
the decrement on error case as well.

Eric

Re: question: tg3 driver/nics and inconsistent RX ring count

[Alexander Duyck]

On Tue, Jul 26, 2016 at 12:52 PM, Michal Soltys  wrote:
> Hi,
>
> I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520
> servers - and all of them have certain peculiarity: they claim to have
> up to 4 TX and RX rings (and this can be set/verified just fine through
> ethtool -l/-L, with driver defaulting to 4 rings), indirection table
> (ethtool -x) looks fine as well:
>
> RX flow hash indirection table for eth1b with 3 RX ring(s):
> 0:  0 1 2 3 0 1 2 3
> 8:  0 1 2 3 0 1 2 3
> ..
>
> But this "3 RX ring(s)" is actually a real limit if I try to adjust
> anything, for example all those commands would fail:
>
> ethtool -X eth1b equal 4
> ethtool -X eth1b weight 1 1 1 1
>
> But would work fine for 3 and less rings. This was quickly tested with
> different kernel/ethtool combinations, from old 3.16 to 4.6.y with same
> exact results. Nothing fancier (-N/-U) is supported either.
>
> Any hints/comments about the cause of this and/or possible workarounds ?

Well a quick look at the driver code makes it seem the problem lies in
tg3_get_rxnfc.  I suspect the bug is related to the following lines:

/* The first interrupt vector only
 * handles link interrupts.
 */
info->data -= 1;

I'm not sure what the number of interrupt vectors has to do with the
number of rings.  Perhaps someone more familiar with the driver can
point out why you would subtract 1 from tp->rxq_cnt to get the number
of queues when it seems like it should be tp->rxq_cnt.

Hope that helps.

- Alex

question: tg3 driver/nics and inconsistent RX ring count

[Michal Soltys]

Hi,

I have a few of BCM5720 and BCM5719 kinds sitting in Dell R320 and R520
servers - and all of them have certain peculiarity: they claim to have
up to 4 TX and RX rings (and this can be set/verified just fine through
ethtool -l/-L, with driver defaulting to 4 rings), indirection table
(ethtool -x) looks fine as well:

RX flow hash indirection table for eth1b with 3 RX ring(s):
0:  0 1 2 3 0 1 2 3
8:  0 1 2 3 0 1 2 3
..

But this "3 RX ring(s)" is actually a real limit if I try to adjust
anything, for example all those commands would fail:

ethtool -X eth1b equal 4
ethtool -X eth1b weight 1 1 1 1

But would work fine for 3 and less rings. This was quickly tested with
different kernel/ethtool combinations, from old 3.16 to 4.6.y with same
exact results. Nothing fancier (-N/-U) is supported either.

Any hints/comments about the cause of this and/or possible workarounds ?

[PATCH net] l2tp: Correctly return -EBADF from pppol2tp_getname.

[Phil Turnbull]

If 'tunnel' is NULL we should return -EBADF but the 'end_put_sess' path
unconditionally sets 'error' back to zero. Rework the error path so it
more closely matches pppol2tp_sendmsg.

Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp 
parts")
Signed-off-by: Phil Turnbull 
---
 net/l2tp/l2tp_ppp.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 652c250b9a3b..d9560aa2dba3 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -866,10 +866,8 @@ static int pppol2tp_getname(struct socket *sock, struct 
sockaddr *uaddr,
 
pls = l2tp_session_priv(session);
tunnel = l2tp_sock_to_tunnel(pls->tunnel_sock);
-   if (tunnel == NULL) {
-   error = -EBADF;
+   if (tunnel == NULL)
goto end_put_sess;
-   }
 
inet = inet_sk(tunnel->sock);
if ((tunnel->version == 2) && (tunnel->sock->sk_family == AF_INET)) {
@@ -947,12 +945,11 @@ static int pppol2tp_getname(struct socket *sock, struct 
sockaddr *uaddr,
}
 
*usockaddr_len = len;
+   error = 0;
 
sock_put(pls->tunnel_sock);
 end_put_sess:
sock_put(sk);
-   error = 0;
-
 end:
return error;
 }
-- 
2.9.0.rc2

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

[Tom Herbert]

On Tue, Jul 26, 2016 at 10:53 AM, John Fastabend
 wrote:
> On 16-07-26 09:08 AM, Tom Herbert wrote:
>> On Tue, Jul 26, 2016 at 6:31 AM, Thomas Monjalon
>>  wrote:
>>> Hi,
>>>
>>> About RX filtering, there is an ongoing effort in DPDK to write an API
>>> which could leverage most of the hardware capabilities of any NICs:
>>> https://rawgit.com/6WIND/rte_flow/master/rte_flow.html
>>> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/43352
>>> I understand that XDP does not target to support every hardware features,
>>> though it may be an interesting approach to check.
>>>
>> Thomas,
>>
>> A major goal of XDP is to leverage and in fact encourage innovation in
>> hardware features. But, we are asking that vendors design the APIs
>> with the community in mind. For instance, if XDP supports crypto
>> offload it should have one API that different companies, we don't want
>> every vendor coming up with their own.
>
> The work in those threads is to create a single API for users of DPDK
> to interact with their hardware. The equivalent interface in Linux
> kernel is ntuple filters from ethtool the effort here is to make a
> usable interface to manage this from an application and also expose
> all the hardware features. Ethtool does a fairly poor job on both
> fronts IMO.
>
> If we evolve the mechanism to run per rx queue xdp programs this
> interface could easily be used to forward packets to specific rx
> queues and run targeted xdp programs.
>
> Integrating this functionality into running XDP programs as ebpf code
> seems a bit challenging to me because there is no software equivalent.
> Once XDP ebpf program is running the pkt has already landed on the rx
> queue. To me the mechanism to bind XDP programs to rx queues and steer
> specific flows (e.g. match a flow label and forward to a queue) needs
> to be part of the runtime environment not part of the main ebpf program
> itself. The runtime environment could use the above linked API. I know
> we debated earlier including this in the ebpf program itself but that
> really doesn't seem feasible to me. Whether the steering is expresses
> as an ebpf program or an API like above seems like a reasonable
> discussion. Perhaps a section could be used to describe the per program
> filter for example which would be different from an API approach used
> in the proposal above or the JIT could translate it into the above
> API for devices without instruction based hardware.
>
I think your convoluting two different mechanisms. If the device has
the capability to different packets and steer them to different
queues, then XDP should be able to make use of that by running
different programs appropriate for each queue. Packet steering is the
domain of HW, for that we have ntuple filtering now but there is no
reason to believe that XDP won't be used for that also. Per queue
program in the host is just configuration, i.e. bind this program to
that queue. Even if the first is not ready, I don't see why the second
is so complex; it should just be a matter of per queue configuration
for which there is already a lot of infrastructure.

> Step 0 should be to show a set of compelling use cases that want to run
> per queue programs then we can talk about the runtime.

Imagine we are able to split VM traffic and non-VM traffic to
different RX queues. The program we will want to run would be very
different in those cases.

Tom

>
>
>>
>>> 2016-07-12 22:32, Jesper Dangaard Brouer via iovisor-dev:
 On Tue, 12 Jul 2016 12:13:01 -0700
 John Fastabend  wrote:
>
> Another use case I have is to make a really high performance AF_PACKET
> interface. So if there was a way to say bind a queue to an AF_PACKET
> ring and run a policy XDP program before hitting the AF_PACKET
> descriptor bit that would be really interesting because it would solve
> some of my need for poll mode drivers in userspace.
>>>
>>> Have you started this work?
>>> Do you have an idea of how RX would perform through XDP + AF_PACKET + DPDK?
>>>
>> I don't understand why the AF_PACKET with DPDK. They should be
>> mutually exclusive. XDP over DPDK does make sense.
>>
>
> Because DPDK is more than just a poll mode driver that binds to a
> device. AF_Packet could be used as a replacement for a specific poll
> mode driver but the application could still use the other libraries
> provided by DPDK to build ACLs for example or deep packet inspection.
>
>
>> Tom
>>
>

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

[Jesper Dangaard Brouer]

On Tue, 26 Jul 2016 10:53:05 -0700
John Fastabend  wrote:

> On 16-07-26 09:08 AM, Tom Herbert wrote:
> > On Tue, Jul 26, 2016 at 6:31 AM, Thomas Monjalon
> >  wrote:  
> >> Hi,
> >>
> >> About RX filtering, there is an ongoing effort in DPDK to write an API
> >> which could leverage most of the hardware capabilities of any NICs:
> >> https://rawgit.com/6WIND/rte_flow/master/rte_flow.html
> >> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/43352
> >> I understand that XDP does not target to support every hardware features,
> >> though it may be an interesting approach to check.
> >>  
> > Thomas,
> > 
> > A major goal of XDP is to leverage and in fact encourage innovation in
> > hardware features. But, we are asking that vendors design the APIs
> > with the community in mind. For instance, if XDP supports crypto
> > offload it should have one API that different companies, we don't want
> > every vendor coming up with their own.  
> 
> The work in those threads is to create a single API for users of DPDK
> to interact with their hardware. The equivalent interface in Linux
> kernel is ntuple filters from ethtool the effort here is to make a
> usable interface to manage this from an application and also expose
> all the hardware features. Ethtool does a fairly poor job on both
> fronts IMO.

Yes, the ethtool + ntuple approach is unfortunately not very easy to :-(


> If we evolve the mechanism to run per rx queue xdp programs this
> interface could easily be used to forward packets to specific rx
> queues and run targeted xdp programs.
> 
> Integrating this functionality into running XDP programs as ebpf code
> seems a bit challenging to me because there is no software equivalent.
> Once XDP ebpf program is running the pkt has already landed on the rx
> queue. To me the mechanism to bind XDP programs to rx queues and steer
> specific flows (e.g. match a flow label and forward to a queue) needs
> to be part of the runtime environment not part of the main ebpf program
> itself. 

I agree, based on the discussion in this thread. Will admit that my
initial idea of adding this filter to the eBPF/XDP program was not such
a good idea.

> The runtime environment could use the above linked API. I know
> we debated earlier including this in the ebpf program itself but that
> really doesn't seem feasible to me. Whether the steering is expresses
> as an ebpf program or an API like above seems like a reasonable
> discussion. Perhaps a section could be used to describe the per program
> filter for example which would be different from an API approach used
> in the proposal above or the JIT could translate it into the above
> API for devices without instruction based hardware.

It seems like someone actually put some though into this, in the link
you send... quite interesting, thanks:
 https://rawgit.com/6WIND/rte_flow/master/rte_flow.html

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

[PATCH net-next v3 1/2] e1000e: factor out systim sanitization

[Jarod Wilson]

This is prepatory work for an expanding list of adapter families that have
occasional ~10 hour clock jumps when being used for PTP. Factor out the
sanitization function and convert to using a feature (bug) flag, per
suggestion from Jesse Brandeburg.

Littering functional code with device-specific checks is much messier than
simply checking a flag, and having device-specific init set flags as needed.
There are probably a number of other cases in the e1000e code that
could/should be converted similarly.

Suggested-by: Jesse Brandeburg 
CC: Jesse Brandeburg 
CC: Jeff Kirsher 
CC: intel-wired-...@lists.osuosl.org
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 drivers/net/ethernet/intel/e1000e/82571.c  |  6 ++-
 drivers/net/ethernet/intel/e1000e/e1000.h  |  1 +
 drivers/net/ethernet/intel/e1000e/netdev.c | 66 ++
 3 files changed, 44 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/82571.c 
b/drivers/net/ethernet/intel/e1000e/82571.c
index 7fd4d54..6b03c85 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -2032,7 +2032,8 @@ const struct e1000_info e1000_82574_info = {
  | FLAG2_DISABLE_ASPM_L0S
  | FLAG2_DISABLE_ASPM_L1
  | FLAG2_NO_DISABLE_RX
- | FLAG2_DMA_BURST,
+ | FLAG2_DMA_BURST
+ | FLAG2_CHECK_SYSTIM_OVERFLOW,
.pba= 32,
.max_hw_frame_size  = DEFAULT_JUMBO,
.get_variants   = e1000_get_variants_82571,
@@ -2053,7 +2054,8 @@ const struct e1000_info e1000_82583_info = {
  | FLAG_HAS_CTRLEXT_ON_LOAD,
.flags2 = FLAG2_DISABLE_ASPM_L0S
  | FLAG2_DISABLE_ASPM_L1
- | FLAG2_NO_DISABLE_RX,
+ | FLAG2_NO_DISABLE_RX
+ | FLAG2_CHECK_SYSTIM_OVERFLOW,
.pba= 32,
.max_hw_frame_size  = DEFAULT_JUMBO,
.get_variants   = e1000_get_variants_82571,
diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h 
b/drivers/net/ethernet/intel/e1000e/e1000.h
index ef96cd1..879cca4 100644
--- a/drivers/net/ethernet/intel/e1000e/e1000.h
+++ b/drivers/net/ethernet/intel/e1000e/e1000.h
@@ -452,6 +452,7 @@ s32 e1000e_get_base_timinca(struct e1000_adapter *adapter, 
u32 *timinca);
 #define FLAG2_PCIM2PCI_ARBITER_WA BIT(11)
 #define FLAG2_DFLT_CRC_STRIPPING  BIT(12)
 #define FLAG2_CHECK_RX_HWTSTAMP   BIT(13)
+#define FLAG2_CHECK_SYSTIM_OVERFLOW   BIT(14)
 
 #define E1000_RX_DESC_PS(R, i) \
(&(((union e1000_rx_desc_packet_split *)((R).desc))[i]))
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 41f32c0..1b2df11 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4303,6 +4303,42 @@ void e1000e_reinit_locked(struct e1000_adapter *adapter)
 }
 
 /**
+ * e1000e_sanitize_systim - sanitize raw cycle counter reads
+ * @hw: pointer to the HW structure
+ * @systim: cycle_t value read, sanitized and returned
+ *
+ * Errata for 82574/82583 possible bad bits read from SYSTIMH/L:
+ * check to see that the time is incrementing at a reasonable
+ * rate and is a multiple of incvalue.
+ **/
+static cycle_t e1000e_sanitize_systim(struct e1000_hw *hw, cycle_t systim)
+{
+   u64 time_delta, rem, temp;
+   cycle_t systim_next;
+   u32 incvalue;
+   int i;
+
+   incvalue = er32(TIMINCA) & E1000_TIMINCA_INCVALUE_MASK;
+   for (i = 0; i < E1000_MAX_82574_SYSTIM_REREADS; i++) {
+   /* latch SYSTIMH on read of SYSTIML */
+   systim_next = (cycle_t)er32(SYSTIML);
+   systim_next |= (cycle_t)er32(SYSTIMH) << 32;
+
+   time_delta = systim_next - systim;
+   temp = time_delta;
+   /* VMWare users have seen incvalue of zero, don't div / 0 */
+   rem = incvalue ? do_div(temp, incvalue) : (time_delta != 0);
+
+   systim = systim_next;
+
+   if ((time_delta < E1000_82574_SYSTIM_EPSILON) && (rem == 0))
+   break;
+   }
+
+   return systim;
+}
+
+/**
  * e1000e_cyclecounter_read - read raw cycle counter (used by time counter)
  * @cc: cyclecounter structure
  **/
@@ -4312,7 +4348,7 @@ static cycle_t e1000e_cyclecounter_read(const struct 
cyclecounter *cc)
 cc);
struct e1000_hw *hw = >hw;
u32 systimel, systimeh;
-   cycle_t systim, systim_next;
+   cycle_t systim;
/* SYSTIMH latching upon 

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[alexmcwhirter]

On 2016-07-26 09:59, Christian Lamparter wrote:
Thanks, I gave the program a try with my WNDA3100 and a WN821N v2 
devices.
I did not see any corruptions in any of the tests though. Can you tell 
me
something about your wireless network too? I would like to know what 
router
and firmware are you using? Also important: what's your wireless 
configuration?

(WPA?, CCMP or TKIP? HT40, HT20 or Legacy rates? ...)

Probably the quickest and easiest way to get that information is by 
running
the following commands as root, when you are connected to your wifi 
network

and post the results:
# iw dev wlan0 link
# iw dev wlan0 scan dump

(You can of course remove your device's MACs, but please do it 
consistently).


Regards,
Christian


I wonder if this is something that is only affecting certain NIC's? For 
example, it see this issue on sun4u boxes with tigon3 and hme 
interfaces. But on my sun4v boxes that have e1000 interfaces everything 
works fine.

[PATCH v3 net-next 0/2] e1000e: fix PTP on e1000_pch_variants

[Jarod Wilson]

This little series factors out the systim sanitization code first, then
adds e1000_pch_lpt as a new case in the switch that calls the sanitize
function, fixing PTP clock issues I've had reported against an Intel
I-218V NIC in an Intel NUC5ik5RYH system.

Jarod Wilson (2):
  e1000e: factor out systim sanitization
  e1000e: fix PTP on e1000_pch_lpt variants

Note: this series replaces the previously submitted singleton patch that
was, er, broken, titled the same.

v3: set and use feature flag to decide to call sanitize function

Reported-by: Rupesh Patel 
CC: Jesse Brandeburg 
CC: Jeff Kirsher 
CC: intel-wired-...@lists.osuosl.org
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson 

 drivers/net/ethernet/intel/e1000e/netdev.c | 72 +++---
 1 file changed, 45 insertions(+), 27 deletions(-)

-- 
1.8.3.1

[PATCH net-next v3 2/2] e1000e: fix PTP on e1000_pch_lpt variants

[Jarod Wilson]

I've got reports that the Intel I-218V NIC in Intel NUC5i5RYH systems used
as a PTP slave experiences random ~10 hour clock jumps, which are resolved
if the same workaround for the 82574 and 82583 is employed, so set the
appropriate flag2 in e1000_pch_lpt_info too.

Reported-by: Rupesh Patel 
CC: Jesse Brandeburg 
CC: Jeff Kirsher 
CC: intel-wired-...@lists.osuosl.org
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 drivers/net/ethernet/intel/e1000e/ich8lan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c 
b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 3e11322..f3aaca7 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -5885,7 +5885,8 @@ const struct e1000_info e1000_pch_lpt_info = {
  | FLAG_HAS_JUMBO_FRAMES
  | FLAG_APME_IN_WUC,
.flags2 = FLAG2_HAS_PHY_STATS
- | FLAG2_HAS_EEE,
+ | FLAG2_HAS_EEE
+ | FLAG2_CHECK_SYSTIM_OVERFLOW,
.pba= 26,
.max_hw_frame_size  = 9022,
.get_variants   = e1000_get_variants_ich8lan,
-- 
1.8.3.1

Re: [PATCH net-next v2 0/3] virtio: style cleanups

[Michael S. Tsirkin]

On Tue, Jul 26, 2016 at 09:37:12AM -0700, Stephen Hemminger wrote:
> Minor things found while doing some inspection code review.

Acked-by: Michael S. Tsirkin 

I guess I'll just queue it up for this release.

-- 
MST

Re: [PATCH v2] net/mlx5_core/health: Remove deprecated create_singlethread_workqueue

[Leon Romanovsky]

On Tue, Jul 26, 2016 at 10:38:24PM +0530, Bhaktipriya Shridhar wrote:
> The workqueue health->wq was used as per device private health thread.
> This was done to perform delayed work.
> 
> The workqueue has a single workitem(>work) and
> hence doesn't require ordering. It is involved in handling the health of
> the device and is not being used on a memory reclaim path.
> Hence, the singlethreaded workqueue has been replaced with the use of
> system_wq.
> 
> Work item has been flushed in mlx5_health_cleanup() to ensure that
> there are no pending tasks while disconnecting the driver.
> 
> Signed-off-by: Bhaktipriya Shridhar 
> ---
>  Changes in v2:
>   -Updated commit description as per the feedback received.
> 
>  drivers/net/ethernet/mellanox/mlx5/core/health.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)

Thanks,
Acked-by: Leon Romanovsky 


signature.asc
Description: Digital signature

Re: [PATCH net-next 0/3] qed*: Janitorial series [semantic & prints]

[David Miller]

From: Yuval Mintz 
Date: Tue, 26 Jul 2016 16:58:34 +0300

> Some day 1 slips in coding style exist in the qed* code
> [incorrect alignments, conditions using (== 0), etc.].
> This series comes to address those, and do some additional
> cosmetic changes along the way [such as reducing the number of lines
> for function declerations].
> 
> The series is broken to 3 parts - purely semantic changes, cosmetic
> changes that required minor changes in the code, and print-related
> changes. All-in-all, no real change in driver behavior is expected.
> 
> Please consider applying this to `net-next'.

net-next is closed, please resubmit this after the merge window.

Thanks.

Re: [PATCH net-next 3/3] virtio: use kcalloc and kmalloc_array

[David Miller]

From: Stephen Hemminger 
Date: Tue, 26 Jul 2016 09:35:43 -0700

> On Tue, 26 Jul 2016 09:20:11 -0700
> Stephen Hemminger  wrote:
> 
>> Preferred style is to use kcalloc and kmalloc_array.
>> 
>> Signed-off-by: Stephen Hemminger 
> 
> Do not apply, needs redo. Wasn't updated. properl

net-next is closed anyways, please resubmit this series after the
merge window.

Re: [PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

[Jarod Wilson]

On Tue, Jul 26, 2016 at 10:53:55AM -0700, Jeff Kirsher wrote:
> On Tue, 2016-07-26 at 13:39 -0400, Jarod Wilson wrote:
> > Per Jesse Brandeburg, e1000e should be using flags for this sort of
> > thing.
> > 
> > Littering functional code with device-specific checks is much messier
> > than
> > simply checking a flag, and having device-specific init set flags as
> > needed.
> > There are probably a number of other cases in the e1000e code that
> > could/should be converted similarly.
> > 
> > At present, this patch is a follow-up to the previously submitted 2
> > patches, but I can redo the series to omit the conversion to a switch
> > entirely, if so desired.
> > 
> > Suggested-by: Jesse Brandeburg 
> > CC: Jesse Brandeburg 
> > CC: Jeff Kirsher 
> > CC: intel-wired-...@lists.osuosl.org
> > CC: netdev@vger.kernel.org
> > Signed-off-by: Jarod Wilson 
> > ---
> >  drivers/net/ethernet/intel/e1000e/82571.c   |  6 --
> >  drivers/net/ethernet/intel/e1000e/e1000.h   |  1 +
> >  drivers/net/ethernet/intel/e1000e/ich8lan.c |  3 ++-
> >  drivers/net/ethernet/intel/e1000e/netdev.c  | 10 ++
> >  4 files changed, 9 insertions(+), 11 deletions(-)
> 
> This generates a compile issue, so I will be dropping this patch and will
> await an update.

Yeah, just sent a note off-list, I really shouldn't send patches while on
conference calls. It's a typo in ich8lan.c, where I put FLAGS2_ instead of
FLAG2_. I'll just redo the entire set omitting the switch conversion.

-- 
Jarod Wilson
ja...@redhat.com

Re: [PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

[Jeff Kirsher]

On Tue, 2016-07-26 at 13:39 -0400, Jarod Wilson wrote:
> Per Jesse Brandeburg, e1000e should be using flags for this sort of
> thing.
> 
> Littering functional code with device-specific checks is much messier
> than
> simply checking a flag, and having device-specific init set flags as
> needed.
> There are probably a number of other cases in the e1000e code that
> could/should be converted similarly.
> 
> At present, this patch is a follow-up to the previously submitted 2
> patches, but I can redo the series to omit the conversion to a switch
> entirely, if so desired.
> 
> Suggested-by: Jesse Brandeburg 
> CC: Jesse Brandeburg 
> CC: Jeff Kirsher 
> CC: intel-wired-...@lists.osuosl.org
> CC: netdev@vger.kernel.org
> Signed-off-by: Jarod Wilson 
> ---
>  drivers/net/ethernet/intel/e1000e/82571.c   |  6 --
>  drivers/net/ethernet/intel/e1000e/e1000.h   |  1 +
>  drivers/net/ethernet/intel/e1000e/ich8lan.c |  3 ++-
>  drivers/net/ethernet/intel/e1000e/netdev.c  | 10 ++
>  4 files changed, 9 insertions(+), 11 deletions(-)

This generates a compile issue, so I will be dropping this patch and will
await an update.

signature.asc
Description: This is a digitally signed message part

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

[John Fastabend]

On 16-07-26 09:08 AM, Tom Herbert wrote:
> On Tue, Jul 26, 2016 at 6:31 AM, Thomas Monjalon
>  wrote:
>> Hi,
>>
>> About RX filtering, there is an ongoing effort in DPDK to write an API
>> which could leverage most of the hardware capabilities of any NICs:
>> https://rawgit.com/6WIND/rte_flow/master/rte_flow.html
>> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/43352
>> I understand that XDP does not target to support every hardware features,
>> though it may be an interesting approach to check.
>>
> Thomas,
> 
> A major goal of XDP is to leverage and in fact encourage innovation in
> hardware features. But, we are asking that vendors design the APIs
> with the community in mind. For instance, if XDP supports crypto
> offload it should have one API that different companies, we don't want
> every vendor coming up with their own.

The work in those threads is to create a single API for users of DPDK
to interact with their hardware. The equivalent interface in Linux
kernel is ntuple filters from ethtool the effort here is to make a
usable interface to manage this from an application and also expose
all the hardware features. Ethtool does a fairly poor job on both
fronts IMO.

If we evolve the mechanism to run per rx queue xdp programs this
interface could easily be used to forward packets to specific rx
queues and run targeted xdp programs.

Integrating this functionality into running XDP programs as ebpf code
seems a bit challenging to me because there is no software equivalent.
Once XDP ebpf program is running the pkt has already landed on the rx
queue. To me the mechanism to bind XDP programs to rx queues and steer
specific flows (e.g. match a flow label and forward to a queue) needs
to be part of the runtime environment not part of the main ebpf program
itself. The runtime environment could use the above linked API. I know
we debated earlier including this in the ebpf program itself but that
really doesn't seem feasible to me. Whether the steering is expresses
as an ebpf program or an API like above seems like a reasonable
discussion. Perhaps a section could be used to describe the per program
filter for example which would be different from an API approach used
in the proposal above or the JIT could translate it into the above
API for devices without instruction based hardware.

Step 0 should be to show a set of compelling use cases that want to run
per queue programs then we can talk about the runtime.


> 
>> 2016-07-12 22:32, Jesper Dangaard Brouer via iovisor-dev:
>>> On Tue, 12 Jul 2016 12:13:01 -0700
>>> John Fastabend  wrote:

 Another use case I have is to make a really high performance AF_PACKET
 interface. So if there was a way to say bind a queue to an AF_PACKET
 ring and run a policy XDP program before hitting the AF_PACKET
 descriptor bit that would be really interesting because it would solve
 some of my need for poll mode drivers in userspace.
>>
>> Have you started this work?
>> Do you have an idea of how RX would perform through XDP + AF_PACKET + DPDK?
>>
> I don't understand why the AF_PACKET with DPDK. They should be
> mutually exclusive. XDP over DPDK does make sense.
> 

Because DPDK is more than just a poll mode driver that binds to a
device. AF_Packet could be used as a replacement for a specific poll
mode driver but the application could still use the other libraries
provided by DPDK to build ACLs for example or deep packet inspection.


> Tom
> 

Re: [PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

[David Miller]

From: Dexuan Cui 
Date: Tue, 26 Jul 2016 07:09:41 +

> I googled "S390 hypervisor socket" but didn't find anything related (I think).

That would be net/iucv/

There's also VMWare's stuff under net/vmw_vsock

It's just absolutely rediculous to make a new hypervisor socket
interface over and over again, so much code duplication and
replication.

[PATCH net-next 3/2] e1000e: convert systim overflow check to use flags2

[Jarod Wilson]

Per Jesse Brandeburg, e1000e should be using flags for this sort of thing.

Littering functional code with device-specific checks is much messier than
simply checking a flag, and having device-specific init set flags as needed.
There are probably a number of other cases in the e1000e code that
could/should be converted similarly.

At present, this patch is a follow-up to the previously submitted 2
patches, but I can redo the series to omit the conversion to a switch
entirely, if so desired.

Suggested-by: Jesse Brandeburg 
CC: Jesse Brandeburg 
CC: Jeff Kirsher 
CC: intel-wired-...@lists.osuosl.org
CC: netdev@vger.kernel.org
Signed-off-by: Jarod Wilson 
---
 drivers/net/ethernet/intel/e1000e/82571.c   |  6 --
 drivers/net/ethernet/intel/e1000e/e1000.h   |  1 +
 drivers/net/ethernet/intel/e1000e/ich8lan.c |  3 ++-
 drivers/net/ethernet/intel/e1000e/netdev.c  | 10 ++
 4 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/intel/e1000e/82571.c 
b/drivers/net/ethernet/intel/e1000e/82571.c
index 7fd4d54..6b03c85 100644
--- a/drivers/net/ethernet/intel/e1000e/82571.c
+++ b/drivers/net/ethernet/intel/e1000e/82571.c
@@ -2032,7 +2032,8 @@ const struct e1000_info e1000_82574_info = {
  | FLAG2_DISABLE_ASPM_L0S
  | FLAG2_DISABLE_ASPM_L1
  | FLAG2_NO_DISABLE_RX
- | FLAG2_DMA_BURST,
+ | FLAG2_DMA_BURST
+ | FLAG2_CHECK_SYSTIM_OVERFLOW,
.pba= 32,
.max_hw_frame_size  = DEFAULT_JUMBO,
.get_variants   = e1000_get_variants_82571,
@@ -2053,7 +2054,8 @@ const struct e1000_info e1000_82583_info = {
  | FLAG_HAS_CTRLEXT_ON_LOAD,
.flags2 = FLAG2_DISABLE_ASPM_L0S
  | FLAG2_DISABLE_ASPM_L1
- | FLAG2_NO_DISABLE_RX,
+ | FLAG2_NO_DISABLE_RX
+ | FLAG2_CHECK_SYSTIM_OVERFLOW,
.pba= 32,
.max_hw_frame_size  = DEFAULT_JUMBO,
.get_variants   = e1000_get_variants_82571,
diff --git a/drivers/net/ethernet/intel/e1000e/e1000.h 
b/drivers/net/ethernet/intel/e1000e/e1000.h
index ef96cd1..879cca4 100644
--- a/drivers/net/ethernet/intel/e1000e/e1000.h
+++ b/drivers/net/ethernet/intel/e1000e/e1000.h
@@ -452,6 +452,7 @@ s32 e1000e_get_base_timinca(struct e1000_adapter *adapter, 
u32 *timinca);
 #define FLAG2_PCIM2PCI_ARBITER_WA BIT(11)
 #define FLAG2_DFLT_CRC_STRIPPING  BIT(12)
 #define FLAG2_CHECK_RX_HWTSTAMP   BIT(13)
+#define FLAG2_CHECK_SYSTIM_OVERFLOW   BIT(14)
 
 #define E1000_RX_DESC_PS(R, i) \
(&(((union e1000_rx_desc_packet_split *)((R).desc))[i]))
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c 
b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 3e11322..395ca26 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -5885,7 +5885,8 @@ const struct e1000_info e1000_pch_lpt_info = {
  | FLAG_HAS_JUMBO_FRAMES
  | FLAG_APME_IN_WUC,
.flags2 = FLAG2_HAS_PHY_STATS
- | FLAG2_HAS_EEE,
+ | FLAG2_HAS_EEE
+ | FLAGS2_CHECK_SYSTIM_OVERFLOW,
.pba= 26,
.max_hw_frame_size  = 9022,
.get_variants   = e1000_get_variants_ich8lan,
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 206bd6a..1b2df11 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4371,15 +4371,9 @@ static cycle_t e1000e_cyclecounter_read(const struct 
cyclecounter *cc)
systim = (cycle_t)systimel;
systim |= (cycle_t)systimeh << 32;
 
-   switch (hw->mac.type) {
-   case e1000_82574:
-   case e1000_82583:
-   case e1000_pch_lpt:
+   if (adapter->flags2 & FLAG2_CHECK_SYSTIM_OVERFLOW)
systim = e1000e_sanitize_systim(hw, systim);
-   break;
-   default:
-   break;
-   }
+
return systim;
 }
 
-- 
1.8.3.1

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Michael Kerrisk (man-pages)]

On 26 July 2016 at 18:52, Kees Cook  wrote:
> On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman
>  wrote:
>> "Michael Kerrisk (man-pages)"  writes:
>>
>>> Hello Eric,
>>>
>>> I realized I had a question after the last mail.
>>>
>>> On 07/21/2016 06:39 PM, Eric W. Biederman wrote:

 This patchset addresses two use cases:
 - Implement a sane upper bound on the number of namespaces.
 - Provide a way for sandboxes to limit the attack surface from
   namespaces.
>>>
>>> Can you say more about the second point? What exactly is the
>>> problem that is being addressed, and how does the patch series
>>> address it? (It would be good to have those details in the
>>> revised commit message...)
>>
>> At some point it was reported that seccomp was not sufficient to disable
>> namespace creation.  I need to go back and look at that claim to see
>> which set of circumstances that was referring to.  Seccomp doesn't stack
>> so I can see why it is an issue.
>
> seccomp does stack. The trouble usually comes from a perception that
> seccomp overhead is not trivial, so setting a system-wide policy is a
> bit of a large hammer for such a limitiation. Also, at the time,
> seccomp could be bypasses with ptrace, but this (as of v4.8) is no
> longer true.

Sounds like someone needs to send me a patch for the seccomp.2 man page?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[PATCH v2] net/mlx5_core/health: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue health->wq was used as per device private health thread.
This was done to perform delayed work.

The workqueue has a single workitem(>work) and
hence doesn't require ordering. It is involved in handling the health of
the device and is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

Work item has been flushed in mlx5_health_cleanup() to ensure that
there are no pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 Changes in v2:
-Updated commit description as per the feedback received.

 drivers/net/ethernet/mellanox/mlx5/core/health.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c 
b/drivers/net/ethernet/mellanox/mlx5/core/health.c
index 42d16b9..9acbccf 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -267,7 +267,7 @@ static void poll_health(unsigned long data)
if (in_fatal(dev) && !health->sick) {
health->sick = true;
print_health_info(dev);
-   queue_work(health->wq, >work);
+   schedule_work(>work);
}
 }

@@ -296,7 +296,7 @@ void mlx5_health_cleanup(struct mlx5_core_dev *dev)
 {
struct mlx5_core_health *health = >priv.health;

-   destroy_workqueue(health->wq);
+   flush_work(>work);
 }

 int mlx5_health_init(struct mlx5_core_dev *dev)
@@ -311,10 +311,7 @@ int mlx5_health_init(struct mlx5_core_dev *dev)

strcpy(name, "mlx5_health");
strcat(name, dev_name(>pdev->dev));
-   health->wq = create_singlethread_workqueue(name);
kfree(name);
-   if (!health->wq)
-   return -ENOMEM;

INIT_WORK(>work, health_care);

--
2.1.4

Re: patch for PCH_GBE rotten packet (Intel EG20T Platform Controller).

[Alexander Duyck]

On Tue, Jul 26, 2016 at 9:00 AM, Tom Walsh  wrote:
> Not sure how this goes, but, we found a race condition in
> drivers/net/ethernet/oki-semi/pch_gbe/
>
> The attached patch corrects for this.
>
> TomW

So a few minor changes are probably needed.

First we don't recommend the use of camel case for variable names.  So
"resetStatus" should probably be renamed to "reset_status".  Second is
the fact that you seemed to have removed a tab that didn't need to be
removed before the read of the INT_EN register.  Third you need to add
a "Signed-off-by" containing your name and email address.  Finally we
usually require the patches to be emailed inline to avoid having the
attachments stripped.

You might also wan to go through the steps called out in
https://www.kernel.org/doc/Documentation/SubmittingPatches

Hope this helps.

- Alex

Re: [PATCH net-next v2 1/3] virtio: whitespace cleanups

[Michael S. Tsirkin]

On Tue, Jul 26, 2016 at 09:37:13AM -0700, Stephen Hemminger wrote:
> Adjust whitespace to match current favored style.
> 
> Signed-off-by: Stephen Hemminger 
> 
> --- a/drivers/net/virtio_net.c2016-07-20 08:12:24.035656119 -0700
> +++ b/drivers/net/virtio_net.c2016-07-26 09:11:06.988788668 -0700
> @@ -201,7 +201,9 @@ static void give_pages(struct receive_qu
>   struct page *end;
>  
>   /* Find end of list, sew whole thing into vi->rq.pages. */
> - for (end = page; end->private; end = (struct page *)end->private);
> + for (end = page; end->private; end = (struct page *)end->private)
> + continue;
> +
>   end->private = (unsigned long)rq->pages;
>   rq->pages = page;
>  }
> @@ -233,13 +235,13 @@ static void skb_xmit_done(struct virtque
>  static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
>  {
>   unsigned int truesize = mrg_ctx & (MERGEABLE_BUFFER_ALIGN - 1);
> +
>   return (truesize + 1) * MERGEABLE_BUFFER_ALIGN;
>  }
>  
>  static void *mergeable_ctx_to_buf_address(unsigned long mrg_ctx)
>  {
>   return (void *)(mrg_ctx & -MERGEABLE_BUFFER_ALIGN);
> -
>  }
>  
>  static unsigned long mergeable_buf_to_ctx(void *buf, unsigned int truesize)
> @@ -310,6 +312,7 @@ static struct sk_buff *page_to_skb(struc
>   BUG_ON(offset >= PAGE_SIZE);
>   while (len) {
>   unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len);
> +
>   skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset,
>   frag_size, truesize);
>   len -= frag_size;
> @@ -323,9 +326,10 @@ static struct sk_buff *page_to_skb(struc
>   return skb;
>  }
>  
> -static struct sk_buff *receive_small(struct virtnet_info *vi, void *buf, 
> unsigned int len)
> +static struct sk_buff *receive_small(struct virtnet_info *vi,
> +  void *buf, unsigned int len)
>  {
> - struct sk_buff * skb = buf;
> + struct sk_buff *skb = buf;
>  
>   len -= vi->hdr_len;
>   skb_trim(skb, len);
> @@ -455,6 +459,7 @@ static void receive_buf(struct virtnet_i
>   if (vi->mergeable_rx_bufs) {
>   unsigned long ctx = (unsigned long)buf;
>   void *base = mergeable_ctx_to_buf_address(ctx);
> +
>   put_page(virt_to_head_page(base));
>   } else if (vi->big_packets) {
>   give_pages(rq, buf);
> @@ -699,7 +704,7 @@ static void refill_work(struct work_stru
>* we will *never* try to fill again.
>*/
>   if (still_empty)
> - schedule_delayed_work(>refill, HZ/2);
> + schedule_delayed_work(>refill, HZ / 2);
>   }
>  }
>  
> @@ -901,12 +906,12 @@ static netdev_tx_t start_xmit(struct sk_
>* Since most packets only take 1 or 2 ring slots, stopping the queue
>* early means 16 slots are typically wasted.
>*/
> - if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
> + if (sq->vq->num_free < 2 + MAX_SKB_FRAGS) {
>   netif_stop_subqueue(dev, qnum);
>   if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
>   /* More just got used, free them then recheck. */
>   free_old_xmit_skbs(sq);
> - if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
> + if (sq->vq->num_free >= 2 + MAX_SKB_FRAGS) {
>   netif_start_subqueue(dev, qnum);
>   virtqueue_disable_cb(sq->vq);
>   }
> @@ -1238,11 +1243,11 @@ static void virtnet_set_affinity(struct
>  }
>  
>  static int virtnet_cpu_callback(struct notifier_block *nfb,
> - unsigned long action, void *hcpu)
> + unsigned long action, void *hcpu)
>  {
>   struct virtnet_info *vi = container_of(nfb, struct virtnet_info, nb);
>  
> - switch(action & ~CPU_TASKS_FROZEN) {
> + switch (action & ~CPU_TASKS_FROZEN) {
>   case CPU_ONLINE:
>   case CPU_DOWN_FAILED:
>   case CPU_DEAD:
> @@ -1259,7 +1264,7 @@ static int virtnet_cpu_callback(struct n
>  }
>  
>  static void virtnet_get_ringparam(struct net_device *dev,
> - struct ethtool_ringparam *ring)
> +   struct ethtool_ringparam *ring)
>  {
>   struct virtnet_info *vi = netdev_priv(dev);
>  
> @@ -1269,7 +1274,6 @@ static void virtnet_get_ringparam(struct
>   ring->tx_pending = ring->tx_max_pending;
>  }
>  
> -
>  static void virtnet_get_drvinfo(struct net_device *dev,
>   struct ethtool_drvinfo *info)
>  {
> @@ -1279,7 +1283,6 @@ static void virtnet_get_drvinfo(struct n
>   strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
>   strlcpy(info->version, VIRTNET_DRIVER_VERSION, sizeof(info->version));
>   

[PATCH net-next v2] net: ipmr/ip6mr: update lastuse on entry change

[Nikolay Aleksandrov]

Currently lastuse is updated on entry creation and cache hit, but it should
also be updated on entry change. Since both on add and update the ttl array
is updated we can simply update the lastuse in ipmr_update_thresholds.

Signed-off-by: Nikolay Aleksandrov 
CC: Roopa Prabhu 
CC: Donald Sharp 
CC: David S. Miller 
---
v2: instead of duplicating the lastuse update, do it while updating the
thresholds which is shared by add/update

 net/ipv4/ipmr.c  | 2 +-
 net/ipv6/ip6mr.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index eec234161b89..26253328d227 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -722,6 +722,7 @@ static void ipmr_update_thresholds(struct mr_table *mrt, 
struct mfc_cache *cache
cache->mfc_un.res.maxvif = vifi + 1;
}
}
+   cache->mfc_un.res.lastuse = jiffies;
 }
 
 static int vif_add(struct net *net, struct mr_table *mrt,
@@ -1150,7 +1151,6 @@ static int ipmr_mfc_add(struct net *net, struct mr_table 
*mrt,
c->mfc_origin = mfc->mfcc_origin.s_addr;
c->mfc_mcastgrp = mfc->mfcc_mcastgrp.s_addr;
c->mfc_parent = mfc->mfcc_parent;
-   c->mfc_un.res.lastuse = jiffies;
ipmr_update_thresholds(mrt, c, mfc->mfcc_ttls);
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 7adce139d92a..6122f9c5cc49 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -921,6 +921,7 @@ static void ip6mr_update_thresholds(struct mr6_table *mrt, 
struct mfc6_cache *ca
cache->mfc_un.res.maxvif = vifi + 1;
}
}
+   cache->mfc_un.res.lastuse = jiffies;
 }
 
 static int mif6_add(struct net *net, struct mr6_table *mrt,
@@ -1500,7 +1501,6 @@ static int ip6mr_mfc_add(struct net *net, struct 
mr6_table *mrt,
c->mf6c_origin = mfc->mf6cc_origin.sin6_addr;
c->mf6c_mcastgrp = mfc->mf6cc_mcastgrp.sin6_addr;
c->mf6c_parent = mfc->mf6cc_parent;
-   c->mfc_un.res.lastuse = jiffies;
ip6mr_update_thresholds(mrt, c, ttls);
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
-- 
2.1.4

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Kees Cook]

On Tue, Jul 26, 2016 at 8:06 AM, Eric W. Biederman
 wrote:
> "Michael Kerrisk (man-pages)"  writes:
>
>> Hello Eric,
>>
>> I realized I had a question after the last mail.
>>
>> On 07/21/2016 06:39 PM, Eric W. Biederman wrote:
>>>
>>> This patchset addresses two use cases:
>>> - Implement a sane upper bound on the number of namespaces.
>>> - Provide a way for sandboxes to limit the attack surface from
>>>   namespaces.
>>
>> Can you say more about the second point? What exactly is the
>> problem that is being addressed, and how does the patch series
>> address it? (It would be good to have those details in the
>> revised commit message...)
>
> At some point it was reported that seccomp was not sufficient to disable
> namespace creation.  I need to go back and look at that claim to see
> which set of circumstances that was referring to.  Seccomp doesn't stack
> so I can see why it is an issue.

seccomp does stack. The trouble usually comes from a perception that
seccomp overhead is not trivial, so setting a system-wide policy is a
bit of a large hammer for such a limitiation. Also, at the time,
seccomp could be bypasses with ptrace, but this (as of v4.8) is no
longer true.

> The general problem is that namespaces by their nature (and especially
> in combination with the user namespaces) allow unprivileged users to use
> more of the kernel than a user would have access to without them.  This
> in turn allows malicious users more kernel calls they can use in attempt
> to find an exploitable bug.
>
> So if you are building a sandbox/chroot jail/chromium tab or anything
> like that and you know you won't be needing a kernel feature having an
> easy way to disable the feature is useful for making the kernel
> marginally more secure, as certain attack vectors are no longer
> possible.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH net-next v2 0/3] virtio: style cleanups

[Stephen Hemminger]

Minor things found while doing some inspection code review.

[PATCH net-next v2 2/3] virtio: cleanup sizeof usage

[Stephen Hemminger]

Although sizeof is an operator in C. Preferred usage is to use
it as a function.

Signed-off-by: Stephen Hemminger 

--- a/drivers/net/virtio_net.c  2016-07-26 09:13:16.173384238 -0700
+++ b/drivers/net/virtio_net.c  2016-07-26 09:13:16.169384220 -0700
@@ -272,7 +272,7 @@ static struct sk_buff *page_to_skb(struc
 
hdr_len = vi->hdr_len;
if (vi->mergeable_rx_bufs)
-   hdr_padded_len = sizeof *hdr;
+   hdr_padded_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
else
hdr_padded_len = sizeof(struct padded_vnet_hdr);
 

[PATCH net-next v2 3/3] virtio: use kcalloc and kmalloc_array

[Stephen Hemminger]

Preferred style is to use kcalloc and kmalloc_array.

Signed-off-by: Stephen Hemminger 

--- a/drivers/net/virtio_net.c  2016-07-26 09:28:21.401557546 -0700
+++ b/drivers/net/virtio_net.c  2016-07-26 09:36:05.107695337 -0700
@@ -1551,13 +1551,13 @@ static int virtnet_find_vqs(struct virtn
virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ);
 
/* Allocate space for find_vqs parameters */
-   vqs = kzalloc(total_vqs * sizeof(*vqs), GFP_KERNEL);
+   vqs = kcalloc(total_vqs, sizeof(*vqs), GFP_KERNEL);
if (!vqs)
goto err_vq;
-   callbacks = kmalloc(total_vqs * sizeof(*callbacks), GFP_KERNEL);
+   callbacks = kmalloc_array(total_vqs, sizeof(*callbacks), GFP_KERNEL);
if (!callbacks)
goto err_callback;
-   names = kmalloc(total_vqs * sizeof(*names), GFP_KERNEL);
+   names = kmalloc_array(total_vqs, sizeof(*names), GFP_KERNEL);
if (!names)
goto err_names;
 
@@ -1613,10 +1613,10 @@ static int virtnet_alloc_queues(struct v
 {
int i;
 
-   vi->sq = kzalloc(sizeof(*vi->sq) * vi->max_queue_pairs, GFP_KERNEL);
+   vi->sq = kcalloc(vi->max_queue_pairs, sizeof(*vi->sq), GFP_KERNEL);
if (!vi->sq)
goto err_sq;
-   vi->rq = kzalloc(sizeof(*vi->rq) * vi->max_queue_pairs, GFP_KERNEL);
+   vi->rq = kcalloc(vi->max_queue_pairs, sizeof(*vi->rq), GFP_KERNEL);
if (!vi->rq)
goto err_rq;
 

[PATCH net-next v2 1/3] virtio: whitespace cleanups

[Stephen Hemminger]

Adjust whitespace to match current favored style.

Signed-off-by: Stephen Hemminger 

--- a/drivers/net/virtio_net.c  2016-07-20 08:12:24.035656119 -0700
+++ b/drivers/net/virtio_net.c  2016-07-26 09:11:06.988788668 -0700
@@ -201,7 +201,9 @@ static void give_pages(struct receive_qu
struct page *end;
 
/* Find end of list, sew whole thing into vi->rq.pages. */
-   for (end = page; end->private; end = (struct page *)end->private);
+   for (end = page; end->private; end = (struct page *)end->private)
+   continue;
+
end->private = (unsigned long)rq->pages;
rq->pages = page;
 }
@@ -233,13 +235,13 @@ static void skb_xmit_done(struct virtque
 static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
 {
unsigned int truesize = mrg_ctx & (MERGEABLE_BUFFER_ALIGN - 1);
+
return (truesize + 1) * MERGEABLE_BUFFER_ALIGN;
 }
 
 static void *mergeable_ctx_to_buf_address(unsigned long mrg_ctx)
 {
return (void *)(mrg_ctx & -MERGEABLE_BUFFER_ALIGN);
-
 }
 
 static unsigned long mergeable_buf_to_ctx(void *buf, unsigned int truesize)
@@ -310,6 +312,7 @@ static struct sk_buff *page_to_skb(struc
BUG_ON(offset >= PAGE_SIZE);
while (len) {
unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len);
+
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset,
frag_size, truesize);
len -= frag_size;
@@ -323,9 +326,10 @@ static struct sk_buff *page_to_skb(struc
return skb;
 }
 
-static struct sk_buff *receive_small(struct virtnet_info *vi, void *buf, 
unsigned int len)
+static struct sk_buff *receive_small(struct virtnet_info *vi,
+void *buf, unsigned int len)
 {
-   struct sk_buff * skb = buf;
+   struct sk_buff *skb = buf;
 
len -= vi->hdr_len;
skb_trim(skb, len);
@@ -455,6 +459,7 @@ static void receive_buf(struct virtnet_i
if (vi->mergeable_rx_bufs) {
unsigned long ctx = (unsigned long)buf;
void *base = mergeable_ctx_to_buf_address(ctx);
+
put_page(virt_to_head_page(base));
} else if (vi->big_packets) {
give_pages(rq, buf);
@@ -699,7 +704,7 @@ static void refill_work(struct work_stru
 * we will *never* try to fill again.
 */
if (still_empty)
-   schedule_delayed_work(>refill, HZ/2);
+   schedule_delayed_work(>refill, HZ / 2);
}
 }
 
@@ -901,12 +906,12 @@ static netdev_tx_t start_xmit(struct sk_
 * Since most packets only take 1 or 2 ring slots, stopping the queue
 * early means 16 slots are typically wasted.
 */
-   if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
+   if (sq->vq->num_free < 2 + MAX_SKB_FRAGS) {
netif_stop_subqueue(dev, qnum);
if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
free_old_xmit_skbs(sq);
-   if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
+   if (sq->vq->num_free >= 2 + MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
}
@@ -1238,11 +1243,11 @@ static void virtnet_set_affinity(struct
 }
 
 static int virtnet_cpu_callback(struct notifier_block *nfb,
-   unsigned long action, void *hcpu)
+   unsigned long action, void *hcpu)
 {
struct virtnet_info *vi = container_of(nfb, struct virtnet_info, nb);
 
-   switch(action & ~CPU_TASKS_FROZEN) {
+   switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
case CPU_DOWN_FAILED:
case CPU_DEAD:
@@ -1259,7 +1264,7 @@ static int virtnet_cpu_callback(struct n
 }
 
 static void virtnet_get_ringparam(struct net_device *dev,
-   struct ethtool_ringparam *ring)
+ struct ethtool_ringparam *ring)
 {
struct virtnet_info *vi = netdev_priv(dev);
 
@@ -1269,7 +1274,6 @@ static void virtnet_get_ringparam(struct
ring->tx_pending = ring->tx_max_pending;
 }
 
-
 static void virtnet_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
 {
@@ -1279,7 +1283,6 @@ static void virtnet_get_drvinfo(struct n
strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
strlcpy(info->version, VIRTNET_DRIVER_VERSION, sizeof(info->version));
strlcpy(info->bus_info, virtio_bus_name(vdev), sizeof(info->bus_info));
-
 }
 
 /* TODO: Eliminate OOO packets during switching */
@@ -1402,9 +1405,9 @@ static int virtnet_change_mtu(struct net
 }
 
 static 

Re: [PATCH net-next 3/3] virtio: use kcalloc and kmalloc_array

[Stephen Hemminger]

On Tue, 26 Jul 2016 09:20:11 -0700
Stephen Hemminger  wrote:

> Preferred style is to use kcalloc and kmalloc_array.
> 
> Signed-off-by: Stephen Hemminger 

Do not apply, needs redo. Wasn't updated. properly

Re: [PATCH net-next 3/3] virtio: use kcalloc and kmalloc_array

[Michael S. Tsirkin]

On Tue, Jul 26, 2016 at 09:20:11AM -0700, Stephen Hemminger wrote:
> Preferred style is to use kcalloc and kmalloc_array.
> 
> Signed-off-by: Stephen Hemminger 
> 
> --- a/drivers/net/virtio_net.c2016-07-26 09:13:19.805400983 -0700
> +++ b/drivers/net/virtio_net.c2016-07-26 09:13:19.801400965 -0700
> @@ -1551,13 +1551,13 @@ static int virtnet_find_vqs(struct virtn
>   virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ);
>  
>   /* Allocate space for find_vqs parameters */
> - vqs = kzalloc(total_vqs * sizeof(*vqs), GFP_KERNEL);
> + vqs = kzalloc(total_vqs, sizeof(*vqs), GFP_KERNEL);

Does this  build? kzalloc seems to take only two arguments ... what
am I missing?


>   if (!vqs)
>   goto err_vq;
> - callbacks = kmalloc(total_vqs * sizeof(*callbacks), GFP_KERNEL);
> + callbacks = kmalloc_array(total_vqs, sizeof(*callbacks), GFP_KERNEL);
>   if (!callbacks)
>   goto err_callback;
> - names = kmalloc(total_vqs * sizeof(*names), GFP_KERNEL);
> + names = kmalloc_array(total_vqs, sizeof(*names), GFP_KERNEL);
>   if (!names)
>   goto err_names;
>  
> @@ -1613,10 +1613,10 @@ static int virtnet_alloc_queues(struct v
>  {
>   int i;
>  
> - vi->sq = kzalloc(sizeof(*vi->sq) * vi->max_queue_pairs, GFP_KERNEL);
> + vi->sq = kcalloc(vi->max_queue_pairs, sizeof(*vi->sq), GFP_KERNEL);
>   if (!vi->sq)
>   goto err_sq;
> - vi->rq = kzalloc(sizeof(*vi->rq) * vi->max_queue_pairs, GFP_KERNEL);
> + vi->rq = kcalloc(vi->max_queue_pairs, sizeof(*vi->rq), GFP_KERNEL);
>   if (!vi->rq)
>   goto err_rq;
>  

[PATCH net-next] net: ipmr/ip6mr: update lastuse on entry change

[Nikolay Aleksandrov]

Currently lastuse is updated on entry creation and cache hit, but it should
also be updated on entry change.

Signed-off-by: Nikolay Aleksandrov 
CC: Roopa Prabhu 
CC: Donald Sharp 
CC: David S. Miller 
---
 net/ipv4/ipmr.c  | 1 +
 net/ipv6/ip6mr.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index eec234161b89..8f032428c14c 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1135,6 +1135,7 @@ static int ipmr_mfc_add(struct net *net, struct mr_table 
*mrt,
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
write_unlock_bh(_lock);
+   c->mfc_un.res.lastuse = jiffies;
mroute_netlink_event(mrt, c, RTM_NEWROUTE);
return 0;
}
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 7adce139d92a..45c5b30a3a8a 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1485,6 +1485,7 @@ static int ip6mr_mfc_add(struct net *net, struct 
mr6_table *mrt,
if (!mrtsock)
c->mfc_flags |= MFC_STATIC;
write_unlock_bh(_lock);
+   c->mfc_un.res.lastuse = jiffies;
mr6_netlink_event(mrt, c, RTM_NEWROUTE);
return 0;
}
-- 
2.1.4

Re: [PATCH net-next 3/3] virtio: use kcalloc and kmalloc_array

[Nikolay Aleksandrov]

On 26/07/16 18:20, Stephen Hemminger wrote:
> Preferred style is to use kcalloc and kmalloc_array.
> 
> Signed-off-by: Stephen Hemminger 
> 
> --- a/drivers/net/virtio_net.c2016-07-26 09:13:19.805400983 -0700
> +++ b/drivers/net/virtio_net.c2016-07-26 09:13:19.801400965 -0700
> @@ -1551,13 +1551,13 @@ static int virtnet_find_vqs(struct virtn
>   virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ);
>  
>   /* Allocate space for find_vqs parameters */
> - vqs = kzalloc(total_vqs * sizeof(*vqs), GFP_KERNEL);
> + vqs = kzalloc(total_vqs, sizeof(*vqs), GFP_KERNEL);

I don't think this patch will compile.
Too much args for kzalloc, s/kzalloc/kcalloc/

Cheers,
 Nik

>   if (!vqs)
>   goto err_vq;
> - callbacks = kmalloc(total_vqs * sizeof(*callbacks), GFP_KERNEL);
> + callbacks = kmalloc_array(total_vqs, sizeof(*callbacks), GFP_KERNEL);
>   if (!callbacks)
>   goto err_callback;
> - names = kmalloc(total_vqs * sizeof(*names), GFP_KERNEL);
> + names = kmalloc_array(total_vqs, sizeof(*names), GFP_KERNEL);
>   if (!names)
>   goto err_names;
>  
> @@ -1613,10 +1613,10 @@ static int virtnet_alloc_queues(struct v
>  {
>   int i;
>  
> - vi->sq = kzalloc(sizeof(*vi->sq) * vi->max_queue_pairs, GFP_KERNEL);
> + vi->sq = kcalloc(vi->max_queue_pairs, sizeof(*vi->sq), GFP_KERNEL);
>   if (!vi->sq)
>   goto err_sq;
> - vi->rq = kzalloc(sizeof(*vi->rq) * vi->max_queue_pairs, GFP_KERNEL);
> + vi->rq = kcalloc(vi->max_queue_pairs, sizeof(*vi->rq), GFP_KERNEL);
>   if (!vi->rq)
>   goto err_rq;
>  
> 

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

[Eric Dumazet]

On Tue, 2016-07-26 at 23:32 +0800, Fengguang Wu wrote:
> Hi Eric,
> 
> It works!
> 
> On Tue, Jul 26, 2016 at 11:14:52AM +0200, Eric Dumazet wrote:
> >On Tue, 2016-07-26 at 11:50 +0800, Fengguang Wu wrote:
> >> Greetings,
> >>
> >> This BUG message can be found in recent kernels as well as v4.4 and
> >> linux-stable. It happens when running
> >>
> >> modprobe netconsole netconsole=@/,$port@$server/
> >>
> >> [   39.937534] 22 Jul 13:30:40 ntpdate[440]: step time server 192.168.1.1 
> >> offset -673.833841 sec
> >> [   39.943285] netpoll: netconsole: local port 6665
> >> [   39.943436] netpoll: netconsole: local IPv4 address 0.0.0.0
> >> [   39.943609] netpoll: netconsole: interface 'eth0'
> >> [   39.943756] netpoll: netconsole: remote port 6672
> >> [   39.943913] netpoll: netconsole: remote IPv4 address 192.168.1.1
> >> [   39.944099] netpoll: netconsole: remote ethernet address 
> >> ff:ff:ff:ff:ff:ff
> >> [   39.944311] netpoll: netconsole: local IP 192.168.1.193
> >> [   39.944514] BUG: sleeping function called from invalid context at 
> >> kernel/irq/manage.c:110
> >> [   39.944515] in_atomic(): 1, irqs_disabled(): 1, pid: 448, name: modprobe
> >> [   39.944517] CPU: 6 PID: 448 Comm: modprobe Not tainted 
> >> 4.7.0-rc7-wt-ath-10122-gf9b5ec2 #102
> >> [   39.944518] Hardware name:  /DZ77BH-55K, BIOS 
> >> BHZ7710H.86A.0097.2012.1228.1346 12/28/2012
> >> [   39.944522]   c90001f2f9e8 813417d9 
> >> 88007faba5c0
> >> [   39.944524]  006e c90001f2fa00 810aec03 
> >> 81a25948
> >> [   39.944525]  c90001f2fa28 810aec9a 8803e5bd9400 
> >> 8803e50fbd68
> >> [   39.944526] Call Trace:
> >> [   39.944533]  [] dump_stack+0x63/0x8a
> >> [   39.944536]  [] ___might_sleep+0xd3/0x120
> >> [   39.944537]  [] __might_sleep+0x4a/0x80
> >> [   39.944541]  [] synchronize_irq+0x38/0xa0
> >> [   39.944543]  [] ? __irq_put_desc_unlock+0x1e/0x40
> >> [   39.944545]  [] ? __disable_irq_nosync+0x43/0x60
> >> [   39.944547]  [] disable_irq+0x1c/0x20
> >> [   39.944559]  [] e1000_netpoll+0xf2/0x120 [e1000e]
> >> [   39.944563]  [] netpoll_poll_dev+0x5c/0x1a0
> >> [   39.944567]  [] ? __kmalloc_reserve+0x31/0x90
> >> [   39.944569]  [] netpoll_send_skb_on_dev+0x16b/0x250
> >> [   39.944572]  [] netpoll_send_udp+0x2ec/0x450
> >> [   39.944576]  [] write_msg+0xb2/0xf0 [netconsole]
> >> [   39.944578]  [] call_console_drivers+0x115/0x120
> >> [   39.944580]  [] console_unlock+0x333/0x5c0
> >> [   39.944583]  [] register_console+0x1c4/0x380
> >> [   39.944586]  [] init_netconsole+0x1c5/0x1000 
> >> [netconsole]
> >> [   39.944588]  [] ? 0xa004f000
> >> [   39.944591]  [] do_one_initcall+0x3d/0x150
> >> [   39.944592]  [] ? __might_sleep+0x4a/0x80
> >> [   39.944596]  [] ? kmem_cache_alloc_trace+0x188/0x1e0
> >> [   39.944598]  [] do_init_module+0x5f/0x1d8
> >> [   39.944602]  [] load_module+0x1429/0x1b40
> >> [   39.944604]  [] ? __symbol_put+0x40/0x40
> >> [   39.944607]  [] ? kernel_read_file+0x178/0x1a0
> >> [   39.944608]  [] ? kernel_read_file_from_fd+0x49/0x80
> >> [   39.944611]  [] SYSC_finit_module+0xc3/0xf0
> >> [   39.944614]  [] SyS_finit_module+0xe/0x10
> >> [   39.944617]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
> >> [   39.946384] console [netcon0] enabled
> >> [   39.946514] netconsole: network logging started
> >>
> >> Can this be possibly fixed?
> >
> >Could you try this ?
> >
> >diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
> >b/drivers/net/ethernet/intel/e1000/e1000_main.c
> >index 
> >f42129d09e2c23ba9fdb5cde890d50ecb7166a42..a53c41c4c4f7d1fe52f95a2cab8784a938b3820b
> > 100644
> >--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
> >+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
> >@@ -5257,9 +5257,13 @@ static void e1000_netpoll(struct net_device *netdev)
> > {
> > struct e1000_adapter *adapter = netdev_priv(netdev);
> >
> >-disable_irq(adapter->pdev->irq);
> >-e1000_intr(adapter->pdev->irq, netdev);
> >-enable_irq(adapter->pdev->irq);
> >+if (napi_schedule_prep(>napi)) {
> >+adapter->total_tx_bytes = 0;
> >+adapter->total_tx_packets = 0;
> >+adapter->total_rx_bytes = 0;
> >+adapter->total_rx_packets = 0;
> >+__napi_schedule(>napi);
> >+}
> 
> The machines are actually running e1000e driver, so I copied your
> approach to e1000e and it works:
> 
> kern  :info  : [   16.109647] netpoll: netconsole: local port 6665
> kern  :info  : [   16.109961] netpoll: netconsole: local IPv4 address 0.0.0.0
> kern  :info  : [   16.110346] netpoll: netconsole: interface 'eth0'
> kern  :info  : [   16.110672] netpoll: netconsole: remote port 6676
> kern  :info  : [   16.110991] netpoll: netconsole: remote IPv4 address 
> 192.168.2.1
> kern  :info  : [   16.111398] netpoll: netconsole: remote ethernet address 
> ff:ff:ff:ff:ff:ff
> kern  :info  : [   16.111845] netpoll: netconsole: local IP 192.168.2.3
> kern  

[PATCH net-next 0/3] virtio: style cleanups

[Stephen Hemminger]

[PATCH net-next 1/3] virtio: whitespace cleanups

[Stephen Hemminger]

Adjust whitespace to match current favored style.

Signed-off-by: Stephen Hemminger 

--- a/drivers/net/virtio_net.c  2016-07-20 08:12:24.035656119 -0700
+++ b/drivers/net/virtio_net.c  2016-07-26 09:11:06.988788668 -0700
@@ -201,7 +201,9 @@ static void give_pages(struct receive_qu
struct page *end;
 
/* Find end of list, sew whole thing into vi->rq.pages. */
-   for (end = page; end->private; end = (struct page *)end->private);
+   for (end = page; end->private; end = (struct page *)end->private)
+   continue;
+
end->private = (unsigned long)rq->pages;
rq->pages = page;
 }
@@ -233,13 +235,13 @@ static void skb_xmit_done(struct virtque
 static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
 {
unsigned int truesize = mrg_ctx & (MERGEABLE_BUFFER_ALIGN - 1);
+
return (truesize + 1) * MERGEABLE_BUFFER_ALIGN;
 }
 
 static void *mergeable_ctx_to_buf_address(unsigned long mrg_ctx)
 {
return (void *)(mrg_ctx & -MERGEABLE_BUFFER_ALIGN);
-
 }
 
 static unsigned long mergeable_buf_to_ctx(void *buf, unsigned int truesize)
@@ -310,6 +312,7 @@ static struct sk_buff *page_to_skb(struc
BUG_ON(offset >= PAGE_SIZE);
while (len) {
unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len);
+
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset,
frag_size, truesize);
len -= frag_size;
@@ -323,9 +326,10 @@ static struct sk_buff *page_to_skb(struc
return skb;
 }
 
-static struct sk_buff *receive_small(struct virtnet_info *vi, void *buf, 
unsigned int len)
+static struct sk_buff *receive_small(struct virtnet_info *vi,
+void *buf, unsigned int len)
 {
-   struct sk_buff * skb = buf;
+   struct sk_buff *skb = buf;
 
len -= vi->hdr_len;
skb_trim(skb, len);
@@ -455,6 +459,7 @@ static void receive_buf(struct virtnet_i
if (vi->mergeable_rx_bufs) {
unsigned long ctx = (unsigned long)buf;
void *base = mergeable_ctx_to_buf_address(ctx);
+
put_page(virt_to_head_page(base));
} else if (vi->big_packets) {
give_pages(rq, buf);
@@ -699,7 +704,7 @@ static void refill_work(struct work_stru
 * we will *never* try to fill again.
 */
if (still_empty)
-   schedule_delayed_work(>refill, HZ/2);
+   schedule_delayed_work(>refill, HZ / 2);
}
 }
 
@@ -901,12 +906,12 @@ static netdev_tx_t start_xmit(struct sk_
 * Since most packets only take 1 or 2 ring slots, stopping the queue
 * early means 16 slots are typically wasted.
 */
-   if (sq->vq->num_free < 2+MAX_SKB_FRAGS) {
+   if (sq->vq->num_free < 2 + MAX_SKB_FRAGS) {
netif_stop_subqueue(dev, qnum);
if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) {
/* More just got used, free them then recheck. */
free_old_xmit_skbs(sq);
-   if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
+   if (sq->vq->num_free >= 2 + MAX_SKB_FRAGS) {
netif_start_subqueue(dev, qnum);
virtqueue_disable_cb(sq->vq);
}
@@ -1238,11 +1243,11 @@ static void virtnet_set_affinity(struct
 }
 
 static int virtnet_cpu_callback(struct notifier_block *nfb,
-   unsigned long action, void *hcpu)
+   unsigned long action, void *hcpu)
 {
struct virtnet_info *vi = container_of(nfb, struct virtnet_info, nb);
 
-   switch(action & ~CPU_TASKS_FROZEN) {
+   switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
case CPU_DOWN_FAILED:
case CPU_DEAD:
@@ -1259,7 +1264,7 @@ static int virtnet_cpu_callback(struct n
 }
 
 static void virtnet_get_ringparam(struct net_device *dev,
-   struct ethtool_ringparam *ring)
+ struct ethtool_ringparam *ring)
 {
struct virtnet_info *vi = netdev_priv(dev);
 
@@ -1269,7 +1274,6 @@ static void virtnet_get_ringparam(struct
ring->tx_pending = ring->tx_max_pending;
 }
 
-
 static void virtnet_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *info)
 {
@@ -1279,7 +1283,6 @@ static void virtnet_get_drvinfo(struct n
strlcpy(info->driver, KBUILD_MODNAME, sizeof(info->driver));
strlcpy(info->version, VIRTNET_DRIVER_VERSION, sizeof(info->version));
strlcpy(info->bus_info, virtio_bus_name(vdev), sizeof(info->bus_info));
-
 }
 
 /* TODO: Eliminate OOO packets during switching */
@@ -1402,9 +1405,9 @@ static int virtnet_change_mtu(struct net
 }
 
 static 

[PATCH net-next 2/3] virtio: cleanup sizeof usage

[Stephen Hemminger]

Although sizeof is an operator in C. Preferred usage is to use
it as a function.

Signed-off-by: Stephen Hemminger 

--- a/drivers/net/virtio_net.c  2016-07-26 09:13:16.173384238 -0700
+++ b/drivers/net/virtio_net.c  2016-07-26 09:13:16.169384220 -0700
@@ -272,7 +272,7 @@ static struct sk_buff *page_to_skb(struc
 
hdr_len = vi->hdr_len;
if (vi->mergeable_rx_bufs)
-   hdr_padded_len = sizeof *hdr;
+   hdr_padded_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
else
hdr_padded_len = sizeof(struct padded_vnet_hdr);
 

[PATCH net-next 3/3] virtio: use kcalloc and kmalloc_array

[Stephen Hemminger]

Preferred style is to use kcalloc and kmalloc_array.

Signed-off-by: Stephen Hemminger 

--- a/drivers/net/virtio_net.c  2016-07-26 09:13:19.805400983 -0700
+++ b/drivers/net/virtio_net.c  2016-07-26 09:13:19.801400965 -0700
@@ -1551,13 +1551,13 @@ static int virtnet_find_vqs(struct virtn
virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ);
 
/* Allocate space for find_vqs parameters */
-   vqs = kzalloc(total_vqs * sizeof(*vqs), GFP_KERNEL);
+   vqs = kzalloc(total_vqs, sizeof(*vqs), GFP_KERNEL);
if (!vqs)
goto err_vq;
-   callbacks = kmalloc(total_vqs * sizeof(*callbacks), GFP_KERNEL);
+   callbacks = kmalloc_array(total_vqs, sizeof(*callbacks), GFP_KERNEL);
if (!callbacks)
goto err_callback;
-   names = kmalloc(total_vqs * sizeof(*names), GFP_KERNEL);
+   names = kmalloc_array(total_vqs, sizeof(*names), GFP_KERNEL);
if (!names)
goto err_names;
 
@@ -1613,10 +1613,10 @@ static int virtnet_alloc_queues(struct v
 {
int i;
 
-   vi->sq = kzalloc(sizeof(*vi->sq) * vi->max_queue_pairs, GFP_KERNEL);
+   vi->sq = kcalloc(vi->max_queue_pairs, sizeof(*vi->sq), GFP_KERNEL);
if (!vi->sq)
goto err_sq;
-   vi->rq = kzalloc(sizeof(*vi->rq) * vi->max_queue_pairs, GFP_KERNEL);
+   vi->rq = kcalloc(vi->max_queue_pairs, sizeof(*vi->rq), GFP_KERNEL);
if (!vi->rq)
goto err_rq;
 

Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

[Tom Herbert]

On Tue, Jul 26, 2016 at 6:31 AM, Thomas Monjalon
 wrote:
> Hi,
>
> About RX filtering, there is an ongoing effort in DPDK to write an API
> which could leverage most of the hardware capabilities of any NICs:
> https://rawgit.com/6WIND/rte_flow/master/rte_flow.html
> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/43352
> I understand that XDP does not target to support every hardware features,
> though it may be an interesting approach to check.
>
Thomas,

A major goal of XDP is to leverage and in fact encourage innovation in
hardware features. But, we are asking that vendors design the APIs
with the community in mind. For instance, if XDP supports crypto
offload it should have one API that different companies, we don't want
every vendor coming up with their own.

> 2016-07-12 22:32, Jesper Dangaard Brouer via iovisor-dev:
>> On Tue, 12 Jul 2016 12:13:01 -0700
>> John Fastabend  wrote:
>> >
>> > Another use case I have is to make a really high performance AF_PACKET
>> > interface. So if there was a way to say bind a queue to an AF_PACKET
>> > ring and run a policy XDP program before hitting the AF_PACKET
>> > descriptor bit that would be really interesting because it would solve
>> > some of my need for poll mode drivers in userspace.
>
> Have you started this work?
> Do you have an idea of how RX would perform through XDP + AF_PACKET + DPDK?
>
I don't understand why the AF_PACKET with DPDK. They should be
mutually exclusive. XDP over DPDK does make sense.

Tom

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[Grygorii Strashko]

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:
> 
> 
> On 22.07.16 16:58, Grygorii Strashko wrote:
>> Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
>> cpsw module removal:
>>  cpsw_remove()
>>  - cpdma_ctlr_destroy()
>>- spin_lock_irqsave(>lock, flags)
>>- cpdma_ctlr_stop()
>>  - spin_lock_irqsave(>lock, flags); <- deadlock
>>- cpdma_chan_destroy()
>>  - spin_lock_irqsave(>lock, flags); <- deadlock
>>
>> The issue has not been observed before because CPDMA channels have
>> been destroyed manually by CPSW until commit d941ebe88a41 ("net:
>> ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.
>>
>> Signed-off-by: Grygorii Strashko 
>> ---
>>  drivers/net/ethernet/ti/davinci_cpdma.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
>> b/drivers/net/ethernet/ti/davinci_cpdma.c
>> index a68652a..89242e9 100644
>> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
>> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
>> @@ -436,7 +436,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
>>  if (!ctlr)
>>  return -EINVAL;
>>
>> -spin_lock_irqsave(>lock, flags);
> Should ctlr->state be checked under lock?
> Seems like here should be used unlocked static versions of
> cpdma_ctlr_stop() and cpdma_chan_destroy() instead.

As per my understanding it's not expected the ctlr->state will be changed at 
this 
moment as all net devices has been unregistered already.

> 
>>  if (ctlr->state != CPDMA_STATE_IDLE)

May be I can move above check in cpdma_ctlr_stop() instead.
What do you think?

>>  cpdma_ctlr_stop(ctlr);
>>
>> @@ -444,7 +443,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
>>  cpdma_chan_destroy(ctlr->channels[i]);
>>
>>  cpdma_desc_pool_destroy(ctlr->pool);
>> -spin_unlock_irqrestore(>lock, flags);
>>  return ret;
>>  }
>>  EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);
>>
> 


-- 
regards,
-grygorii

patch for PCH_GBE rotten packet (Intel EG20T Platform Controller).

[Tom Walsh]

Not sure how this goes, but, we found a race condition in
drivers/net/ethernet/oki-semi/pch_gbe/

The attached patch corrects for this.

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net
"Windows? No thanks, I have work to do..."



0004-oki-PCH_GBE-rotten_packet.patch
Description: Binary data

Re: [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

[Fengguang Wu]

Hi Eric,

It works!

On Tue, Jul 26, 2016 at 11:14:52AM +0200, Eric Dumazet wrote:

On Tue, 2016-07-26 at 11:50 +0800, Fengguang Wu wrote:

Greetings,

This BUG message can be found in recent kernels as well as v4.4 and
linux-stable. It happens when running

modprobe netconsole netconsole=@/,$port@$server/

[   39.937534] 22 Jul 13:30:40 ntpdate[440]: step time server 192.168.1.1 
offset -673.833841 sec
[   39.943285] netpoll: netconsole: local port 6665
[   39.943436] netpoll: netconsole: local IPv4 address 0.0.0.0
[   39.943609] netpoll: netconsole: interface 'eth0'
[   39.943756] netpoll: netconsole: remote port 6672
[   39.943913] netpoll: netconsole: remote IPv4 address 192.168.1.1
[   39.944099] netpoll: netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
[   39.944311] netpoll: netconsole: local IP 192.168.1.193
[   39.944514] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:110
[   39.944515] in_atomic(): 1, irqs_disabled(): 1, pid: 448, name: modprobe
[   39.944517] CPU: 6 PID: 448 Comm: modprobe Not tainted 
4.7.0-rc7-wt-ath-10122-gf9b5ec2 #102
[   39.944518] Hardware name:  /DZ77BH-55K, BIOS 
BHZ7710H.86A.0097.2012.1228.1346 12/28/2012
[   39.944522]   c90001f2f9e8 813417d9 
88007faba5c0
[   39.944524]  006e c90001f2fa00 810aec03 
81a25948
[   39.944525]  c90001f2fa28 810aec9a 8803e5bd9400 
8803e50fbd68
[   39.944526] Call Trace:
[   39.944533]  [] dump_stack+0x63/0x8a
[   39.944536]  [] ___might_sleep+0xd3/0x120
[   39.944537]  [] __might_sleep+0x4a/0x80
[   39.944541]  [] synchronize_irq+0x38/0xa0
[   39.944543]  [] ? __irq_put_desc_unlock+0x1e/0x40
[   39.944545]  [] ? __disable_irq_nosync+0x43/0x60
[   39.944547]  [] disable_irq+0x1c/0x20
[   39.944559]  [] e1000_netpoll+0xf2/0x120 [e1000e]
[   39.944563]  [] netpoll_poll_dev+0x5c/0x1a0
[   39.944567]  [] ? __kmalloc_reserve+0x31/0x90
[   39.944569]  [] netpoll_send_skb_on_dev+0x16b/0x250
[   39.944572]  [] netpoll_send_udp+0x2ec/0x450
[   39.944576]  [] write_msg+0xb2/0xf0 [netconsole]
[   39.944578]  [] call_console_drivers+0x115/0x120
[   39.944580]  [] console_unlock+0x333/0x5c0
[   39.944583]  [] register_console+0x1c4/0x380
[   39.944586]  [] init_netconsole+0x1c5/0x1000 [netconsole]
[   39.944588]  [] ? 0xa004f000
[   39.944591]  [] do_one_initcall+0x3d/0x150
[   39.944592]  [] ? __might_sleep+0x4a/0x80
[   39.944596]  [] ? kmem_cache_alloc_trace+0x188/0x1e0
[   39.944598]  [] do_init_module+0x5f/0x1d8
[   39.944602]  [] load_module+0x1429/0x1b40
[   39.944604]  [] ? __symbol_put+0x40/0x40
[   39.944607]  [] ? kernel_read_file+0x178/0x1a0
[   39.944608]  [] ? kernel_read_file_from_fd+0x49/0x80
[   39.944611]  [] SYSC_finit_module+0xc3/0xf0
[   39.944614]  [] SyS_finit_module+0xe/0x10
[   39.944617]  [] entry_SYSCALL_64_fastpath+0x1a/0xa9
[   39.946384] console [netcon0] enabled
[   39.946514] netconsole: network logging started

Can this be possibly fixed?


Could you try this ?

diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c 
b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 
f42129d09e2c23ba9fdb5cde890d50ecb7166a42..a53c41c4c4f7d1fe52f95a2cab8784a938b3820b
 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -5257,9 +5257,13 @@ static void e1000_netpoll(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);

-   disable_irq(adapter->pdev->irq);
-   e1000_intr(adapter->pdev->irq, netdev);
-   enable_irq(adapter->pdev->irq);
+   if (napi_schedule_prep(>napi)) {
+   adapter->total_tx_bytes = 0;
+   adapter->total_tx_packets = 0;
+   adapter->total_rx_bytes = 0;
+   adapter->total_rx_packets = 0;
+   __napi_schedule(>napi);
+   }


The machines are actually running e1000e driver, so I copied your
approach to e1000e and it works:

kern  :info  : [   16.109647] netpoll: netconsole: local port 6665
kern  :info  : [   16.109961] netpoll: netconsole: local IPv4 address 0.0.0.0
kern  :info  : [   16.110346] netpoll: netconsole: interface 'eth0'
kern  :info  : [   16.110672] netpoll: netconsole: remote port 6676
kern  :info  : [   16.110991] netpoll: netconsole: remote IPv4 address 
192.168.2.1
kern  :info  : [   16.111398] netpoll: netconsole: remote ethernet address 
ff:ff:ff:ff:ff:ff
kern  :info  : [   16.111845] netpoll: netconsole: local IP 192.168.2.3
kern  :info  : [   16.114284] console [netcon0] enabled
kern  :info  : [   16.114550] netconsole: network logging started

However I'm not sure if it'll have side effects, because this
effectively disables the various checks in e1000_intr() and
e1000_intr_msi().

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 9b4ec13..4f89873 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ 

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Eric W. Biederman]

"Michael Kerrisk (man-pages)"  writes:

> Hello Eric,
>
> On 07/21/2016 06:39 PM, Eric W. Biederman wrote:
>>
>> This patchset addresses two use cases:
>> - Implement a sane upper bound on the number of namespaces.
>> - Provide a way for sandboxes to limit the attack surface from
>>   namespaces.
>>
>> The maximum sane case I can imagine is if every process is a fat
>> process, so I set the maximum number of namespaces to the maximum
>> number of threads.
>>
>> I make these limits recursive and per user namespace so that a
>> usernamespace root can reduce the limits further.  If a user namespace
>> root raises the limit the limit in the parent namespace will be honored.
>>
>> I have cut this implementation to the bare minimum needed to achieve
>> these objectives.
>>
>> Does anyone know if there is a proper error code to return for resource
>> limit exceeded?  I am currently using -EUSERS or -ENFILE but both of
>> those feel a little wrong.
>
> ENFILE certainly seems weird. I suppose my first question is: why two
> different errors?

EUSERS was there in the user namespace case for this condition (well
nesting depth but same principle) so it made sense to start with.  But
too many users doesn't really make sense.

ENFILE is actually slightly less insane.  It actually is about hitting a
resource limit, and seemed the most generic catchall we had.

> Some alternatives you might want to consider: E2BIG, EOVERFLOW,
> or (maybe) ERANGE.

My problem with those is typically those are about the values in fields,
not about creating too many things.  So those really don't feel right.
EACCESS or EPERM might be better but those are very very generic.

I really want ETOOMANY or something like that.

I am actually surprised given how common this pattern is, and the fact that
rlimits have existed forever, that we don't have a resource limit
exceeded error code.  I suppose it might be worth looking at Posix to
see if they have any suggestions.  Perhaps it may even be time to add an
appropriate error code to the list.

Not the most important thing out of this patch series but something
worth looking at.

Eric

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

[Eric W. Biederman]

"Michael Kerrisk (man-pages)"  writes:

> Hello Eric,
>
> I realized I had a question after the last mail.
>
> On 07/21/2016 06:39 PM, Eric W. Biederman wrote:
>>
>> This patchset addresses two use cases:
>> - Implement a sane upper bound on the number of namespaces.
>> - Provide a way for sandboxes to limit the attack surface from
>>   namespaces.
>
> Can you say more about the second point? What exactly is the
> problem that is being addressed, and how does the patch series
> address it? (It would be good to have those details in the
> revised commit message...)

At some point it was reported that seccomp was not sufficient to disable
namespace creation.  I need to go back and look at that claim to see
which set of circumstances that was referring to.  Seccomp doesn't stack
so I can see why it is an issue.

The general problem is that namespaces by their nature (and especially
in combination with the user namespaces) allow unprivileged users to use
more of the kernel than a user would have access to without them.  This
in turn allows malicious users more kernel calls they can use in attempt
to find an exploitable bug.

So if you are building a sandbox/chroot jail/chromium tab or anything
like that and you know you won't be needing a kernel feature having an
easy way to disable the feature is useful for making the kernel
marginally more secure, as certain attack vectors are no longer
possible.

Eric

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

[Appana Durga Kedareswara Rao]

Hi Andrew,

Thanks for the inputs...

> >
> > > > Hi Kedareswara
> > > >
> > > > So looking at the device tree, you have the gmiitorgmii as an mdio
> > > > device. It will get probed as an mdio device, and from that you
> > > > know the address on the bus. However, your driver does not
> > > > actually do this. xilinx_gmii2rgmii.c is just a library of two
> > > > functions, and does not use any of this device tree information.
> > > > You device tree binding is completely bogus.
> > > >
> > > > What i think is a much more logical structure, and fits the
> > > > hardware, which is what DT is all about, is to make your driver an mdio
> driver.
> > > > Also, have a phy-handle pointing to the PHY in the gmii_to_rgmii node.
> > > > You then no longer need the exported gmii2rgmii_phyprobe() function.
> > > >
> > > > Next, you want gmiitorgmii driver to register a phy. The MAC
> > > > driver can then look this up using phy-handle:
> > > >
> > > >mdio {
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > >
> > > > phy: ethernet-phy@0 {
> > > > reg = <0>;
> > > > };
> > > >
> > > > gmii_to_rgmii: gmii-to-rgmii@8 {
> > > > compatible = "xlnx,gmiitorgmii";
> > > > reg = <8>;
> > > > phy-handle = <>;
> > > > };
> > > >};
> > >
> > >
> > > Thanks for your inputs initially we too thought the similar
> > > implementation But the GMII2RGMII converter contains only one
> > > register and it is  not compatible to the standard ethernet MII
> > > interface. Also it doesn't have a standard VID and PID registers So,
> > > during the mdio bus scan, this device
> > will
> > > not appear.

I tried to implement the driver as you suggested but there are few limitations 
in this
Implementation please correct me if my understanding is wrong...

The device-tree will look like below...
mdio {
#address-cells = <1>;
 #size-cells = <0>;
 phy: ethernet-phy@0 {
 reg = <0>;
 };
 gmii_to_rgmii: gmii-to-rgmii@8 {
 compatible = "xlnx,gmiitorgmii";
 reg = <8>;
phy-handle = <>;
 };
  };

The MAC driver does the below.
---> It creates a MDIO device for the gmii_to_rgmii node.
---> It creates a PHY device for the External PHY node.

The GMII2RGMII driver does the below.
1) It registers the gmii_to_rgmii node as a MDIO driver.
It contains the external phy as a phy-handle
2) Register a PHY Driver.
---> Register it as a phy driver (phy_register_driver): 
For this implementation the converter won't have any VID or 
DID(PHY register 2 and 3)  
---> Register phy using of_phy_connect call: 
   For this implementation needed a netdev pointer to pass it to 
the of_phy_connect call.
  (Need to allocate a network device during probe and need to 
register it as netdev) 

For the 2nd one implement I am facing above limitations...
Please correct me if my understanding is wrong...

Regards,
Kedar.

[PATCH -next] i40e: Use list_move instead of list_del/list_add

[Wei Yongjun]

Using list_move() instead of list_del() + list_add().

Signed-off-by: Wei Yongjun 
---
 drivers/net/ethernet/intel/i40e/i40e_client.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_client.c 
b/drivers/net/ethernet/intel/i40e/i40e_client.c
index e1370c5..e6b9263 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_client.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_client.c
@@ -662,8 +662,7 @@ static int i40e_client_release(struct i40e_client *client)
 client->name, pf->hw.pf_id);
}
/* delete the client instance from the list */
-   list_del(>list);
-   list_add(>list, _tmp);
+   list_move(>list, _tmp);
atomic_dec(>ref_cnt);
dev_info(>pdev->dev, "Deleted client instance of Client 
%s\n",
 client->name);

Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

[Grygorii Strashko]

On 07/26/2016 03:02 PM, Uwe Kleine-König wrote:

Hello,

these patches are based on next-20160726. I didn't check yet how latency
improves by using these patches, but even if the improvment is small,
it's still a good idea to have them.


Sry, but how this will affect on -RT? This is not a raw locks, so
they will be converted to rt-mutexes which are sleepable.
Or I've missed smth?



A second pair of eyes checking what I did would be great.

Best regards
Uwe


Uwe Kleine-König (2):
  net: davinci_cpdma: reduce time holding ctlr->lock in
cpdma_control_set
  net: davinci_cpdma: reduce time holding chan->lock in
cpdma_chan_submit

 drivers/net/ethernet/ti/davinci_cpdma.c | 58 -
 1 file changed, 29 insertions(+), 29 deletions(-)




--
regards,
-grygorii

[PATCH v2 1/1] Add timer to handle OOM situations

[ggarcia]

From: Gerard Garcia 

v2:
* Use of ERR_PTR/PTR_ERR/IS_ERR
* Timer cleaned on device release.
* Do not process more packets on error.

Signed-off-by: Gerard Garcia 
---
 drivers/vhost/vsock.c | 55 +--
 1 file changed, 45 insertions(+), 10 deletions(-)

diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 17bfe4e..5c6879d 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -14,11 +14,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "vhost.h"
 
 #define VHOST_VSOCK_DEFAULT_HOST_CID   2
+#define OOM_RETRY_MS   100
 
 enum {
VHOST_VSOCK_FEATURES = VHOST_FEATURES,
@@ -43,8 +45,12 @@ struct vhost_vsock {
u32 total_tx_buf;
 
u32 guest_cid;
+
+   struct timer_list tx_kick;
 };
 
+
+
 static u32 vhost_transport_get_local_cid(void)
 {
return VHOST_VSOCK_DEFAULT_HOST_CID;
@@ -282,12 +288,13 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
 
if (in != 0) {
vq_err(vq, "Expected 0 input buffers, got %u\n", in);
-   return NULL;
+   return ERR_PTR(-EINVAL);
}
 
pkt = kzalloc(sizeof(*pkt), GFP_KERNEL);
-   if (!pkt)
-   return NULL;
+   if (!pkt){
+   return ERR_PTR(-ENOMEM);
+   }
 
len = iov_length(vq->iov, out);
iov_iter_init(_iter, WRITE, vq->iov, out, len);
@@ -297,7 +304,7 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
vq_err(vq, "Expected %zu bytes for pkt->hdr, got %zu bytes\n",
   sizeof(pkt->hdr), nbytes);
kfree(pkt);
-   return NULL;
+   return ERR_PTR(-EINVAL);
}
 
if (le16_to_cpu(pkt->hdr.type) == VIRTIO_VSOCK_TYPE_STREAM)
@@ -310,13 +317,13 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
/* The pkt is too big */
if (pkt->len > VIRTIO_VSOCK_MAX_PKT_BUF_SIZE) {
kfree(pkt);
-   return NULL;
+   return ERR_PTR(-EINVAL);
}
 
pkt->buf = kmalloc(pkt->len, GFP_KERNEL);
if (!pkt->buf) {
kfree(pkt);
-   return NULL;
+   return ERR_PTR(-EINVAL);
}
 
nbytes = copy_from_iter(pkt->buf, pkt->len, _iter);
@@ -324,7 +331,7 @@ vhost_vsock_alloc_pkt(struct vhost_virtqueue *vq,
vq_err(vq, "Expected %u byte payload, got %zu bytes\n",
   pkt->len, nbytes);
virtio_transport_free_pkt(pkt);
-   return NULL;
+   return ERR_PTR(-EINVAL);
}
 
return pkt;
@@ -362,9 +369,26 @@ static void vhost_vsock_handle_tx_kick(struct vhost_work 
*work)
}
 
pkt = vhost_vsock_alloc_pkt(vq, out, in);
-   if (!pkt) {
-   vq_err(vq, "Faulted on pkt\n");
-   continue;
+
+   if (IS_ERR(pkt)) {
+   if (PTR_ERR(pkt) == -ENOMEM) {
+   vhost_discard_vq_desc(vq, 1);
+
+   if (!timer_pending(>tx_kick)) {
+   vsock->tx_kick.data =
+   (unsigned long) vq;
+   vsock->tx_kick.expires =
+   jiffies + 
msecs_to_jiffies(OOM_RETRY_MS);
+   add_timer(>tx_kick);
+   }
+
+   break;
+   } else {
+   vq_err(vq, "Faulted on pkt\n");
+   break;
+   }
+   } else if (unlikely(timer_pending(>tx_kick))) {
+   del_timer(>tx_kick);
}
 
/* Only accept correctly addressed packets */
@@ -383,6 +407,13 @@ out:
mutex_unlock(>mutex);
 }
 
+static void vhost_vsock_rehandle_tx_kick(unsigned long data)
+{
+   struct vhost_virtqueue *vq = (struct vhost_virtqueue *) data;
+
+   vhost_poll_queue(>poll);
+}
+
 static void vhost_vsock_handle_rx_kick(struct vhost_work *work)
 {
struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
@@ -493,6 +524,9 @@ static int vhost_vsock_dev_open(struct inode *inode, struct 
file *file)
goto out;
}
 
+   setup_timer(>tx_kick,
+   vhost_vsock_rehandle_tx_kick, (unsigned long) NULL);
+
vqs[VSOCK_VQ_TX] = >vqs[VSOCK_VQ_TX];
vqs[VSOCK_VQ_RX] = >vqs[VSOCK_VQ_RX];
vsock->vqs[VSOCK_VQ_TX].handle_kick = vhost_vsock_handle_tx_kick;
@@ -555,6 +589,7 @@ static int vhost_vsock_dev_release(struct inode *inode, 
struct file *file)
vhost_dev_stop(>dev);
vhost_dev_cleanup(>dev, false);
kfree(vsock->dev.vqs);
+   del_timer(>tx_kick);

[PATCH v2 0/1] virtio-vsock: Add timer to handle OOM situations

[ggarcia]

From: Gerard Garcia 

This patch applies over the stefanha/vsock-next repository:
https://github.com/stefanha/linux/tree/vsock-next

Once the guest puts a packet in the virtqueue it is guaranteed
that it will be delivered. 

This patch addresses the problem of packets being discarded when 
there is not available memory in the host.

v2:
* Use of ERR_PTR/PTR_ERR/IS_ERR
* Timer cleaned on device release.
* Do not process more packets on error.

Gerard Garcia (1):
  Add timer to handle OOM situations

 drivers/vhost/vsock.c | 55 +--
 1 file changed, 45 insertions(+), 10 deletions(-)

-- 
2.9.1

Re: [PATCH v2] net: davinci_cpdma: remove excessive dump of register values to kernel log

[Grygorii Strashko]

+ CC: Ivan

On 07/26/2016 05:09 PM, Grygorii Strashko wrote:

On 07/26/2016 03:57 AM, David Miller wrote:

From: Uwe Kleine-König 
Date: Mon, 25 Jul 2016 11:54:45 +0200


Such a big dump of register values is hardly useful on a production
system.

Another downside of the now removed functions is that calling
emac_dump_regs resulted in at least 87 calls to dev_info while holding a
spinlock and having irqs off which is a big source of latency.

Signed-off-by: Uwe Kleine-König 


Applied.



:( To be honest I was really enjoyed using cpdma_ctlr_dump()
for debug purposed during the past few weeks in cpsw where I've added
calls to this func manually. And I even thinking about adding debug_fs
entry for the same :(

Pretty fast merge :(





--
regards,
-grygorii

Re: [PATCH 2/2] net: davinci_cpdma: reduce time holding chan->lock in cpdma_chan_submit

[Grygorii Strashko]

On 07/26/2016 03:02 PM, Uwe Kleine-König wrote:
> Allocating and preparing a dma descriptor doesn't need to happen under
> the channel's lock. So do this before taking the channel's lock. The only
> down side is that the dma descriptor might be allocated even though the
> channel is about to be stopped. This is unlikely though.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/net/ethernet/ti/davinci_cpdma.c | 38 
> +
>  1 file changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
> b/drivers/net/ethernet/ti/davinci_cpdma.c
> index 5ffa04a306c6..ba3462707ae3 100644
> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
> @@ -542,24 +542,10 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void 
> *token, void *data,
>   u32 mode;
>   int ret = 0;
>  
> - spin_lock_irqsave(>lock, flags);
> -
> - if (chan->state == CPDMA_STATE_TEARDOWN) {
> - ret = -EINVAL;
> - goto unlock_ret;
> - }
> -
> - if (chan->count >= chan->desc_num)  {
> - chan->stats.desc_alloc_fail++;
> - ret = -ENOMEM;
> - goto unlock_ret;
> - }

I'm not sure this is right thing to do. This check is expected to be strict
and means "channel has exhausted the available descriptors, so further descs 
allocation does not allowed".


This also might affect on Ivan's work [1] "[PATCH 0/4]  net: ethernet: ti: 
cpsw: add multi-queue support"



[1] https://lkml.org/lkml/2016/6/30/603
-- 
regards,
-grygorii

Re: [iproute PATCH 3/4] tc: use action_a2n() everywhere

[Jamal Hadi Salim]

On 16-07-23 07:28 AM, Phil Sutter wrote:

Signed-off-by: Phil Sutter 


Thanks for the nice work Phil.
Acked-by: Jamal Hadi Salim 

cheers,
jamal

Re: [iproute PATCH 2/4] tc: util: bore up action_a2n()

[Jamal Hadi Salim]

On 16-07-23 07:28 AM, Phil Sutter wrote:

It's a pitty this function is used nowhere, so let's polish it for use:

* Loop over branch names, makes it clear that every former conditional
  was exactly identical.
* Support 'pipe' branch name, too.
* Make number parsing optional.

Signed-off-by: Phil Sutter 


Acked-by: Jamal Hadi Salim 

cheers,
jamal

Re: [PATCH v2] net: davinci_cpdma: remove excessive dump of register values to kernel log

[Grygorii Strashko]

On 07/26/2016 03:57 AM, David Miller wrote:

From: Uwe Kleine-König 
Date: Mon, 25 Jul 2016 11:54:45 +0200


Such a big dump of register values is hardly useful on a production
system.

Another downside of the now removed functions is that calling
emac_dump_regs resulted in at least 87 calls to dev_info while holding a
spinlock and having irqs off which is a big source of latency.

Signed-off-by: Uwe Kleine-König 


Applied.



:( To be honest I was really enjoyed using cpdma_ctlr_dump()
for debug purposed during the past few weeks in cpsw where I've added 
calls to this func manually. And I even thinking about adding debug_fs 
entry for the same :(


Pretty fast merge :(


--
regards,
-grygorii

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Christian Lamparter]

On Tuesday, July 26, 2016 4:57:03 AM CEST Alan Curry wrote:
> Al Viro wrote:
> > On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote:
> > 
> > > > The symptom is that downloaded files (http, ftp, and probably other
> > > > protocols) have small corrupted segments (about 1-2 kilobytes long) in
> > > > random locations. Only downloads that sustain a high speed for at least 
> > > > a
> > > > few seconds are corrupted. Anything small enough to be received in less
> > > > than about 5 seconds is not affected.
> > 
> > Can that sucker be reproduced with netcat?  That would eliminate all issues
> > with multi-iovec recvmsg(2), narrowing the things down quite bit.
> 
> netcat seems to be immune. Comparing strace results, I didn't see any
> recvmsg() calls in the other programs that have had the problem, but there
> is an interesting difference: netcat calls select() to wait for the socket
> to be ready for reading, where my other test programs just call read() and
> let it block until ready.
> 
> So I wrote a small test program to isolate that difference. It downloads
> a file using only read() and write() and a hardcoded HTTP request. It has
> a select mode (main loop alternates read() and select() on the TCP socket)
> and a noselect mode (main loop just read()s the TCP socket).
> 
> The program is included at the bottom of this message.
> 
> I ran it several times in both modes and got corruption if and only if the
> noselect mode was used.
> 
> > 
> > Another thing (and if that works, it's *NOT* a proper fix - it would be
> > papering over the problem, but at least it would show where to look for
> > it) - try (on top of mainline) the following delta:
> > 
> > diff --git a/net/core/datagram.c b/net/core/datagram.c
> 
> Will try that patch soon. Meanwhile, here's my test:
> 
> /* Demonstration program "dlbug".
>Usage: dlbug select > outfile
>   or
>   dlbug noselect > outfile
>outfile will contain the full HTTP response. Edit out the HTTP headers
>and what's left should be a valid gzip if the download worked. */
> [...]
Thanks, I gave the program a try with my WNDA3100 and a WN821N v2 devices.
I did not see any corruptions in any of the tests though. Can you tell me
something about your wireless network too? I would like to know what router
and firmware are you using? Also important: what's your wireless configuration?
(WPA?, CCMP or TKIP? HT40, HT20 or Legacy rates? ...)

Probably the quickest and easiest way to get that information is by running
the following commands as root, when you are connected to your wifi network
and post the results:
# iw dev wlan0 link
# iw dev wlan0 scan dump

(You can of course remove your device's MACs, but please do it consistently).

Regards,
Christian

Re: [Patch net-next v2 1/2] net_sched: move tc_action into tcf_common

[Jamal Hadi Salim]

On 16-07-25 07:09 PM, Cong Wang wrote:

struct tc_action is confusing, currently we use it for two purposes:
1) Pass in arguments and carry out results from helper functions
2) A generic representation for tc actions

The first one is error-prone, since we need to make sure we don't
miss anything. This patch aims to get rid of this use, by moving
tc_action into tcf_common, so that they are allocated together
in hashtable and can be cast'ed easily.

And together with the following patch, we could really make
tc_action a generic representation for all tc actions and each
type of action can inherit from it.

Cc: Jamal Hadi Salim 
Signed-off-by: Cong Wang 



Cong - i need to stare at this longer than cursory
to give feedback. I apologize,
I am in travel mode but will get back to you.

cheers,
jamal

[PATCH net-next 1/3] qed*: Semantic changes

[Yuval Mintz]

Make semantic-only adjustments to qed* drivers, such as:
  - Changes in code indentation.
  - Usage of BIT() macro.
  - re-naming of variables.
  - Re-ordering of variable declerations.
  - Removal of (== 0) and (!= 0) in conditions.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_cxt.c |  47 ++---
 drivers/net/ethernet/qlogic/qed/qed_dev.c |  96 --
 drivers/net/ethernet/qlogic/qed/qed_hw.c  | 137 ++
 drivers/net/ethernet/qlogic/qed/qed_init_ops.c|  79 +++-
 drivers/net/ethernet/qlogic/qed/qed_int.c | 113 
 drivers/net/ethernet/qlogic/qed/qed_l2.c  | 210 ++
 drivers/net/ethernet/qlogic/qed/qed_main.c|  13 +-
 drivers/net/ethernet/qlogic/qed/qed_mcp.c |  67 +++
 drivers/net/ethernet/qlogic/qed/qed_sp_commands.c |  15 +-
 drivers/net/ethernet/qlogic/qed/qed_spq.c |  84 -
 drivers/net/ethernet/qlogic/qed/qed_sriov.c   |  56 +++---
 drivers/net/ethernet/qlogic/qede/qede_ethtool.c   |   6 +-
 drivers/net/ethernet/qlogic/qede/qede_main.c  | 121 +
 13 files changed, 404 insertions(+), 640 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c 
b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index 1c35f37..5476927 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -377,9 +377,8 @@ static void qed_cxt_set_proto_cid_count(struct qed_hwfn 
*p_hwfn,
}
 }
 
-u32 qed_cxt_get_proto_cid_count(struct qed_hwfn*p_hwfn,
-   enum protocol_type  type,
-   u32 *vf_cid)
+u32 qed_cxt_get_proto_cid_count(struct qed_hwfn *p_hwfn,
+   enum protocol_type type, u32 *vf_cid)
 {
if (vf_cid)
*vf_cid = p_hwfn->p_cxt_mngr->conn_cfg[type].cids_per_vf;
@@ -405,10 +404,10 @@ u32 qed_cxt_get_proto_tid_count(struct qed_hwfn *p_hwfn,
return cnt;
 }
 
-static void
-qed_cxt_set_proto_tid_count(struct qed_hwfn *p_hwfn,
-   enum protocol_type proto,
-   u8 seg, u8 seg_type, u32 count, bool has_fl)
+static void qed_cxt_set_proto_tid_count(struct qed_hwfn *p_hwfn,
+   enum protocol_type proto,
+   u8 seg,
+   u8 seg_type, u32 count, bool has_fl)
 {
struct qed_cxt_mngr *p_mngr = p_hwfn->p_cxt_mngr;
struct qed_tid_seg *p_seg = _mngr->conn_cfg[proto].tid_seg[seg];
@@ -420,8 +419,7 @@ qed_cxt_set_proto_tid_count(struct qed_hwfn *p_hwfn,
 
 static void qed_ilt_cli_blk_fill(struct qed_ilt_client_cfg *p_cli,
 struct qed_ilt_cli_blk *p_blk,
-u32 start_line, u32 total_size,
-u32 elem_size)
+u32 start_line, u32 total_size, u32 elem_size)
 {
u32 ilt_size = ILT_PAGE_IN_BYTES(p_cli->p_size.val);
 
@@ -448,8 +446,7 @@ static void qed_ilt_cli_adv_line(struct qed_hwfn *p_hwfn,
p_cli->first.val = *p_line;
 
p_cli->active = true;
-   *p_line += DIV_ROUND_UP(p_blk->total_size,
-   p_blk->real_size_in_page);
+   *p_line += DIV_ROUND_UP(p_blk->total_size, p_blk->real_size_in_page);
p_cli->last.val = *p_line - 1;
 
DP_VERBOSE(p_hwfn, QED_MSG_ILT,
@@ -926,12 +923,9 @@ static int qed_ilt_blk_alloc(struct qed_hwfn *p_hwfn,
void *p_virt;
u32 size;
 
-   size = min_t(u32, sz_left,
-p_blk->real_size_in_page);
+   size = min_t(u32, sz_left, p_blk->real_size_in_page);
p_virt = dma_alloc_coherent(_hwfn->cdev->pdev->dev,
-   size,
-   _phys,
-   GFP_KERNEL);
+   size, _phys, GFP_KERNEL);
if (!p_virt)
return -ENOMEM;
memset(p_virt, 0, size);
@@ -976,7 +970,7 @@ static int qed_ilt_shadow_alloc(struct qed_hwfn *p_hwfn)
for (j = 0; j < ILT_CLI_PF_BLOCKS; j++) {
p_blk = [i].pf_blks[j];
rc = qed_ilt_blk_alloc(p_hwfn, p_blk, i, 0);
-   if (rc != 0)
+   if (rc)
goto ilt_shadow_fail;
}
for (k = 0; k < p_mngr->vf_count; k++) {
@@ -985,7 +979,7 @@ static int qed_ilt_shadow_alloc(struct qed_hwfn *p_hwfn)
 
p_blk = [i].vf_blks[j];
rc = qed_ilt_blk_alloc(p_hwfn, p_blk, i, lines);
-   if (rc != 0)
+   if 

[PATCH net-next 3/3] qed*: Add and modify some prints

[Yuval Mintz]

This patch touches various prints in the driver - it reduces the
verbosity of some prints [which were previously logged by default]
while adding several new debug prints and modifying others.

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_dev.c| 10 +++---
 drivers/net/ethernet/qlogic/qed/qed_int.c|  8 ++--
 drivers/net/ethernet/qlogic/qed/qed_main.c   | 21 +++--
 drivers/net/ethernet/qlogic/qed/qed_mcp.c|  7 ---
 drivers/net/ethernet/qlogic/qed/qed_spq.c| 11 +--
 drivers/net/ethernet/qlogic/qede/qede_main.c | 20 
 6 files changed, 53 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c 
b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index da23169..66e9f91 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -1211,7 +1211,7 @@ static int qed_reg_assert(struct qed_hwfn *p_hwfn,
u32 assert_val = qed_rd(p_hwfn, p_ptt, reg);
 
if (assert_val != expected) {
-   DP_NOTICE(p_hwfn, "Value at address 0x%x != 0x%08x\n",
+   DP_NOTICE(p_hwfn, "Value at address 0x%08x != 0x%08x\n",
  reg, expected);
return -EINVAL;
}
@@ -1311,6 +1311,10 @@ static void get_function_id(struct qed_hwfn *p_hwfn)
  PXP_CONCRETE_FID_PFID);
p_hwfn->port_id = GET_FIELD(p_hwfn->hw_info.concrete_fid,
PXP_CONCRETE_FID_PORT);
+
+   DP_VERBOSE(p_hwfn, NETIF_MSG_PROBE,
+  "Read ME register: Concrete 0x%08x Opaque 0x%04x\n",
+  p_hwfn->hw_info.concrete_fid, p_hwfn->hw_info.opaque_fid);
 }
 
 static void qed_hw_set_feat(struct qed_hwfn *p_hwfn)
@@ -1610,10 +1614,10 @@ static void qed_get_num_funcs(struct qed_hwfn *p_hwfn, 
struct qed_ptt *p_ptt)
 
DP_VERBOSE(p_hwfn,
   NETIF_MSG_PROBE,
-  "PF [rel_id %d, abs_id %d] within the %d enabled functions 
on the engine\n",
+  "PF [rel_id %d, abs_id %d] occupies index %d within the %d 
enabled functions on the engine\n",
   p_hwfn->rel_pf_id,
   p_hwfn->abs_pf_id,
-  p_hwfn->num_funcs_on_engine);
+  p_hwfn->enabled_func_idx, p_hwfn->num_funcs_on_engine);
 }
 
 static int
diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c 
b/drivers/net/ethernet/qlogic/qed/qed_int.c
index a701b76..61ec973 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
@@ -2576,8 +2576,12 @@ static u16 qed_get_igu_sb_id(struct qed_hwfn *p_hwfn, 
u16 sb_id)
else
igu_sb_id = qed_vf_get_igu_sb_id(p_hwfn, sb_id);
 
-   DP_VERBOSE(p_hwfn, NETIF_MSG_INTR, "SB [%s] index is 0x%04x\n",
-  (sb_id == QED_SP_SB_ID) ? "DSB" : "non-DSB", igu_sb_id);
+   if (sb_id == QED_SP_SB_ID)
+   DP_VERBOSE(p_hwfn, NETIF_MSG_INTR,
+  "Slowpath SB index in IGU is 0x%04x\n", igu_sb_id);
+   else
+   DP_VERBOSE(p_hwfn, NETIF_MSG_INTR,
+  "SB [%04x] <--> IGU SB [%04x]\n", sb_id, igu_sb_id);
 
return igu_sb_id;
 }
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c 
b/drivers/net/ethernet/qlogic/qed/qed_main.c
index aacd00f..675a503 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -51,8 +51,6 @@ MODULE_FIRMWARE(QED_FW_FILE_NAME);
 
 static int __init qed_init(void)
 {
-   pr_notice("qed_init called\n");
-
pr_info("%s", version);
 
return 0;
@@ -437,6 +435,11 @@ static int qed_set_int_mode(struct qed_dev *cdev, bool 
force_mode)
}
 
 out:
+   if (!rc)
+   DP_INFO(cdev, "Using %s interrupts\n",
+   int_params->out.int_mode == QED_INT_MODE_INTA ?
+   "INTa" : int_params->out.int_mode == QED_INT_MODE_MSI ?
+   "MSI" : "MSIX");
cdev->int_coalescing_mode = QED_COAL_MODE_ENABLE;
 
return rc;
@@ -512,19 +515,18 @@ static irqreturn_t qed_single_int(int irq, void 
*dev_instance)
 int qed_slowpath_irq_req(struct qed_hwfn *hwfn)
 {
struct qed_dev *cdev = hwfn->cdev;
+   u32 int_mode;
int rc = 0;
u8 id;
 
-   if (cdev->int_params.out.int_mode == QED_INT_MODE_MSIX) {
+   int_mode = cdev->int_params.out.int_mode;
+   if (int_mode == QED_INT_MODE_MSIX) {
id = hwfn->my_id;
snprintf(hwfn->name, NAME_SIZE, "sp-%d-%02x:%02x.%02x",
 id, cdev->pdev->bus->number,
 PCI_SLOT(cdev->pdev->devfn), hwfn->abs_pf_id);
rc = request_irq(cdev->int_params.msix_table[id].vector,
 qed_msix_sp_int, 0, hwfn->name, hwfn->sp_dpc);
-   if (!rc)
-  

[PATCH net-next 2/3] qed*: Trivial modifications

[Yuval Mintz]

Change qed* code in trivial manner; This isn't necessarily
semantic-only, but the end result is the same, i.e., no change
should occur from user perspective. Changes include:
  - Using temporary variables to better fit 80-character restrictions.
  - Removal of unused variables & code with no effect.
[plus some additional minor modifications].

Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/qed/qed_dev.c  | 11 +
 drivers/net/ethernet/qlogic/qed/qed_init_ops.c | 14 +---
 drivers/net/ethernet/qlogic/qed/qed_int.c  | 11 ++---
 drivers/net/ethernet/qlogic/qed/qed_l2.c   | 31 --
 drivers/net/ethernet/qlogic/qed/qed_mcp.c  |  4 +---
 drivers/net/ethernet/qlogic/qede/qede_main.c   |  3 ---
 6 files changed, 28 insertions(+), 46 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c 
b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 1356e17..da23169 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -540,8 +540,7 @@ int qed_resc_alloc(struct qed_dev *cdev)
cdev->reset_stats = kzalloc(sizeof(*cdev->reset_stats), GFP_KERNEL);
if (!cdev->reset_stats) {
DP_NOTICE(cdev, "Failed to allocate reset statistics\n");
-   rc = -ENOMEM;
-   goto alloc_err;
+   goto alloc_no_mem;
}
 
return 0;
@@ -1468,11 +1467,11 @@ static int qed_hw_get_nvm_info(struct qed_hwfn *p_hwfn, 
struct qed_ptt *p_ptt)
link_temp = qed_rd(p_hwfn, p_ptt,
   port_cfg_addr +
   offsetof(struct nvm_cfg1_port, speed_cap_mask));
-   link->speed.advertised_speeds =
-   link_temp & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_MASK;
+   link_temp &= NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_MASK;
+   link->speed.advertised_speeds = link_temp;
 
-   p_hwfn->mcp_info->link_capabilities.speed_capabilities =
-   link->speed.advertised_speeds;
+   link_temp = link->speed.advertised_speeds;
+   p_hwfn->mcp_info->link_capabilities.speed_capabilities = link_temp;
 
link_temp = qed_rd(p_hwfn, p_ptt,
   port_cfg_addr +
diff --git a/drivers/net/ethernet/qlogic/qed/qed_init_ops.c 
b/drivers/net/ethernet/qlogic/qed/qed_init_ops.c
index 57044ee..b7a4b27 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_init_ops.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_init_ops.c
@@ -295,17 +295,15 @@ static int qed_init_cmd_wr(struct qed_hwfn *p_hwfn,
 
switch (GET_FIELD(data, INIT_WRITE_OP_SOURCE)) {
case INIT_SRC_INLINE:
-   qed_wr(p_hwfn, p_ptt, addr,
-  le32_to_cpu(arg->inline_val));
+   data = le32_to_cpu(p_cmd->args.inline_val);
+   qed_wr(p_hwfn, p_ptt, addr, data);
break;
case INIT_SRC_ZEROS:
-   if (b_must_dmae ||
-   (b_can_dmae && (le32_to_cpu(arg->zeros_count) >= 64)))
-   rc = qed_init_fill_dmae(p_hwfn, p_ptt, addr, 0,
-   le32_to_cpu(arg->zeros_count));
+   data = le32_to_cpu(p_cmd->args.zeros_count);
+   if (b_must_dmae || (b_can_dmae && (data >= 64)))
+   rc = qed_init_fill_dmae(p_hwfn, p_ptt, addr, 0, data);
else
-   qed_init_fill(p_hwfn, p_ptt, addr, 0,
- le32_to_cpu(arg->zeros_count));
+   qed_init_fill(p_hwfn, p_ptt, addr, 0, data);
break;
case INIT_SRC_ARRAY:
rc = qed_init_cmd_array(p_hwfn, p_ptt, p_cmd,
diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c 
b/drivers/net/ethernet/qlogic/qed/qed_int.c
index 2afa7a0..a701b76 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
@@ -2413,12 +2413,6 @@ void qed_init_cau_sb_entry(struct qed_hwfn *p_hwfn,
SET_FIELD(p_sb_entry->params, CAU_SB_ENTRY_SB_TIMESET0, 0x7F);
SET_FIELD(p_sb_entry->params, CAU_SB_ENTRY_SB_TIMESET1, 0x7F);
 
-   /* setting the time resultion to a fixed value ( = 1) */
-   SET_FIELD(p_sb_entry->params, CAU_SB_ENTRY_TIMER_RES0,
- QED_CAU_DEF_RX_TIMER_RES);
-   SET_FIELD(p_sb_entry->params, CAU_SB_ENTRY_TIMER_RES1,
- QED_CAU_DEF_TX_TIMER_RES);
-
cau_state = CAU_HC_DISABLE_STATE;
 
if (cdev->int_coalescing_mode == QED_COAL_MODE_ENABLE) {
@@ -3133,10 +3127,9 @@ int qed_int_alloc(struct qed_hwfn *p_hwfn, struct 
qed_ptt *p_ptt)
return rc;
}
rc = qed_int_sb_attn_alloc(p_hwfn, p_ptt);
-   if (rc) {
+   if (rc)
DP_ERR(p_hwfn->cdev, "Failed to allocate sb attn mem\n");
-   return rc;
-   }
+
return rc;
 }
 
diff --git 

[PATCH net-next 0/3] qed*: Janitorial series [semantic & prints]

[Yuval Mintz]

Hi Dave,

Some day 1 slips in coding style exist in the qed* code
[incorrect alignments, conditions using (== 0), etc.].
This series comes to address those, and do some additional
cosmetic changes along the way [such as reducing the number of lines
for function declerations].

The series is broken to 3 parts - purely semantic changes, cosmetic
changes that required minor changes in the code, and print-related
changes. All-in-all, no real change in driver behavior is expected.

Please consider applying this to `net-next'.

Thanks,
Yuval

Yuval Mintz (3):
  qed*: Semantic changes
  qed*: Trivial modifications
  qed*: Add and modify some prints

 drivers/net/ethernet/qlogic/qed/qed_cxt.c |  47 ++---
 drivers/net/ethernet/qlogic/qed/qed_dev.c | 115 +--
 drivers/net/ethernet/qlogic/qed/qed_hw.c  | 137 +---
 drivers/net/ethernet/qlogic/qed/qed_init_ops.c|  93 -
 drivers/net/ethernet/qlogic/qed/qed_int.c | 132 +---
 drivers/net/ethernet/qlogic/qed/qed_l2.c  | 241 ++
 drivers/net/ethernet/qlogic/qed/qed_main.c|  34 +--
 drivers/net/ethernet/qlogic/qed/qed_mcp.c |  78 +++
 drivers/net/ethernet/qlogic/qed/qed_sp_commands.c |  15 +-
 drivers/net/ethernet/qlogic/qed/qed_spq.c |  95 -
 drivers/net/ethernet/qlogic/qed/qed_sriov.c   |  56 +++--
 drivers/net/ethernet/qlogic/qede/qede_ethtool.c   |   6 +-
 drivers/net/ethernet/qlogic/qede/qede_main.c  | 144 ++---
 13 files changed, 484 insertions(+), 709 deletions(-)

-- 
1.9.3

Re: [iproute PATCH 0/3] improve MACsec support

[Sabrina Dubroca]

2016-07-26, 11:03:17 +0200, Davide Caratti wrote:
> parsing of 'cipher' and 'icvlen' arguments has been improved; while at it,
> a couple of missing printouts have been added to usage() functions in 
> "ip addr help" and "ip link help". Finally, some errors in the man pages
> have been fixed.
> 
> Signed-off-by: Davide Caratti 
> 
> Davide Caratti (3):
>   man: macsec: fix macsec related typos
>   ip {link,address}: add 'macsec' item to TYPE list
>   macsec: cipher and icvlen can be set separately
> 
>  ip/ipaddress.c   |  2 +-
>  ip/iplink.c  |  2 +-
>  ip/ipmacsec.c| 52 
> 
>  man/man8/ip-address.8.in |  3 ++-
>  man/man8/ip-link.8.in| 17 +++-
>  man/man8/ip-macsec.8 | 13 
>  6 files changed, 42 insertions(+), 47 deletions(-)

Acked-by: Sabrina Dubroca 

Stephen, can this go in before the 4.7 release?  This fixes parsing
bugs and docs, it would be nice to have this.


Thanks,

-- 
Sabrina