Re: [PATCH] net: stmmac: dwmac-rk: add rk322x-specific data

2016-06-21 Thread Heiko Stübner
Am Dienstag, 21. Juni 2016, 15:13:55 schrieb Xing Zheng:
> Add constants and callback functions for the dwmac on rk322x socs.
> As can be seen, the base structure is the same, only registers and
> the bits in them moved slightly.
> 
> Signed-off-by: Xing Zheng 
> ---
> 
>  .../devicetree/bindings/net/rockchip-dwmac.txt |3 +-
>  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c |  117
>  2 files changed, 119 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt index
> 93eac7c..5040ed4 100644
> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
> @@ -3,7 +3,8 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
>  The device node has following properties.
> 
>  Required properties:
> - - compatible: Can be one of "rockchip,rk3288-gmac", "rockchip,rk3368-gmac"
> + - compatible: Can be one of "rockchip,rk322x-gmac",

devicetree names are normally expected to be real, aka no "x" as catchall. So 
I guess either just add compatibles for both the rk3228 and rk3229 which point 
to the same structure in the driver. (So driver-side can stay as it is below, 
just add a second compatible).


> "rockchip,rk3288-gmac", +
> "rockchip,rk3368-gmac"
>   - reg: addresses and length of the register sets for the device.
>   - interrupts: Should contain the GMAC interrupts.
>   - interrupt-names: Should contain the interrupt names "macirq".
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index 0cd3ecf..7f045db
> 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -72,6 +72,122 @@ struct rk_priv_data {
>  #define GRF_BIT(nr)  (BIT(nr) | BIT(nr+16))
>  #define GRF_CLR_BIT(nr)  (BIT(nr+16))
> 
> +#define RK322X_GRF_MAC_CON0  0x0900
> +#define RK322X_GRF_MAC_CON1  0x0904
> +
> +/* RK322X_GRF_MAC_CON0 */
> +#define RK322X_GMAC_CLK_RX_DL_CFG(val)   HIWORD_UPDATE(val, 0x7F, 7)
> +#define RK322X_GMAC_CLK_TX_DL_CFG(val)   HIWORD_UPDATE(val, 0x7F, 0)
> +
> +/* RK322X_GRF_MAC_CON1 */
> +#define RK322X_GMAC_PHY_INTF_SEL_RGMII   \
> + (GRF_BIT(4) | GRF_CLR_BIT(5) | GRF_CLR_BIT(6))
> +#define RK322X_GMAC_PHY_INTF_SEL_RMII\
> + (GRF_CLR_BIT(4) | GRF_CLR_BIT(5) | GRF_BIT(6))
> +#define RK322X_GMAC_FLOW_CTRLGRF_BIT(3)
> +#define RK322X_GMAC_FLOW_CTRL_CLRGRF_CLR_BIT(3)
> +#define RK322X_GMAC_SPEED_10MGRF_CLR_BIT(2)
> +#define RK322X_GMAC_SPEED_100M   GRF_BIT(2)
> +#define RK322X_GMAC_RMII_CLK_25M GRF_BIT(7)
> +#define RK322X_GMAC_RMII_CLK_2_5MGRF_CLR_BIT(7)
> +#define RK322X_GMAC_CLK_125M (GRF_CLR_BIT(8) | GRF_CLR_BIT(9))
> +#define RK322X_GMAC_CLK_25M  (GRF_BIT(8) | GRF_BIT(9))
> +#define RK322X_GMAC_CLK_2_5M (GRF_CLR_BIT(8) | GRF_BIT(9))
> +#define RK322X_GMAC_RMII_MODEGRF_BIT(10)
> +#define RK322X_GMAC_RMII_MODE_CLRGRF_CLR_BIT(10)
> +#define RK322X_GMAC_TXCLK_DLY_ENABLE GRF_BIT(0)
> +#define RK322X_GMAC_TXCLK_DLY_DISABLEGRF_CLR_BIT(0)
> +#define RK322X_GMAC_RXCLK_DLY_ENABLE GRF_BIT(1)
> +#define RK322X_GMAC_RXCLK_DLY_DISABLEGRF_CLR_BIT(1)
> +
> +static void rk322x_set_to_rgmii(struct rk_priv_data *bsp_priv,
> + int tx_delay, int rx_delay)
> +{
> + struct device *dev = _priv->pdev->dev;
> +
> + if (IS_ERR(bsp_priv->grf)) {
> + dev_err(dev, "Missing rockchip,grf property\n");
> + return;
> + }
> +
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON1,
> +  RK322X_GMAC_PHY_INTF_SEL_RGMII |
> +  RK322X_GMAC_RMII_MODE_CLR |
> +  RK322X_GMAC_RXCLK_DLY_ENABLE |
> +  RK322X_GMAC_TXCLK_DLY_ENABLE);
> +
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON0,
> +  RK322X_GMAC_CLK_RX_DL_CFG(rx_delay) |
> +  RK322X_GMAC_CLK_TX_DL_CFG(tx_delay));
> +}
> +
> +static void rk322x_set_to_rmii(struct rk_priv_data *bsp_priv)
> +{
> + struct device *dev = _priv->pdev->dev;
> +
> + if (IS_ERR(bsp_priv->grf)) {
> + dev_err(dev, "Missing rockchip,grf property\n");
> + return;
> + }
> +
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON1,
> +  RK322X_GMAC_PHY_INTF_SEL_RMII |
> +  RK322X_GMAC_RMII_MODE);
> +
> + /* set MAC to RMII mode */
> + regmap_write(bsp_priv->grf, RK322X_GRF_MAC_CON1, GRF_BIT(11));
> +}
> +
> +static void rk322x_set_rgmii_speed(struct rk_priv_data *bsp_priv, int
> speed) +{
> + struct device *dev = _priv->pdev->dev;
> +
> + if (IS_ERR(bsp_priv->grf)) {
> + dev_err(dev, "Missing rockchip,grf property\n");
> + 

Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   net/ieee802154/nl-mac.c: In function 'llsec_parse_dev':
>> net/ieee802154/nl-mac.c:1003:5: error: 'struct ieee802154_llsec_device' has 
>> no member named 'hwaddr'
 dev->hwaddr = nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
^
   net/ieee802154/nl-mac.c: In function 'ieee802154_nl_fill_dev':
>> net/ieee802154/nl-mac.c:1069:55: error: 'const struct 
>> ieee802154_llsec_device' has no member named 'hwaddr'
 nla_put_hwaddr(msg, IEEE802154_ATTR_HW_ADDR, desc->hwaddr,
  ^
   net/ieee802154/nl-mac.c: In function 'llsec_iter_devkeys':
   net/ieee802154/nl-mac.c:1208:17: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'
dpos->hwaddr, kpos,
^

vim +1003 net/ieee802154/nl-mac.c

3e9c156e Phoebe Buckheister 2014-05-16   997dev->pan_id = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_PAN_ID]);
3e9c156e Phoebe Buckheister 2014-05-16   998dev->short_addr = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_SHORT_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16   999} else {
3e9c156e Phoebe Buckheister 2014-05-16  1000dev->short_addr = 
cpu_to_le16(IEEE802154_ADDR_UNDEF);
3e9c156e Phoebe Buckheister 2014-05-16  1001}
3e9c156e Phoebe Buckheister 2014-05-16  1002  
3e9c156e Phoebe Buckheister 2014-05-16 @1003dev->hwaddr = 
nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16  1004dev->frame_counter = 
nla_get_u32(info->attrs[IEEE802154_ATTR_LLSEC_FRAME_COUNTER]);
3e9c156e Phoebe Buckheister 2014-05-16  1005dev->seclevel_exempt = 
!!nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_OVERRIDE]);
3e9c156e Phoebe Buckheister 2014-05-16  1006dev->key_mode = 
nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_KEY_MODE]);
3e9c156e Phoebe Buckheister 2014-05-16  1007  
3e9c156e Phoebe Buckheister 2014-05-16  1008if (dev->key_mode >= 
__IEEE802154_LLSEC_DEVKEY_MAX)
3e9c156e Phoebe Buckheister 2014-05-16  1009return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1010  
3e9c156e Phoebe Buckheister 2014-05-16  1011return 0;
3e9c156e Phoebe Buckheister 2014-05-16  1012  }
3e9c156e Phoebe Buckheister 2014-05-16  1013  
3e9c156e Phoebe Buckheister 2014-05-16  1014  static int llsec_add_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1015  {
3e9c156e Phoebe Buckheister 2014-05-16  1016struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1017struct ieee802154_llsec_device 
desc;
3e9c156e Phoebe Buckheister 2014-05-16  1018  
3e9c156e Phoebe Buckheister 2014-05-16  1019if (llsec_parse_dev(info, 
))
3e9c156e Phoebe Buckheister 2014-05-16  1020return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1021  
3e9c156e Phoebe Buckheister 2014-05-16  1022return ops->llsec->add_dev(dev, 
);
3e9c156e Phoebe Buckheister 2014-05-16  1023  }
3e9c156e Phoebe Buckheister 2014-05-16  1024  
3e9c156e Phoebe Buckheister 2014-05-16  1025  int 
ieee802154_llsec_add_dev(struct sk_buff *skb, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1026  {
3e9c156e Phoebe Buckheister 2014-05-16  1027if ((info->nlhdr->nlmsg_flags & 
(NLM_F_CREATE | NLM_F_EXCL)) !=
3e9c156e Phoebe Buckheister 2014-05-16  1028(NLM_F_CREATE | NLM_F_EXCL))
3e9c156e Phoebe Buckheister 2014-05-16  1029return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1030  
3e9c156e Phoebe Buckheister 2014-05-16  1031return 
ieee802154_nl_llsec_change(skb, info, llsec_add_dev);
3e9c156e Phoebe Buckheister 2014-05-16  1032  }
3e9c156e Phoebe Buckheister 2014-05-16  1033  
3e9c156e Phoebe Buckheister 2014-05-16  1034  static int llsec_del_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1035  {
3e9c156e Phoebe Buckheister 2014-05-16  1036struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1037__le64 devaddr;
3e9c156e Phoebe Buckheister 2014-05-16  1038  
3e9c156e Phoebe Buckheister 2014-05-16  1039if 
(!info->attrs[IEEE802154_ATTR_HW_ADDR])
3e9c156e Phoebe Buckheister 2014-05-16  1040return -EINVAL;
3e9c156e Phoeb

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

2016-06-21 Thread Leon Romanovsky
On Tue, Jun 21, 2016 at 06:50:51PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/20 21:33, Leon Romanovsky wrote:
> >On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:
> >>This patch added the operation for cmd, and added some functions
> >>for initializing eq table and selecting cmd mode.
> >>
> >>Signed-off-by: Wei Hu 
> >>Signed-off-by: Nenglong Zhao 
> >>Signed-off-by: Lijun Ou 
> >>---
> >>PATCH v9/v8/v7/v6:
> >>- No change over the PATCH v5
> >>
> >>PATCH v5:
> >>- The initial patch which was redesigned based on the second patch
> >>   in PATCH v4
> >>---
> ><...>
> >
> >>+#define CMD_MAX_NUM32
> >>+
> >>+int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> >>+{
> >>+   struct device *dev = _dev->pdev->dev;
> >>+
> >>+   mutex_init(_dev->cmd.hcr_mutex);
> >>+   sema_init(_dev->cmd.poll_sem, 1);
> >>+   hr_dev->cmd.use_events = 0;
> >>+   hr_dev->cmd.toggle = 1;
> >>+   hr_dev->cmd.max_cmds = CMD_MAX_NUM;
> ><...>
> >
> >>+   for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
> >>+hr_cmd->token_mask <<= 1)
> >>+   ;
> >>+   --hr_cmd->token_mask;
> >It doesn't look that you dynamically change max_cmds supported.
> >Why do you need to calculate token_mask dynamically?
> Hi, Leon
> 
> 1. The four lines above are in the function named
> hns_roce_cmd_use_events.
>  and now this function is only called once in hns_roce_probe.
> 2. In hns_roce_cmd_use_events,
> we use these 4 lines to achieve the value of hr_cmd->token_mask
> according to hr_cmd->max_cmds dynamically,
> then we only define one marco for hr_cmd->max_cmds as below:
> 
>   #define CMD_MAX_NUM 32
> 
>And it looks more flexible.

It is called over engineering.
I would recommend to you to remove it.

We don't need over complicated code which is executed
once with need to maintain with zero benefit.

The other places need such simplification too.

> 
> Regards
> Wei Hu
> 
> 
> 


signature.asc
Description: Digital signature


Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   net/ieee802154/nl-mac.c: In function 'llsec_parse_dev':
>> net/ieee802154/nl-mac.c:1003:5: error: 'struct ieee802154_llsec_device' has 
>> no member named 'hwaddr'; did you mean 'short_addr'?
 dev->hwaddr = nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
^~
   net/ieee802154/nl-mac.c: In function 'ieee802154_nl_fill_dev':
>> net/ieee802154/nl-mac.c:1069:55: error: 'const struct 
>> ieee802154_llsec_device' has no member named 'hwaddr'; did you mean 
>> 'short_addr'?
 nla_put_hwaddr(msg, IEEE802154_ATTR_HW_ADDR, desc->hwaddr,
  ^~
   net/ieee802154/nl-mac.c: In function 'llsec_iter_devkeys':
   net/ieee802154/nl-mac.c:1208:17: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'; did you mean 'short_addr'?
dpos->hwaddr, kpos,
^~

vim +1003 net/ieee802154/nl-mac.c

3e9c156e Phoebe Buckheister 2014-05-16   997dev->pan_id = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_PAN_ID]);
3e9c156e Phoebe Buckheister 2014-05-16   998dev->short_addr = 
nla_get_shortaddr(info->attrs[IEEE802154_ATTR_SHORT_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16   999} else {
3e9c156e Phoebe Buckheister 2014-05-16  1000dev->short_addr = 
cpu_to_le16(IEEE802154_ADDR_UNDEF);
3e9c156e Phoebe Buckheister 2014-05-16  1001}
3e9c156e Phoebe Buckheister 2014-05-16  1002  
3e9c156e Phoebe Buckheister 2014-05-16 @1003dev->hwaddr = 
nla_get_hwaddr(info->attrs[IEEE802154_ATTR_HW_ADDR]);
3e9c156e Phoebe Buckheister 2014-05-16  1004dev->frame_counter = 
nla_get_u32(info->attrs[IEEE802154_ATTR_LLSEC_FRAME_COUNTER]);
3e9c156e Phoebe Buckheister 2014-05-16  1005dev->seclevel_exempt = 
!!nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_OVERRIDE]);
3e9c156e Phoebe Buckheister 2014-05-16  1006dev->key_mode = 
nla_get_u8(info->attrs[IEEE802154_ATTR_LLSEC_DEV_KEY_MODE]);
3e9c156e Phoebe Buckheister 2014-05-16  1007  
3e9c156e Phoebe Buckheister 2014-05-16  1008if (dev->key_mode >= 
__IEEE802154_LLSEC_DEVKEY_MAX)
3e9c156e Phoebe Buckheister 2014-05-16  1009return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1010  
3e9c156e Phoebe Buckheister 2014-05-16  1011return 0;
3e9c156e Phoebe Buckheister 2014-05-16  1012  }
3e9c156e Phoebe Buckheister 2014-05-16  1013  
3e9c156e Phoebe Buckheister 2014-05-16  1014  static int llsec_add_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1015  {
3e9c156e Phoebe Buckheister 2014-05-16  1016struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1017struct ieee802154_llsec_device 
desc;
3e9c156e Phoebe Buckheister 2014-05-16  1018  
3e9c156e Phoebe Buckheister 2014-05-16  1019if (llsec_parse_dev(info, 
))
3e9c156e Phoebe Buckheister 2014-05-16  1020return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1021  
3e9c156e Phoebe Buckheister 2014-05-16  1022return ops->llsec->add_dev(dev, 
);
3e9c156e Phoebe Buckheister 2014-05-16  1023  }
3e9c156e Phoebe Buckheister 2014-05-16  1024  
3e9c156e Phoebe Buckheister 2014-05-16  1025  int 
ieee802154_llsec_add_dev(struct sk_buff *skb, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1026  {
3e9c156e Phoebe Buckheister 2014-05-16  1027if ((info->nlhdr->nlmsg_flags & 
(NLM_F_CREATE | NLM_F_EXCL)) !=
3e9c156e Phoebe Buckheister 2014-05-16  1028(NLM_F_CREATE | NLM_F_EXCL))
3e9c156e Phoebe Buckheister 2014-05-16  1029return -EINVAL;
3e9c156e Phoebe Buckheister 2014-05-16  1030  
3e9c156e Phoebe Buckheister 2014-05-16  1031return 
ieee802154_nl_llsec_change(skb, info, llsec_add_dev);
3e9c156e Phoebe Buckheister 2014-05-16  1032  }
3e9c156e Phoebe Buckheister 2014-05-16  1033  
3e9c156e Phoebe Buckheister 2014-05-16  1034  static int llsec_del_dev(struct 
net_device *dev, struct genl_info *info)
3e9c156e Phoebe Buckheister 2014-05-16  1035  {
3e9c156e Phoebe Buckheister 2014-05-16  1036struct ieee802154_mlme_ops *ops 
= ieee802154_mlme_ops(dev);
3e9c156e Phoebe Buckheister 2014-05-16  1037__le64 devaddr;
3e9c156e Phoebe Buckheister 2014-05-16  1038  
3e9c156e Phoebe Buckheister 2014-05-16  1039if 
(!info->attrs[I

Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

2016-06-21 Thread Bob Copeland
On Mon, Jun 20, 2016 at 04:00:19PM +0300, Maxim Altshul wrote:
> 2. Implements the opcode and the mechanism that reports the rates
> in TI driver.

Does this mean TI driver will support mesh at some point?

-- 
Bob Copeland %% http://bobcopeland.com/


Re: [PATCH net-next 00/19] net: hns: fix some bugs in hns driver

2016-06-21 Thread David Miller
From: Yisen Zhuang 
Date: Tue, 21 Jun 2016 11:56:20 +0800

> This series includes some bugs fixed. All these patches needs to be
> applied after the patchset about ACPI support, so this series is 
> floated to net-next list.

Series applied, thanks.


Re: [PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on net-next/master]
[also build test ERROR on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Rowland/include-net-cfg802154-rename-ieee802154_llsec_device-hwaddr-to-extended_addr/20160621-182617
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   net/mac802154/llsec.c: In function 'llsec_dev_find_long':
>> net/mac802154/llsec.c:333:15: error: 'struct ieee802154_llsec_device' has no 
>> member named 'hwaddr'
  if (dev->dev.hwaddr == hwaddr)
  ^
   net/mac802154/llsec.c: In function 'llsec_lookup_dev':
   net/mac802154/llsec.c:799:16: error: 'struct ieee802154_llsec_device' has no 
member named 'hwaddr'
   if (dev->dev.hwaddr == devaddr.extended_addr)
   ^
   net/mac802154/llsec.c: In function 'mac802154_llsec_decrypt':
   net/mac802154/llsec.c:1037:21: error: 'struct ieee802154_llsec_device' has 
no member named 'hwaddr'
 dev_addr = dev->dev.hwaddr;
^

vim +333 net/mac802154/llsec.c

5d637d5a Phoebe Buckheister 2014-05-16  327  llsec_dev_find_long(struct 
mac802154_llsec *sec, __le64 hwaddr)
5d637d5a Phoebe Buckheister 2014-05-16  328  {
5d637d5a Phoebe Buckheister 2014-05-16  329 struct mac802154_llsec_device 
*dev;
5d637d5a Phoebe Buckheister 2014-05-16  330 u64 key = 
llsec_dev_hash_long(hwaddr);
5d637d5a Phoebe Buckheister 2014-05-16  331  
5d637d5a Phoebe Buckheister 2014-05-16  332 
hash_for_each_possible_rcu(sec->devices_hw, dev, bucket_hw, key) {
5d637d5a Phoebe Buckheister 2014-05-16 @333 if (dev->dev.hwaddr == 
hwaddr)
5d637d5a Phoebe Buckheister 2014-05-16  334 return dev;
5d637d5a Phoebe Buckheister 2014-05-16  335 }
5d637d5a Phoebe Buckheister 2014-05-16  336  

:: The code at line 333 was first introduced by commit
:: 5d637d5aabd85132bd85779677d8acb708e0ed90 mac802154: add llsec structures 
and mutators

:: TO: Phoebe Buckheister <phoebe.buckheis...@itwm.fraunhofer.de>
:: CC: David S. Miller <da...@davemloft.net>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[PATCHv3] wlcore: spi: add wl18xx support

2016-06-21 Thread Reizer, Eyal
Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage and puts the wilink chip into wspi mode.

Signed-off-by: Eyal Reizer 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle, which achieves the same hardware purpose.
update device tree bindings docucmentation accordingly

 .../bindings/net/wireless/ti,wlcore,spi.txt|  47 ++--
 drivers/net/wireless/ti/wlcore/spi.c   | 124 +
 2 files changed, 145 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..35467cf 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
 
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.
 
 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip
 
 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL
 
 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,10 +32,15 @@ Optional properties:
 
 Examples:
 
+For wl12xx family:
  {
-   wl1271@1 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
clock-xtal;
@@ -34,3 +50,20 @@ Examples:
vwlan-supply = <_fixed>;
};
 };
+
+For wl18xx family:
+  {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   vwlan-supply = <_en_reg>;
+   spi-max-frequency = <4800>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 020ac1a..bd1253d 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092
 
 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
 
 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+   struct spi_device *spi = to_spi_device(glue->dev);
u8 

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

2016-06-21 Thread Naveen N. Rao
On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > 
> > > Hi, Michael and Naveen.
> > > 
> > > I noticed independently that there is a problem with BPF JIT and ABIv2, 
> > > and
> > > worked out the patch below before I noticed Naveen's patchset and the 
> > > latest
> > > changes in ppc tree for a better way to check for ABI versions.
> > > 
> > > However, since the issue described below affect mainline and stable 
> > > kernels,
> > > would you consider applying it before merging your two patchsets, so that 
> > > we can
> > > more easily backport the fix?
> > 
> > Hi Cascardo,
> > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > fixing it. But, I can see why this would be a good thing to have for 
> > -stable and existing distros. However, while your patch below may fix 
> > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > changes in bpf_jit_asm.S as well.
> 
> Hi, Naveen.
> 
> Any tips on how to exercise possible issues there? Or what changes you think
> would be sufficient?

The calling convention is different with ABIv2 and so we'll need changes 
in bpf_slow_path_common() and sk_negative_common().

However, rather than enabling classic JIT for ppc64le, are we better off 
just disabling it?

--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -128,7 +128,7 @@ config PPC
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
select HAVE_SYSCALL_TRACEPOINTS
-   select HAVE_CBPF_JIT
+   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
select HAVE_ARCH_JUMP_LABEL
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_HAS_GCOV_PROFILE_ALL


Michael,
Let me know your thoughts on whether you intend to take this patch or 
Cascardo's patch for -stable before the eBPF patches. I can redo my 
patches accordingly.


- Naveen



[PATCH net 0/2] mlx4_en fixes for 4.7-rc

2016-06-21 Thread Tariq Toukan
Hi Dave,

This small patchset includes two fixes for mlx4_en driver.

One allows a clean shutdown even when clients do not release their
netdev reference.
The other adds error return values to the VLAN VID add/kill functions.

Eran Ben Elisha (1):
  net/mlx4_en: Avoid unregister_netdev at shutdown flow

Kamal Heib (1):
  net/mlx4_en: Fix the return value of a failure in VLAN VID add/kill

 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 35 +++---
 drivers/net/ethernet/mellanox/mlx4/main.c  |  5 +++-
 include/linux/mlx4/device.h|  1 +
 3 files changed, 31 insertions(+), 10 deletions(-)

-- 
1.8.3.1



[PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

2016-06-21 Thread thloh
From: Tien Hock Loh 

This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
the dwmac is set to sgmii

Signed-off-by: Tien Hock Loh 

---
v2:
- Refactored the TSE PCS out from the dwmac-socfpga.c file
- Added binding documentation for TSE PCS sgmii adapter
v3:
- Added missing license header for new source files
- Updated tse_pcs.h include headers
- Standardize if statements
v4:
- Reset SGMII adapter on speed change
- Do not enable SGMII adapter if speed is not supported
- On init, if PCS reset fails, do not enable adapter
123
---
 .../devicetree/bindings/net/socfpga-dwmac.txt  |  19 ++
 drivers/net/ethernet/stmicro/stmmac/Makefile   |   2 +-
 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 276 +
 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h |  36 +++
 .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 149 +--
 5 files changed, 460 insertions(+), 22 deletions(-)
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h

diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt 
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 72d82d6..dd10f2f 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -17,9 +17,26 @@ Required properties:
 Optional properties:
 altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
DWMAC controller is connected emac splitter.
+phy-mode: The phy mode the ethernet operates in
+altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter
+
+This device node has additional phandle dependency, the sgmii converter:
+
+Required properties:
+ - compatible  : Should be altr,gmii-to-sgmii-2.0
+ - reg-names   : Should be "eth_tse_control_port"
 
 Example:
 
+gmii_to_sgmii_converter: phy@0x10240 {
+   compatible = "altr,gmii-to-sgmii-2.0";
+   reg = <0x0001 0x0240 0x0008>,
+   <0x0001 0x0200 0x0040>;
+   reg-names = "eth_tse_control_port";
+   clocks = <_1_clk_0  1 _clk_125 _clk_125>;
+   clock-names = "tse_pcs_ref_clk_clock_connection", "tse_rx_cdr_refclk";
+};
+
 gmac0: ethernet@ff70 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
altr,sysmgr-syscon = < 0x60 0>;
@@ -30,4 +47,6 @@ gmac0: ethernet@ff70 {
mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
clocks = <_0_clk>;
clock-names = "stmmaceth";
+   phy-mode = "sgmii";
+   altr,gmii-to-sgmii-converter = <_to_sgmii_converter>;
 };
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 0fb362d..0ff76e8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -11,7 +11,7 @@ obj-$(CONFIG_DWMAC_IPQ806X)   += dwmac-ipq806x.o
 obj-$(CONFIG_DWMAC_LPC18XX)+= dwmac-lpc18xx.o
 obj-$(CONFIG_DWMAC_MESON)  += dwmac-meson.o
 obj-$(CONFIG_DWMAC_ROCKCHIP)   += dwmac-rk.o
-obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o
+obj-$(CONFIG_DWMAC_SOCFPGA)+= dwmac-socfpga.o altr_tse_pcs.o
 obj-$(CONFIG_DWMAC_STI)+= dwmac-sti.o
 obj-$(CONFIG_DWMAC_SUNXI)  += dwmac-sunxi.o
 obj-$(CONFIG_DWMAC_GENERIC)+= dwmac-generic.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c 
b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
new file mode 100644
index 000..40bfaac
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c
@@ -0,0 +1,276 @@
+/* Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2,
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ * Author: Tien Hock Loh 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "stmmac.h"
+#include "stmmac_platform.h"
+#include "altr_tse_pcs.h"
+
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII   0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII  BIT(1)
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII   BIT(2)
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH   2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASKGENMASK(1, 0)
+
+#define TSE_PCS_CONTROL_AN_EN_MASK BIT(12)
+#define 

Re: [PATCH 3/3] mac80211: mesh: Add support for HW RC implementation

2016-06-21 Thread Johannes Berg
> - if (sta->mesh->fail_avg >= 100)
> - return MAX_METRIC;
> + /* try to get rate based on HW RC algorithm */
> + rate = drv_get_expected_throughput(local, >sta);

This doesn't look correct, since you should use the rate control op if
available, to get data from rate control algorithms.

You should call sta_set_sinfo(), but that's far too much, so more
likely you should factor out the last few lines of that into a new
function and call that new function in both places.

johannes


Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

2016-06-21 Thread Johannes Berg
On Mon, 2016-06-13 at 23:21 +0200, Pavel Machek wrote:
> 
> (Actually, "::wifi" is super confusing, I'd expect that to be a led
> that blinks when wifi is active.)

Agree with that, yeah, that'd be confusing.

> Well... "airplane" is quite confusing. I'd we use "rfkill" for
> disabling radios, and I believe we should stick with that.
> 
> But small problem might be polarity. You may need both "::rfkill" and
> "::not-rfkill".

I'd argue that "airplane" matches better what you're likely to find on
the chassis of the system.

In either case I think the suffixes should be documented, for both
future kernel and application developers.

johannes


Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

2016-06-21 Thread Netanel Belgazal


On 06/21/2016 01:43 AM, Francois Romieu wrote:
> Netanel Belgazal  :
> [...]
>>> diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h 
>>> b/drivers/net/ethernet/amazon/ena/ena_com.h
>>> new file mode 100644
>>> index 000..e49ba43
>>> --- /dev/null
>>> [...]
>>> +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg 
>>> *intr_reg,
>>> +  u32 rx_delay_interval,
>>> +  u32 tx_delay_interval,
>>> +  bool unmask)
>>> +{
>>> +   intr_reg->intr_control = 0;
>>> +   intr_reg->intr_control |= rx_delay_interval &
>>> +   ENA_ETH_IO_INTR_REG_RX_INTR_DELAY_MASK;
>>> +
>>> +   intr_reg->intr_control |=
>>> +   (tx_delay_interval << ENA_ETH_IO_INTR_REG_TX_INTR_DELAY_SHIFT)
>>> +   & ENA_ETH_IO_INTR_REG_RX_INTR_DELAY_MASK;
>>>   ^^ TX ?
>>>
>>> Extra: you should not return NETDEV_TX_BUSY in the xmit handler while
>>> queueing is still enabled. Please drop packet and return NETDEV_TX_OK.
>> Ack.
>>
>> Thanks for your review.
> Ack/nack regarding use of ..._RX_INTR_DELAY_MASK with ..._TX_INTR_DELAY_SHIFT 
> ?
You are right, it should have been TX_INTR_DELAY_SHIFT.
I'll fix that.


Re: [PATCH net-next 10/19] net: hns: bugfix about pfc pause frame statistics

2016-06-21 Thread Andy Shevchenko
On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote:
> From: Daode Huang 
> 
> For SoC hip06, PFC pause handled in dsaf, while hip05 in XGMAC,
> so change the statistics of pfc pause in dsaf and remove the old
> pfc pause frame statistics.
> 


> +static char *hns_dsaf_get_node_stats_strings(char *data, int node,
> +  struct dsaf_device
> *dsaf_dev)
>  {
>   char *buff = data;
> + int i;
> + bool is_ver1 = AE_IS_VER1(dsaf_dev->dsaf_ver);
>  
>   snprintf(buff, ETH_GSTRING_LEN, "innod%d_pad_drop_pkts",
> node);
>   buff = buff + ETH_GSTRING_LEN;
> @@ -2502,6 +2530,18 @@ static char
> *hns_dsaf_get_node_stats_strings(char *data, int node)
>   buff = buff + ETH_GSTRING_LEN;
>   snprintf(buff, ETH_GSTRING_LEN, "innod%d_stp_drop_pkts",
> node);
>   buff = buff + ETH_GSTRING_LEN;
> + if ((node < DSAF_SERVICE_NW_NUM) && (!is_ver1)) {

Redundant parens.

> + for (i = 0; i < DSAF_PRIO_NR; i++) {
> + snprintf(buff, ETH_GSTRING_LEN,
> +  "inod%d_pfc_prio%d_pkts", node, i);
> + buff = buff + ETH_GSTRING_LEN;

buff += ...

> + }
> + for (i = 0; i < DSAF_PRIO_NR; i++) {
> + snprintf(buff, ETH_GSTRING_LEN,
> +  "onod%d_pfc_prio%d_pkts", node, i);
> + buff = buff + ETH_GSTRING_LEN;

Ditto.

>  {
>   u64 *p = data;
> + int i;
>   struct dsaf_hw_stats *hw_stats = >hw_stats[node_num];
> + bool is_ver1 = AE_IS_VER1(ddev->dsaf_ver);
>  
>   p[0] = hw_stats->pad_drop;
>   p[1] = hw_stats->man_pkts;
> @@ -2527,8 +2569,16 @@ static u64 *hns_dsaf_get_node_stats(struct
> dsaf_device *ddev, u64 *data,
>   p[10] = hw_stats->local_addr_false;
>   p[11] = hw_stats->vlan_drop;
>   p[12] = hw_stats->stp_drop;
> - p[13] = hw_stats->tx_pkts;
> + if ((node_num < DSAF_SERVICE_NW_NUM) && (!is_ver1)) {
> + for (i = 0; i < DSAF_PRIO_NR; i++) {
> + p[13 + i] = hw_stats->rx_pfc[i];
> + p[13 + i + DSAF_PRIO_NR] = hw_stats-
> >tx_pfc[i];
> + }

Two different approaches how to assign data. Above uses 2 for-loops,
here you put everything to one.

> + p[29] = hw_stats->tx_pkts;
> + return [30];
> + }
>  
> + p[13] = hw_stats->tx_pkts;
>   return [14];
>  }

-- 

Andy Shevchenko 
Intel Finland Oy


Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

2016-06-21 Thread Edward Cree
On 21/06/16 09:22, David Miller wrote:
> From: Tom Herbert  Date: Mon, 20 Jun 2016 10:05:01 -0700
>> Generally, this means it needs to at least match by local addresses and port 
>> for an unconnected/unbound socket, the source address for an 
>> unconnected/bound socket, a the full 4-tuple for a connected socket. 
> These lookup keys are all insufficient. At the very least the network 
> namespace must be in the lookup key as well if you want to match "sockets".
But the card doesn't have to be told that; instead, only push a socket to
a device offload if the device is in the same ns as the socket.  Wouldn't
that work?
Anything beyond that - i.e. supporting cross-ns offloads - would require
knowing how packets / addresses get transformed in bridging them from one
ns to another and in general that's quite a wide set of possibilities; it
doesn't seem worth while.  Especially since the likely use-case of tunnels
plus containers is that the host does the decapsulation and transparently
gives the container a virtual ethernet device, which keeps the hardware
and the "socket" in the same ns.
> But anyways, the vastness of the key is why we want to keep "sockets"
> out of network cards, because proper support of "sockets" requires
> access to information the card simply does not and should not have.

I think Tom's talk of "sockets" is a red herring; it's more a question of
"flows".  If we think of our host as a black box, its decisions ("is this
traffic encapsulated?") necessarily depend upon the 5-tuple plus the
(implicit) information that the traffic is being received on a particular
interface.
Netns are another red herring: even without them, what if our host is a
router with NAT, forwarding traffic to another host?  Now you're trying to
match a "socket" on another host (in, perhaps, another IP-address
namespace), but the "flow" is still the same: it's defined in terms of the
addresses on the incoming traffic, not what they might get NATted to by
the time the packets hit an actual socket.

So AFAICT, flow matching up to and including 5-tuple is both necessary and
sufficient for correct UDP tunnel detection in HW.  Sadly most HW
(including our latest here at sfc) thinks it only needs UDP dest port :(
and for such HW, Tom is right that we can't mix it with forwarding, and
have to reserve the port in all ns.

-Ed



Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

2016-06-21 Thread Wei Hu (Xavier)



On 2016/6/20 21:33, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:

This patch added the operation for cmd, and added some functions
for initializing eq table and selecting cmd mode.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---
PATCH v9/v8/v7/v6:
- No change over the PATCH v5

PATCH v5:
- The initial patch which was redesigned based on the second patch
   in PATCH v4
---

<...>


+#define CMD_MAX_NUM32
+
+int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
+{
+   struct device *dev = _dev->pdev->dev;
+
+   mutex_init(_dev->cmd.hcr_mutex);
+   sema_init(_dev->cmd.poll_sem, 1);
+   hr_dev->cmd.use_events = 0;
+   hr_dev->cmd.toggle = 1;
+   hr_dev->cmd.max_cmds = CMD_MAX_NUM;

<...>


+   for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
+hr_cmd->token_mask <<= 1)
+   ;
+   --hr_cmd->token_mask;

It doesn't look that you dynamically change max_cmds supported.
Why do you need to calculate token_mask dynamically?

Hi, Leon

1. The four lines above are in the function named 
hns_roce_cmd_use_events.

 and now this function is only called once in hns_roce_probe.
2. In hns_roce_cmd_use_events,
we use these 4 lines to achieve the value of hr_cmd->token_mask 
according to hr_cmd->max_cmds dynamically,

then we only define one marco for hr_cmd->max_cmds as below:

#define CMD_MAX_NUM 32

   And it looks more flexible.

Regards
Wei Hu





[PATCH net-next] net/mlx4_en: Add DCB PFC support through CEE netlink commands

2016-06-21 Thread Tariq Toukan
From: Rana Shahout 

This patch adds support for reading and updating priority flow
control (PFC) attributes in the driver via netlink.

Signed-off-by: Rana Shahout 
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Eugenia Emantayev 
Signed-off-by: Tariq Toukan 
---
 drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 277 +++--
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c |  25 +++
 drivers/net/ethernet/mellanox/mlx4/fw.c|   1 +
 drivers/net/ethernet/mellanox/mlx4/fw.h|   1 +
 drivers/net/ethernet/mellanox/mlx4/main.c  |   1 +
 drivers/net/ethernet/mellanox/mlx4/mlx4_en.h   |  26 +++
 drivers/net/ethernet/mellanox/mlx4/port.c  |  12 ++
 include/linux/mlx4/device.h|   2 +
 8 files changed, 331 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c 
b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
index f01918c..99c6bbd 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
@@ -37,6 +37,11 @@
 #include "mlx4_en.h"
 #include "fw_qos.h"
 
+enum {
+   MLX4_CEE_STATE_DOWN   = 0,
+   MLX4_CEE_STATE_UP = 1,
+};
+
 /* Definitions for QCN
  */
 
@@ -80,13 +85,202 @@ struct 
mlx4_congestion_control_mb_prio_802_1_qau_statistics {
__be32 reserved3[4];
 };
 
+static u8 mlx4_en_dcbnl_getcap(struct net_device *dev, int capid, u8 *cap)
+{
+   struct mlx4_en_priv *priv = netdev_priv(dev);
+
+   switch (capid) {
+   case DCB_CAP_ATTR_PFC:
+   *cap = true;
+   break;
+   case DCB_CAP_ATTR_DCBX:
+   *cap = priv->cee_params.dcbx_cap;
+   break;
+   case DCB_CAP_ATTR_PFC_TCS:
+   *cap = 1 <<  mlx4_max_tc(priv->mdev->dev);
+   break;
+   default:
+   *cap = false;
+   break;
+   }
+
+   return 0;
+}
+
+static u8 mlx4_en_dcbnl_getpfcstate(struct net_device *netdev)
+{
+   struct mlx4_en_priv *priv = netdev_priv(netdev);
+
+   return priv->cee_params.dcb_cfg.pfc_state;
+}
+
+static void mlx4_en_dcbnl_setpfcstate(struct net_device *netdev, u8 state)
+{
+   struct mlx4_en_priv *priv = netdev_priv(netdev);
+
+   priv->cee_params.dcb_cfg.pfc_state = state;
+}
+
+static void mlx4_en_dcbnl_get_pfc_cfg(struct net_device *netdev, int priority,
+ u8 *setting)
+{
+   struct mlx4_en_priv *priv = netdev_priv(netdev);
+
+   *setting = priv->cee_params.dcb_cfg.tc_config[priority].dcb_pfc;
+}
+
+static void mlx4_en_dcbnl_set_pfc_cfg(struct net_device *netdev, int priority,
+ u8 setting)
+{
+   struct mlx4_en_priv *priv = netdev_priv(netdev);
+
+   priv->cee_params.dcb_cfg.tc_config[priority].dcb_pfc = setting;
+   priv->cee_params.dcb_cfg.pfc_state = true;
+}
+
+static int mlx4_en_dcbnl_getnumtcs(struct net_device *netdev, int tcid, u8 
*num)
+{
+   struct mlx4_en_priv *priv = netdev_priv(netdev);
+
+   if (!(priv->flags & MLX4_EN_FLAG_DCB_ENABLED))
+   return -EINVAL;
+
+   if (tcid == DCB_NUMTCS_ATTR_PFC)
+   *num = mlx4_max_tc(priv->mdev->dev);
+   else
+   *num = 0;
+
+   return 0;
+}
+
+static u8 mlx4_en_dcbnl_set_all(struct net_device *netdev)
+{
+   struct mlx4_en_priv *priv = netdev_priv(netdev);
+   struct mlx4_en_dev *mdev = priv->mdev;
+   struct mlx4_en_cee_config *dcb_cfg = >cee_params.dcb_cfg;
+   int err = 0;
+
+   if (!(priv->cee_params.dcbx_cap & DCB_CAP_DCBX_VER_CEE))
+   return -EINVAL;
+
+   if (dcb_cfg->pfc_state) {
+   int tc;
+
+   priv->prof->rx_pause = 0;
+   priv->prof->tx_pause = 0;
+   for (tc = 0; tc < CEE_DCBX_MAX_PRIO; tc++) {
+   u8 tc_mask = 1 << tc;
+
+   switch (dcb_cfg->tc_config[tc].dcb_pfc) {
+   case pfc_disabled:
+   priv->prof->tx_ppp &= ~tc_mask;
+   priv->prof->rx_ppp &= ~tc_mask;
+   break;
+   case pfc_enabled_full:
+   priv->prof->tx_ppp |= tc_mask;
+   priv->prof->rx_ppp |= tc_mask;
+   break;
+   case pfc_enabled_tx:
+   priv->prof->tx_ppp |= tc_mask;
+   priv->prof->rx_ppp &= ~tc_mask;
+   break;
+   case pfc_enabled_rx:
+   priv->prof->tx_ppp &= ~tc_mask;
+   priv->prof->rx_ppp |= tc_mask;
+   break;
+   default:
+   break;
+   }
+

Re: 802.3ad bonding aggregator reselection

2016-06-21 Thread Veli-Matti Lintu
2016-06-20 17:11 GMT+03:00 zhuyj :
> 5. Switch Configuration
> ===
>
> For this section, "switch" refers to whatever system the
> bonded devices are directly connected to (i.e., where the other end of
> the cable plugs into).  This may be an actual dedicated switch device,
> or it may be another regular system (e.g., another computer running
> Linux),
>
> The active-backup, balance-tlb and balance-alb modes do not
> require any specific configuration of the switch.
>
> The 802.3ad mode requires that the switch have the appropriate
> ports configured as an 802.3ad aggregation.  The precise method used
> to configure this varies from switch to switch, but, for example, a
> Cisco 3550 series switch requires that the appropriate ports first be
> grouped together in a single etherchannel instance, then that
> etherchannel is set to mode "lacp" to enable 802.3ad (instead of
> standard EtherChannel).

The ports are configured in switch settings (HP Procurve 2530-48G) in
same trunk group (TrkX) and trunk group type is set as LACP.
/proc/net/bonding/bond0 also shows that the three ports belong to same
aggregator and bandwidth tests also support this. In my understanding
Procurve's trunk group is pretty much the same as etherchannel in
Cisco's terminology. The bonded link comes always up properly, but
handling of links going down is the problem. Are there known
differences between different vendors there?

Veli-Matti


[PATCH 2/2] ath6kl: replace semaphore with mutex

2016-06-21 Thread Chaehyun Lim
It replaces struct semaphore sem with struct mutex mutex

Signed-off-by: Chaehyun Lim 
---
 drivers/net/wireless/ath/ath6kl/cfg80211.c | 30 +++---
 drivers/net/wireless/ath/ath6kl/core.c |  2 +-
 drivers/net/wireless/ath/ath6kl/core.h |  2 +-
 drivers/net/wireless/ath/ath6kl/debug.c| 12 ++--
 drivers/net/wireless/ath/ath6kl/init.c |  6 +++---
 5 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f6b5390..d4eb066 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -480,14 +480,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
return -EINVAL;
}
 
-   if (down_interruptible(>sem)) {
+   if (mutex_lock_interruptible(>mutex)) {
ath6kl_err("busy, couldn't get access\n");
return -ERESTARTSYS;
}
 
if (test_bit(DESTROY_IN_PROGRESS, >flag)) {
ath6kl_err("busy, destroy in progress\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EBUSY;
}
 
@@ -500,14 +500,14 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
 WMI_TIMEOUT);
if (signal_pending(current)) {
ath6kl_err("cmd queue drain timeout\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EINTR;
}
}
 
status = ath6kl_set_assoc_req_ies(vif, sme->ie, sme->ie_len);
if (status) {
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
 
@@ -522,7 +522,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
  vif->req_bssid,
  vif->ch_hint);
 
-   up(>sem);
+   mutex_unlock(>mutex);
if (status) {
ath6kl_err("wmi_reconnect_cmd failed\n");
return -EIO;
@@ -548,7 +548,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
 
status = ath6kl_set_auth_type(vif, sme->auth_type);
if (status) {
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
 
@@ -570,7 +570,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
if (sme->key_idx > WMI_MAX_KEY_INDEX) {
ath6kl_err("key index %d out of bounds\n",
   sme->key_idx);
-   up(>sem);
+   mutex_unlock(>mutex);
return -ENOENT;
}
 
@@ -594,7 +594,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
if (ath6kl_wmi_bssfilter_cmd(ar->wmi, vif->fw_vif_idx,
 ALL_BSS_FILTER, 0) != 0) {
ath6kl_err("couldn't set bss filtering\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return -EIO;
}
}
@@ -626,7 +626,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
   0);
if (status) {
ath6kl_err("couldn't set listen intervel\n");
-   up(>sem);
+   mutex_unlock(>mutex);
return status;
}
}
@@ -651,7 +651,7 @@ static int ath6kl_cfg80211_connect(struct wiphy *wiphy, 
struct net_device *dev,
ath6kl_wmi_scanparams_cmd(ar->wmi, vif->fw_vif_idx, 0, 0,
  sme->bg_scan_period, 0, 0, 0, 3, 0, 0, 0);
 
-   up(>sem);
+   mutex_unlock(>mutex);
 
if (status == -EINVAL) {
memset(vif->ssid, 0, sizeof(vif->ssid));
@@ -832,7 +832,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
return -EBUSY;
}
 
-   if (down_interruptible(>sem)) {
+   if (mutex_lock_interruptible(>mutex)) {
ath6kl_err("busy, couldn't get access\n");
return -ERESTARTSYS;
}
@@ -845,7 +845,7 @@ static int ath6kl_cfg80211_disconnect(struct wiphy *wiphy,
if (!test_bit(SKIP_SCAN, >flag))
memset(vif->req_bssid, 0, sizeof(vif->req_bssid));
 
-   up(>sem);
+   mutex_unlock(>mutex);
 
vif->sme_state = SME_DISCONNECTED;
 
@@ -1775,7 +1775,7 @@ static int ath6kl_get_station(struct wiphy *wiphy, struct 
net_device *dev,
if (memcmp(mac, 

Re: [PATCH v10 08/22] IB/hns: Add icm support

2016-06-21 Thread Leon Romanovsky
On Tue, Jun 21, 2016 at 12:37:39PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/20 21:04, Leon Romanovsky wrote:
> >On Mon, Jun 20, 2016 at 05:48:15PM +0800, Wei Hu (Xavier) wrote:
> >>
> >>On 2016/6/20 17:27, Leon Romanovsky wrote:
> >>>On Mon, Jun 20, 2016 at 03:49:24PM +0800, Wei Hu (Xavier) wrote:
> On 2016/6/20 14:06, Leon Romanovsky wrote:
> >On Mon, Jun 20, 2016 at 12:37:40PM +0800, Wei Hu (Xavier) wrote:
> >>On 2016/6/17 17:58, Leon Romanovsky wrote:
> >>>On Thu, Jun 16, 2016 at 10:35:16PM +0800, Lijun Ou wrote:
> This patch mainly added icm support for RoCE. It initializes icm
> which managers the relative memory blocks for RoCE. The data
> structures of RoCE will be located in it. For example, CQ table,
> QP table and MTPT table so on.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> >>><...>
> >>>
> +
> >Another question which you didn't answer [1].
> >
> >"I wonder if you have the same needs for ICM as it is in mlx4 device.
> >Do you have firmware?"
> >
> >[1] http://marc.info/?l=linux-rdma=146545553104913=2
> Hi, Leon
>  Now we haven't firmware.
>  But hardware still need memory for QPC\CQC\MTPT\mtt etc.
> >>>ICM stands for InfiniHost (Interconnect) Context Memory is a specific
> >>>memory place to share between host <-> FW and host <-> HW if HW is
> >>>aware of specific structures.
> >>>
> >>>I assume that in your case, it is enough to allocate memory region and
> >>>supply it to HW. Am I right?
> >>For Our hardware,
> >>1. ICM has a memory management method, It's very good for QPC\CQC\MTPT\mtt
> >>etc. we need it.
> >You need special HW to leverage its. AFAIK it is Mellanox specific.
> For our hardware, we use ICM to memory management, the memory shared with
> host and HW.
> QPC\CQC\MTPT\mtt has specific memory requirement.
> QPC\CQC\MTPT need continuous memory. we use ICM to management the block of
> memory. It's very good!

I wasn't convinced why do you need to copy whole ICM logic which is
specific to Mellanox. Your requirements can be implemented by standard CMA
and/or DMA.

> >>2. The meomry for QPC\CQC\MTPT\mtt only used for RoCE hardware and driver,
> >>we don't want use MR.
> >I didn't mean Infiniband MR, but memory region returned from standard
> >allocation functions (kmalloc, ...).
> >
> >>3. Now we haven't firmware, maybe we need it next version.
> >You are always invited to add support once it will be needed, no need to
> >add it in advance.
> >
> >Thanks
> 
> 


signature.asc
Description: Digital signature


Re: [PATCH 2/2] ath6kl: replace semaphore with mutex

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.7-rc4 next-20160621]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chaehyun-Lim/ath10k-remove-unused-linux-semaphore-h/20160621-195511
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/ath/ath6kl/debug.c: In function 
'ath6kl_roam_table_read':
>> drivers/net/wireless/ath/ath6kl/debug.c:1177:19: error: 'struct ath6kl' has 
>> no member named 'sem'
  mutex_unlock(>sem);
  ^

vim +1177 drivers/net/wireless/ath/ath6kl/debug.c

  1171  return -EBUSY;
  1172  
  1173  set_bit(ROAM_TBL_PEND, >flag);
  1174  
  1175  ret = ath6kl_wmi_get_roam_tbl_cmd(ar->wmi);
  1176  if (ret) {
> 1177  mutex_unlock(>sem);
  1178  return ret;
  1179  }
  1180  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH net-next 01/19] net: hns: bug fix of ge reset sequence

2016-06-21 Thread Andy Shevchenko
On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote:
> From: Qianqian Xie 
> 
> The bit fileds of PPE reset register are different between HNS v1 and
> HNS v2, but the current procedure just only match HNS v1. Here is a
> patch to fix it.
> 
> Signed-off-by: Kejian Yan 
> Signed-off-by: Qianqian Xie 
> Signed-off-by: Yisen Zhuang 
> ---
>  drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> index 96cb628..09e60d6 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
> @@ -271,7 +271,11 @@ static void hns_dsaf_ge_srst_by_port(struct
> dsaf_device *dsaf_dev, u32 port,
>   }
>   } else {
>   reg_val_1 = 0x15540 << dsaf_dev->reset_offset;
> - reg_val_2 = 0x100 << dsaf_dev->reset_offset;
> +
> + if (AE_IS_VER1(dsaf_dev->dsaf_ver))
> + reg_val_2 = 0x100 << dsaf_dev->reset_offset;
> + else
> + reg_val_2 = 0x40 << dsaf_dev->reset_offset;

reg_val_1 = 0x15540;
reg_val_2 = AE_IS_VER1(dsaf_dev->dsaf_ver) ? 0x100 : 0x40;

reg_val_1 <<= dsaf_dev->reset_offset;
reg_val_2 <<= dsaf_dev-
>reset_offset;


>  
>   if (!dereset) {
>   dsaf_write_sub(dsaf_dev,
> DSAF_SUB_SC_GE_RESET_REQ1_REG,

-- 

Andy Shevchenko 
Intel Finland Oy


pull-request: wireless-drivers 2016-06-21

2016-06-21 Thread Kalle Valo
Hi Dave,

here is a pull request for 4.7, really small fixes this time, some of
them fix important regressions. Please let me know if there are any
problems.

Kalle

The following changes since commit 182fd9eecb287e696c82b30d06c6150d80a49c5b:

  MAINTAINERS: Add file patterns for wireless device tree bindings (2016-06-04 
17:24:02 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2016-06-21

for you to fetch changes up to 034fdd4a17ff089c2428ece18efa65c5396810d2:

  Merge ath-current from ath.git (2016-06-16 17:55:19 +0300)



wireless-drivers fixes for 4.7

iwlwifi

* fix the scan timeout for long scans
* fix an RCU splat caused when updating the TKIP key
* fix a potential NULL-derefence introduced recently
* fix a IGTK key bug that has existed since the MVM driver was introduced
* fix some fw capabilities checks that got accidentally inverted

rtl8xxxu

* fix typo on variable name

ath10k

* fix deadlock when peer cannot be created
* fix crash related to printing features
* fix deadlock while processing rx_in_ord_ind

ath9k

* fix GPIO mask regression for AR9462 and AR9565


Ayala Beker (1):
  iwlwifi: mvm: set the encryption type of an IGTK key

Ben Greear (2):
  ath10k: fix deadlock when peer cannot be created
  ath10k: fix crash related to printing features

Colin Ian King (1):
  rtl8xxxu: fix typo on variable name, compare against correct variable

Emmanuel Grumbach (1):
  iwlwifi: mvm: fix RCU splat in TKIP's update_key

Johannes Berg (1):
  iwlwifi: mvm: fix a few firmware capability checks

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2016-06-10' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge ath-current from ath.git

Luca Coelho (2):
  iwlwifi: mvm: increase scan timeout to 20 seconds
  iwlwifi: mvm: fix potential NULL-dereference in iwl_mvm_reorder()

Miaoqing Pan (1):
  ath9k: fix GPIO mask for AR9462 and AR9565

Rajkumar Manoharan (1):
  ath10k: fix deadlock while processing rx_in_ord_ind

 drivers/net/wireless/ath/ath10k/core.c |2 +-
 drivers/net/wireless/ath/ath10k/htt_rx.c   |1 -
 drivers/net/wireless/ath/ath10k/mac.c  |2 +-
 drivers/net/wireless/ath/ath9k/reg.h   |8 
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |8 
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |4 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c  |2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |   16 +++-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c |2 +-
 9 files changed, 30 insertions(+), 15 deletions(-)


pull-request: wireless-drivers-next 2016-06-21

2016-06-21 Thread Kalle Valo
Hi Dave,

I hope it's ok to send two pull requests the same day, both for net and
net-next? This is targeted to 4.8 so it is for net-next.

Even though is this the first pull request for 4.8 we actually remove
more code than add, thanks to Guenter Roeck's on removing unused "phy_a"
support from b43. Otherwise there's not really anything standing out,
adding new chipset support to brcmfmac and ath10k, lots of fixes and the
usual.

Please let me know if there any issues.

Kalle

The following changes since commit 76f21b99004ef1f16be6184678f660eab911b8b8:

  net: Add docbook description for 'mtu' arg to skb_gso_validate_mtu() 
(2016-06-03 22:56:28 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2016-06-21

for you to fetch changes up to 1bb57c8a5e33bcbec031ce0c629968922d5af89d:

  Merge ath-next from ath.git (2016-06-19 11:19:30 +0300)



wireless-drivers patches for 4.8

Major changes:

ath10k

* enable btcoex support without restarting firmware
* enable ipq4019 support using AHB bus
* add QCA9887 chipset support
* retrieve calibration data from EEPROM, currently only for QCA9887

wil6210

* add pm_notify handling

brcmfmac

* add support for the PCIE devices 43525 and 43465


Adrian Chadd (1):
  b43: don't unconditionally fall back to CCK if the rate is 6MB OFDM.

Amitkumar Karwar (1):
  mwifiex: inform disconnection initiator correctly.

Arend van Spriel (1):
  brcm80211: update maintainers email addresses

Arnd Bergmann (4):
  iwlegacy: avoid warning about missing braces
  wl3501_cs: avoid bogus gcc-6 warning
  rtlwifi: fix error handling in *_read_adapter_info()
  mwifiex: fix link error against sdio

Ashok Raj Nagarajan (1):
  ath10k: fix diag_read to collect data for larger memory

Bhaktipriya Shridhar (1):
  libertas: Remove create_workqueue

Bob Copeland (1):
  ath5k: fix misplaced default label in sifs switch

Christian Daudt (2):
  brcmfmac: Fix kernel oops in failed chip_attach
  brcmfmac: Fix 'did not remove int handler' warning

Eduardo Abinader (3):
  ath9k: Remove empty test condition
  ath9k: allow tx99 for ar9002 based cards
  ath9k: Proper TX99 interrupt ref count

Guenter Roeck (3):
  libertas_tf: Drop unused variable and define
  b43: Remove unused phy_a code
  b43: Completely remove support for phy_a

Hante Meuleman (2):
  brcmfmac: fix skb priority handling
  brcmfmac: add support for the PCIE devices 43525 and 43465

Heinrich Schuchardt (7):
  ath6kl: simplify logical condition
  rsi: eliminate superfluous NULL check
  mwifiex: illegal assignment
  rtlwifi: rtl8723be: avoid undefined behavior
  mwiflex: avoid possible null pointer dereference
  rtlwifi: rtl8192ee: simplify coding
  brcm80211: simplify assignment

Javier Martinez Canillas (8):
  mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
  mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()
  mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()
  mwifiex: consolidate mwifiex_sdio_probe() error paths
  mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
  mwifiex: check if mwifiex_sdio_probe_of() fails and return error
  mwifiex: don't print an error if an optional DT property is missing
  mwifiex: use better message and error code when OF node doesn't match

Julia Lawall (2):
  ath6kl: fix typo
  mwifiex: fix typo

Kalle Valo (1):
  Merge ath-next from ath.git

Lauri Kasanen (1):
  carl9170: Clarify kconfig text

Lior David (1):
  wil6210: abort P2P search when stopping P2P device

Lucas Stach (1):
  b43: only hardcode LED behavior if SPROM doesn't encode any

Mathias Krause (1):
  mwifiex: remove misleading GFP_DMA flag in buffer allocations

Maya Erez (7):
  wil6210: fix race conditions between TX send and completion
  wil6210: guarantee safe access to rx descriptors shared memory
  wil6210: protect wil_vring_fini_tx in parallel to tx completions
  wil6210: fix dma mapping error cleanup in __wil_tx_vring_tso
  wil6210: add pm_notify handling
  wil6210: align wil log functions to wil_dbg_ratelimited implementation
  wil6210: fix chan check in wil_p2p_listen

Michal Kazior (1):
  ath10k: improve tx scheduling

Mohammed Shafi Shajakhan (5):
  ath10k: reduce warning messages during rx without proper channel context
  ath10k: fix legacy rate packet debug messages
  ath10k: fix error while writing 'simulate_fw_crash' debugfs
  ath10k: remove duplicate and unused rx rate flags
  ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets

Muhammad Falak R Wani (1):
  brcmfmac: use kmemdup

Rafał Miłecki 

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

2016-06-21 Thread Michael Ellerman
On Tue, 2016-06-21 at 14:28 +0530, Naveen N. Rao wrote:
> On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> > On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > Hi, Michael and Naveen.
> > > > 
> > > > I noticed independently that there is a problem with BPF JIT and ABIv2, 
> > > > and
> > > > worked out the patch below before I noticed Naveen's patchset and the 
> > > > latest
> > > > changes in ppc tree for a better way to check for ABI versions.
> > > > 
> > > > However, since the issue described below affect mainline and stable 
> > > > kernels,
> > > > would you consider applying it before merging your two patchsets, so 
> > > > that we can
> > > > more easily backport the fix?
> > > 
> > > Hi Cascardo,
> > > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > > fixing it. But, I can see why this would be a good thing to have for 
> > > -stable and existing distros. However, while your patch below may fix 
> > > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > > changes in bpf_jit_asm.S as well.
> > 
> > Hi, Naveen.
> > 
> > Any tips on how to exercise possible issues there? Or what changes you think
> > would be sufficient?
> 
> The calling convention is different with ABIv2 and so we'll need changes 
> in bpf_slow_path_common() and sk_negative_common().

How big would those changes be? Do we know?

How come no one reported this was broken previously? This is the first I've
heard of it being broken.

> However, rather than enabling classic JIT for ppc64le, are we better off 
> just disabling it?
> 
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -128,7 +128,7 @@ config PPC
> select IRQ_FORCED_THREADING
> select HAVE_RCU_TABLE_FREE if SMP
> select HAVE_SYSCALL_TRACEPOINTS
> -   select HAVE_CBPF_JIT
> +   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> select HAVE_ARCH_JUMP_LABEL
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_HAS_GCOV_PROFILE_ALL
> 
> 
> Michael,
> Let me know your thoughts on whether you intend to take this patch or 
> Cascardo's patch for -stable before the eBPF patches. I can redo my 
> patches accordingly.

This patch sounds like the best option at the moment for something we can
backport. Unless the changes to fix it are minimal.

cheers



Re: [PATCH 15/15] ARM: dts: am335x/am437x/dra7: use new "ti,cpsw-mdio" compat string

2016-06-21 Thread Tony Lindgren
* Grygorii Strashko  [160615 05:05]:
> Add "ti,cpsw-mdio" for am335x/am437x/dra7 SoCs where MDIO is
> implemented as part of TI CPSW and, this way, enable PM runtime auto
> suspend for Davinci MDIO driver on these paltforms.

This one should not cause merge conflicts, please feel free
to merge along with the other CPSW driver patches after the
pending comments are dealt with:

Acked-by: Tony Lindgren 


Re: [PATCH net-next] net/mlx4_en: Add DCB PFC support through CEE netlink commands

2016-06-21 Thread Or Gerlitz
On Tue, Jun 21, 2016 at 2:12 PM, Tariq Toukan  wrote:
> From: Rana Shahout 
>
> This patch adds support for reading and updating priority flow
> control (PFC) attributes in the driver via netlink.

The patch does multiple things, you need to break it to few patches, I
guess 2-3 patches could be fine, e.g

1. changes to areas areas where you read new values from the FW
2. changes/refactoring to the IEEE code to make some of the callbacks general
3. add CEE code and usage of the code you added in steps 1,2 above



> ---
>  drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c | 277 
> +++--
>  drivers/net/ethernet/mellanox/mlx4/en_netdev.c |  25 +++
>  drivers/net/ethernet/mellanox/mlx4/fw.c|   1 +
>  drivers/net/ethernet/mellanox/mlx4/fw.h|   1 +
>  drivers/net/ethernet/mellanox/mlx4/main.c  |   1 +
>  drivers/net/ethernet/mellanox/mlx4/mlx4_en.h   |  26 +++
>  drivers/net/ethernet/mellanox/mlx4/port.c  |  12 ++
>  include/linux/mlx4/device.h|   2 +
>  8 files changed, 331 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c 
> b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
> index f01918c..99c6bbd 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
> @@ -37,6 +37,11 @@
>  #include "mlx4_en.h"
>  #include "fw_qos.h"
>
> +enum {
> +   MLX4_CEE_STATE_DOWN   = 0,
> +   MLX4_CEE_STATE_UP = 1,
> +};
> +
>  /* Definitions for QCN
>   */
>
> @@ -80,13 +85,202 @@ struct 
> mlx4_congestion_control_mb_prio_802_1_qau_statistics {
> __be32 reserved3[4];
>  };
>
> +static u8 mlx4_en_dcbnl_getcap(struct net_device *dev, int capid, u8 *cap)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(dev);
> +
> +   switch (capid) {
> +   case DCB_CAP_ATTR_PFC:
> +   *cap = true;
> +   break;
> +   case DCB_CAP_ATTR_DCBX:
> +   *cap = priv->cee_params.dcbx_cap;
> +   break;
> +   case DCB_CAP_ATTR_PFC_TCS:
> +   *cap = 1 <<  mlx4_max_tc(priv->mdev->dev);
> +   break;
> +   default:
> +   *cap = false;
> +   break;
> +   }
> +
> +   return 0;
> +}
> +
> +static u8 mlx4_en_dcbnl_getpfcstate(struct net_device *netdev)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(netdev);
> +
> +   return priv->cee_params.dcb_cfg.pfc_state;
> +}
> +
> +static void mlx4_en_dcbnl_setpfcstate(struct net_device *netdev, u8 state)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(netdev);
> +
> +   priv->cee_params.dcb_cfg.pfc_state = state;
> +}
> +
> +static void mlx4_en_dcbnl_get_pfc_cfg(struct net_device *netdev, int 
> priority,
> + u8 *setting)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(netdev);
> +
> +   *setting = priv->cee_params.dcb_cfg.tc_config[priority].dcb_pfc;
> +}
> +
> +static void mlx4_en_dcbnl_set_pfc_cfg(struct net_device *netdev, int 
> priority,
> + u8 setting)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(netdev);
> +
> +   priv->cee_params.dcb_cfg.tc_config[priority].dcb_pfc = setting;
> +   priv->cee_params.dcb_cfg.pfc_state = true;
> +}
> +
> +static int mlx4_en_dcbnl_getnumtcs(struct net_device *netdev, int tcid, u8 
> *num)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(netdev);
> +
> +   if (!(priv->flags & MLX4_EN_FLAG_DCB_ENABLED))
> +   return -EINVAL;
> +
> +   if (tcid == DCB_NUMTCS_ATTR_PFC)
> +   *num = mlx4_max_tc(priv->mdev->dev);
> +   else
> +   *num = 0;
> +
> +   return 0;
> +}
> +
> +static u8 mlx4_en_dcbnl_set_all(struct net_device *netdev)
> +{
> +   struct mlx4_en_priv *priv = netdev_priv(netdev);
> +   struct mlx4_en_dev *mdev = priv->mdev;
> +   struct mlx4_en_cee_config *dcb_cfg = >cee_params.dcb_cfg;
> +   int err = 0;
> +
> +   if (!(priv->cee_params.dcbx_cap & DCB_CAP_DCBX_VER_CEE))
> +   return -EINVAL;
> +
> +   if (dcb_cfg->pfc_state) {
> +   int tc;
> +
> +   priv->prof->rx_pause = 0;
> +   priv->prof->tx_pause = 0;
> +   for (tc = 0; tc < CEE_DCBX_MAX_PRIO; tc++) {
> +   u8 tc_mask = 1 << tc;
> +
> +   switch (dcb_cfg->tc_config[tc].dcb_pfc) {
> +   case pfc_disabled:
> +   priv->prof->tx_ppp &= ~tc_mask;
> +   priv->prof->rx_ppp &= ~tc_mask;
> +   break;
> +   case pfc_enabled_full:
> +   priv->prof->tx_ppp |= tc_mask;
> +   priv->prof->rx_ppp |= tc_mask;
> +   break;
> +   case pfc_enabled_tx:
> +

Re: [PATCH] rxrpc: fix uninitialized variable use

2016-06-21 Thread David Howells
Arnd Bergmann  wrote:

> Hashing the peer key was introduced for AF_INET, but gcc
> warns about the rxrpc_peer_hash_key function returning uninitialized
> data for any other value of srx->transport.family:
> 
> net/rxrpc/peer_object.c: In function 'rxrpc_peer_hash_key':
> net/rxrpc/peer_object.c:57:15: error: 'p' may be used uninitialized in this 
> function [-Werror=maybe-uninitialized]
> 
> Assuming that nothing else can be set here, this changes the
> function to just return zero in case of an unknown address
> family.

I'm actually more tempted to put a BUG() in there because if any new family
support (say AF_INET6) is added, I want to make sure I catch all the places.

David


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

2016-06-21 Thread Arnd Bergmann
On Tuesday, June 21, 2016 11:18:39 AM CEST Stephen Rothwell wrote:
> Today's linux-next merge of the net-next tree got conflicts in:
> 
>   arch/arm64/boot/dts/broadcom/ns2-svk.dts
>   arch/arm64/boot/dts/broadcom/ns2.dtsi
> 
> between commits:
> 
>   97b1504a30b3 ("arm64: dts: enable pinctrl for Broadcom NS2 SoC")
>   5dcc9c7618df ("arm64: dts: NS2: Add CCI-400 PMU support")
> 
> from the arm-soc tree and commit:
> 
>   5f1a067bfa0a ("dt: mdio-mux: Add mdio multiplexer driver 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.

Looks good to me, thanks!

I don't see a good way to resolve the conflict before the merge window,
but it's simple enough that we can just send it this way and let
Linus handle it.

Arnd



Re: [patch net-next] rxrpc: checking for IS_ERR() instead of NULL

2016-06-21 Thread David Howells
Dan Carpenter  wrote:

> rxrpc_lookup_peer_rcu() returns NULL on error, it never returns error
> pointers.
> 
> Fixes: be6e6707f6ee ('rxrpc: Rework peer object handling to use hash table 
> and RCU')
> Signed-off-by: Dan Carpenter 

Applied.


Re: [patch net-next 00/23] mlxsw: Preparation for IPv4 router

2016-06-21 Thread David Miller
From: Jiri Pirko 
Date: Mon, 20 Jun 2016 23:03:58 +0200

> From: Jiri Pirko 
> 
> Ido says:
> 
> This series prepares the driver for IPv4 router support. The router follow-up
> patches are available at: 
> https://github.com/jpirko/linux_mlxsw/tree/net-next_queue
 ...

Looks good, series applied, thanks.


Re: [PATCH] rxrpc: fix uninitialized variable use

2016-06-21 Thread Arnd Bergmann
On Tuesday, June 21, 2016 9:48:52 AM CEST David Howells wrote:
> Arnd Bergmann  wrote:
> 
> > Hashing the peer key was introduced for AF_INET, but gcc
> > warns about the rxrpc_peer_hash_key function returning uninitialized
> > data for any other value of srx->transport.family:
> > 
> > net/rxrpc/peer_object.c: In function 'rxrpc_peer_hash_key':
> > net/rxrpc/peer_object.c:57:15: error: 'p' may be used uninitialized in this 
> > function [-Werror=maybe-uninitialized]
> > 
> > Assuming that nothing else can be set here, this changes the
> > function to just return zero in case of an unknown address
> > family.
> 
> I'm actually more tempted to put a BUG() in there because if any new family
> support (say AF_INET6) is added, I want to make sure I catch all the places.

Makes sense. Do you want to do the patch yourself, or should I send
a new one doing that?

Maybe WARN() would be better than BUG()? That would still get the attention
it needs but not kill the process.

Arnd



[PATCH 1/2] ath10k: remove unused

2016-06-21 Thread Chaehyun Lim
 is not used anymore, so just remove it.

Signed-off-by: Chaehyun Lim 
---
 drivers/net/wireless/ath/ath10k/htc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index cc82718..0c55cd9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 struct ath10k;
-- 
2.9.0



Re: [PATCH] net: stmmac: dwmac-rk: add rk322x-specific data

2016-06-21 Thread Xing Zheng

Hi Heiko,

On 2016年06月21日 17:43, Heiko Stübner wrote:

devicetree names are normally expected to be real, aka no "x" as catchall. So
I guess either just add compatibles for both the rk3228 and rk3229 which point
to the same structure in the driver. (So driver-side can stay as it is below,
just add a second compatible).
OK, I try to just use "rockchip,rk3228-gmac" to point to "rk322x_ops" 
which is the same structure in MAC driver,

and both rk3228 and rk3229 use it.

Thanks

--
- Xing Zheng




Re: [PATCH V4 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

2016-06-21 Thread Arnd Bergmann
On Tuesday, June 21, 2016 1:46:11 AM CEST th...@altera.com wrote:
> diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt 
> b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> index 72d82d6..dd10f2f 100644
> --- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
> @@ -17,9 +17,26 @@ Required properties:
>  Optional properties:
>  altr,emac-splitter: Should be the phandle to the emac splitter soft IP node 
> if
>   DWMAC controller is connected emac splitter.
> +phy-mode: The phy mode the ethernet operates in
> +altr,sgmii_to_sgmii_converter: phandle to the TSE SGMII converter
> +

Please use '-' instead of '_' in the property names.

Can you explain in the patch description why you can't reference
the converter using the normal "phy-handle" property and implement
the converter as a phy driver?

Arnd



Re: [PATCH v4 00/19] CALIPSO Implementation

2016-06-21 Thread David Miller
From: Huw Davies 
Date: Mon, 20 Jun 2016 14:36:40 +0100

> This patch series implements RFC 5570 - Common Architecture Label IPv6
> Security Option (CALIPSO).  Its goal is to set MLS sensitivity labels
> on IPv6 packets using a hop-by-hop option.  CALIPSO is very similar to
> its IPv4 cousin CIPSO and much of this series is based on that code.
> 
> To use this you'll need some patches to netlabel-tools that are
> available on the 'working-calipso-v3' branch at:
> https://github.com/netlabel/netlabel_tools .  The protocol has
> changed very slightly from the v2 patches, so please update to the
> latest if you haven't already done so.
> 
> This implementation has been tested against the CALIPSO implementation
> of Solaris Trusted Extensions.
> 
> This patch series is based off v4.6.
 ...

What tree do you expect to integrate this?


[PATCH] include: net: cfg802154: rename ieee802154_llsec_device.hwaddr to extended_addr

2016-06-21 Thread Thomas Rowland
Renamed the ieee802154_llsec_device member 'hwaddr' to 'extended_addr'

Signed-off-by: Thomas Rowland 
---
 include/net/cfg802154.h   |  2 +-
 net/ieee802154/nl802154.c | 15 +--
 net/mac802154/llsec.c |  4 ++--
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/include/net/cfg802154.h b/include/net/cfg802154.h
index 171cd76..1b5bb10 100644
--- a/include/net/cfg802154.h
+++ b/include/net/cfg802154.h
@@ -292,7 +292,7 @@ struct ieee802154_llsec_device {
 
__le16 pan_id;
__le16 short_addr;
-   __le64 hwaddr;
+   __le64 extended_addr;
u32 frame_counter;
bool seclevel_exempt;
 
diff --git a/net/ieee802154/nl802154.c b/net/ieee802154/nl802154.c
index 116187b..f0cb080 100644
--- a/net/ieee802154/nl802154.c
+++ b/net/ieee802154/nl802154.c
@@ -1628,7 +1628,7 @@ static int nl802154_send_device(struct sk_buff *msg, u32 
cmd, u32 portid,
nla_put_le16(msg, NL802154_DEV_ATTR_SHORT_ADDR,
 dev_desc->short_addr) ||
nla_put_le64(msg, NL802154_DEV_ATTR_EXTENDED_ADDR,
-dev_desc->hwaddr, NL802154_DEV_ATTR_PAD) ||
+dev_desc->extended_addr, NL802154_DEV_ATTR_PAD) ||
nla_put_u8(msg, NL802154_DEV_ATTR_SECLEVEL_EXEMPT,
   dev_desc->seclevel_exempt) ||
nla_put_u32(msg, NL802154_DEV_ATTR_KEY_MODE, dev_desc->key_mode))
@@ -1725,8 +1725,7 @@ ieee802154_llsec_parse_device(struct nlattr *nla,
dev->frame_counter = 
nla_get_u32(attrs[NL802154_DEV_ATTR_FRAME_COUNTER]);
dev->pan_id = nla_get_le16(attrs[NL802154_DEV_ATTR_PAN_ID]);
dev->short_addr = nla_get_le16(attrs[NL802154_DEV_ATTR_SHORT_ADDR]);
-   /* TODO rename hwaddr to extended_addr */
-   dev->hwaddr = nla_get_le64(attrs[NL802154_DEV_ATTR_EXTENDED_ADDR]);
+   dev->extended_addr = 
nla_get_le64(attrs[NL802154_DEV_ATTR_EXTENDED_ADDR]);
dev->seclevel_exempt = 
nla_get_u8(attrs[NL802154_DEV_ATTR_SECLEVEL_EXEMPT]);
dev->key_mode = nla_get_u32(attrs[NL802154_DEV_ATTR_KEY_MODE]);
 
@@ -1850,7 +1849,7 @@ nl802154_dump_llsec_devkey(struct sk_buff *skb, struct 
netlink_callback *cb)
 cb->nlh->nlmsg_seq,
 NLM_F_MULTI, rdev,
 wpan_dev->netdev,
-dpos->hwaddr,
+dpos->extended_addr,
 kpos) < 0) {
/* TODO */
err = -EIO;
@@ -1903,9 +1902,7 @@ static int nl802154_add_llsec_devkey(struct sk_buff *skb, 
struct genl_info *info
 
/* TODO be32 */
key.frame_counter = 
nla_get_u32(attrs[NL802154_DEVKEY_ATTR_FRAME_COUNTER]);
-   /* TODO change naming hwaddr -> extended_addr
-* check unique identifier short+pan OR extended_addr
-*/
+   /* TODO check unique identifier short+pan OR extended_addr */
extended_addr = nla_get_le64(attrs[NL802154_DEVKEY_ATTR_EXTENDED_ADDR]);
return rdev_add_devkey(rdev, wpan_dev, extended_addr, );
 }
@@ -1932,9 +1929,7 @@ static int nl802154_del_llsec_devkey(struct sk_buff *skb, 
struct genl_info *info
  _id) < 0)
return -ENOBUFS;
 
-   /* TODO change naming hwaddr -> extended_addr
-* check unique identifier short+pan OR extended_addr
-*/
+   /* TODO check unique identifier short+pan OR extended_addr */
extended_addr = nla_get_le64(attrs[NL802154_DEVKEY_ATTR_EXTENDED_ADDR]);
return rdev_del_devkey(rdev, wpan_dev, extended_addr, );
 }
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index 6a3e1c2..e8a1f76 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -358,13 +358,13 @@ int mac802154_llsec_dev_add(struct mac802154_llsec *sec,
 {
struct mac802154_llsec_device *entry;
u32 skey = llsec_dev_hash_short(dev->short_addr, dev->pan_id);
-   u64 hwkey = llsec_dev_hash_long(dev->hwaddr);
+   u64 hwkey = llsec_dev_hash_long(dev->extended_addr);
 
BUILD_BUG_ON(sizeof(hwkey) != IEEE802154_ADDR_LEN);
 
if ((llsec_dev_use_shortaddr(dev->short_addr) &&
 llsec_dev_find_short(sec, dev->short_addr, dev->pan_id)) ||
-llsec_dev_find_long(sec, dev->hwaddr))
+llsec_dev_find_long(sec, dev->extended_addr))
return -EEXIST;
 
entry = kmalloc(sizeof(*entry), GFP_KERNEL);
-- 
2.1.4



[PATCH net 2/2] net/mlx4_en: Avoid unregister_netdev at shutdown flow

2016-06-21 Thread Tariq Toukan
From: Eran Ben Elisha 

This allows a clean shutdown, even if some netdev clients do not
release their reference from this netdev. It is enough to release
the HW resources only as the kernel is shutting down.

Fixes: 2ba5fbd62b25 ('net/mlx4_core: Handle AER flow properly')
Signed-off-by: Eran Ben Elisha 
Signed-off-by: Tariq Toukan 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 17 +++--
 drivers/net/ethernet/mellanox/mlx4/main.c  |  5 -
 include/linux/mlx4/device.h|  1 +
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 43f505e..0c0dfd6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2036,11 +2036,20 @@ err:
return -ENOMEM;
 }
 
+static void mlx4_en_shutdown(struct net_device *dev)
+{
+   rtnl_lock();
+   netif_device_detach(dev);
+   mlx4_en_close(dev);
+   rtnl_unlock();
+}
 
 void mlx4_en_destroy_netdev(struct net_device *dev)
 {
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
+   bool shutdown = mdev->dev->persist->interface_state &
+   MLX4_INTERFACE_STATE_SHUTDOWN;
 
en_dbg(DRV, priv, "Destroying netdev on port:%d\n", priv->port);
 
@@ -2048,7 +2057,10 @@ void mlx4_en_destroy_netdev(struct net_device *dev)
if (priv->registered) {
devlink_port_type_clear(mlx4_get_devlink_port(mdev->dev,
  priv->port));
-   unregister_netdev(dev);
+   if (shutdown)
+   mlx4_en_shutdown(dev);
+   else
+   unregister_netdev(dev);
}
 
if (priv->allocated)
@@ -2073,7 +2085,8 @@ void mlx4_en_destroy_netdev(struct net_device *dev)
kfree(priv->tx_ring);
kfree(priv->tx_cq);
 
-   free_netdev(dev);
+   if (!shutdown)
+   free_netdev(dev);
 }
 
 static int mlx4_en_change_mtu(struct net_device *dev, int new_mtu)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
b/drivers/net/ethernet/mellanox/mlx4/main.c
index 372ebfa..546fab0 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -4135,8 +4135,11 @@ static void mlx4_shutdown(struct pci_dev *pdev)
 
mlx4_info(persist->dev, "mlx4_shutdown was called\n");
mutex_lock(>interface_state_mutex);
-   if (persist->interface_state & MLX4_INTERFACE_STATE_UP)
+   if (persist->interface_state & MLX4_INTERFACE_STATE_UP) {
+   /* Notify mlx4 clients that the kernel is being shut down */
+   persist->interface_state |= MLX4_INTERFACE_STATE_SHUTDOWN;
mlx4_unload_one(pdev);
+   }
mutex_unlock(>interface_state_mutex);
 }
 
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 80dec87..d46a0e7 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -466,6 +466,7 @@ enum {
 enum {
MLX4_INTERFACE_STATE_UP = 1 << 0,
MLX4_INTERFACE_STATE_DELETION   = 1 << 1,
+   MLX4_INTERFACE_STATE_SHUTDOWN   = 1 << 2,
 };
 
 #define MSTR_SM_CHANGE_MASK (MLX4_EQ_PORT_INFO_MSTR_SM_SL_CHANGE_MASK | \
-- 
1.8.3.1



[PATCH net 1/2] net/mlx4_en: Fix the return value of a failure in VLAN VID add/kill

2016-06-21 Thread Tariq Toukan
From: Kamal Heib 

Modify mlx4_en_vlan_rx_[add/kill]_vid to return error value in case of
failure.

Fixes: 8e586137e6b6 ('net: make vlan ndo_vlan_rx_[add/kill]_vid return error 
value')
Signed-off-by: Kamal Heib 
Signed-off-by: Tariq Toukan 
---
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c 
b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index a2c2536..43f505e 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -406,14 +406,18 @@ static int mlx4_en_vlan_rx_add_vid(struct net_device *dev,
mutex_lock(>state_lock);
if (mdev->device_up && priv->port_up) {
err = mlx4_SET_VLAN_FLTR(mdev->dev, priv);
-   if (err)
+   if (err) {
en_err(priv, "Failed configuring VLAN filter\n");
+   goto out;
+   }
}
-   if (mlx4_register_vlan(mdev->dev, priv->port, vid, ))
-   en_dbg(HW, priv, "failed adding vlan %d\n", vid);
-   mutex_unlock(>state_lock);
+   err = mlx4_register_vlan(mdev->dev, priv->port, vid, );
+   if (err)
+   en_dbg(HW, priv, "Failed adding vlan %d\n", vid);
 
-   return 0;
+out:
+   mutex_unlock(>state_lock);
+   return err;
 }
 
 static int mlx4_en_vlan_rx_kill_vid(struct net_device *dev,
@@ -421,7 +425,7 @@ static int mlx4_en_vlan_rx_kill_vid(struct net_device *dev,
 {
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_en_dev *mdev = priv->mdev;
-   int err;
+   int err = 0;
 
en_dbg(HW, priv, "Killing VID:%d\n", vid);
 
@@ -438,7 +442,7 @@ static int mlx4_en_vlan_rx_kill_vid(struct net_device *dev,
}
mutex_unlock(>state_lock);
 
-   return 0;
+   return err;
 }
 
 static void mlx4_en_u64_to_mac(unsigned char dst_mac[ETH_ALEN + 2], u64 
src_mac)
-- 
1.8.3.1



Re: [PATCH] rxrpc: fix uninitialized variable use

2016-06-21 Thread David Howells
Arnd Bergmann  wrote:

> > I'm actually more tempted to put a BUG() in there because if any new family
> > support (say AF_INET6) is added, I want to make sure I catch all the places.
> 
> Makes sense. Do you want to do the patch yourself, or should I send
> a new one doing that?
> 
> Maybe WARN() would be better than BUG()? That would still get the attention
> it needs but not kill the process.

I can stick a WARN() into your patch.

David


[PATCH] net: ethernet: fix odd_ptr_err.cocci warnings

2016-06-21 Thread Julia Lawall
PTR_ERR should normally access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Tien Hock Loh <th...@altera.com>
Signed-off-by: Julia Lawall <julia.law...@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>
---

This patch refers to the following code:

url:
https://github.com/0day-ci/linux/commits/thloh-altera-com/net-ethernet-Add-T
SE-PCS-support-to-dwmac-socfpga/20160621-164854

 dwmac-socfpga.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -224,7 +224,7 @@ static int socfpga_dwmac_parse_data(stru
dev_err(dev,
"%s: ERROR: failed mapping tse control 
port\n",
__func__);
-   return PTR_ERR(dwmac->pcs.sgmii_adapter_base);
+   return PTR_ERR(dwmac->pcs.tse_pcs_base);
}
}
}


Re: [6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF

2016-06-21 Thread Michael Ellerman
On Tue, 2016-06-21 at 12:28 +0530, Naveen N. Rao wrote:
> On 2016/06/21 09:38AM, Michael Ellerman wrote:
> > On Sun, 2016-06-19 at 23:06 +0530, Naveen N. Rao wrote:
> > > 
> > > #include 
> > > 
> > > in bpf_jit_comp64.c
> > > 
> > > Can you please check if it resolves the build error?
> > 
> > Can you? :D
> 
> :)
> Sorry, I should have explained myself better. I did actually try your 
> config and I was able to reproduce the build error. After the above 
> #include, that error went away, but I saw some vdso related errors. I 
> thought I was doing something wrong and needed a different setup for 
> that particular kernel config, which is why I requested your help in the 
> matter. I just didn't do a good job of putting across that message...
 
Ah OK. Not sure why you're seeing VDSO errors?

> Note to self: randconfig builds *and* more time drafting emails :)

No stress. You don't need to do randconfig builds, or even build all the
arch/powerpc/ configs, just try to do a reasonable set, something like - ppc64,
powernv, pseries, pmac32, ppc64e.

I'm happy to catch the esoteric build failures.

> Do you want me to respin the patches?

No that's fine, I'll fix it up here.

cheers



Re: [PATCH v4 00/19] CALIPSO Implementation

2016-06-21 Thread Huw Davies
On Tue, Jun 21, 2016 at 05:39:28AM -0400, David Miller wrote:
> From: Huw Davies 
> Date: Mon, 20 Jun 2016 14:36:40 +0100
> 
> > This patch series implements RFC 5570 - Common Architecture Label IPv6
> > Security Option (CALIPSO).  Its goal is to set MLS sensitivity labels
> > on IPv6 packets using a hop-by-hop option.  CALIPSO is very similar to
> > its IPv4 cousin CIPSO and much of this series is based on that code.
> 
> What tree do you expect to integrate this?

My understanding is that Paul Moore is happy to take them
in via the SELinux tree.  However, these patches do touch
some core networking code, such as the IPv6 option handling
code (in a similar manner to the way CIPSO touched the IPv4
option code), so if you have any comments on those aspects
that would be good to hear.

Thanks,
Huw.


Re: [PATCH net-next 10/19] net: hns: bugfix about pfc pause frame statistics

2016-06-21 Thread Yisen Zhuang


在 2016/6/21 18:32, Andy Shevchenko 写道:
> On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote:
>> From: Daode Huang 
>>
>> For SoC hip06, PFC pause handled in dsaf, while hip05 in XGMAC,
>> so change the statistics of pfc pause in dsaf and remove the old
>> pfc pause frame statistics.
>>
> 
> 
>> +static char *hns_dsaf_get_node_stats_strings(char *data, int node,
>> + struct dsaf_device
>> *dsaf_dev)
>>  {
>>  char *buff = data;
>> +int i;
>> +bool is_ver1 = AE_IS_VER1(dsaf_dev->dsaf_ver);
>>  
>>  snprintf(buff, ETH_GSTRING_LEN, "innod%d_pad_drop_pkts",
>> node);
>>  buff = buff + ETH_GSTRING_LEN;
>> @@ -2502,6 +2530,18 @@ static char
>> *hns_dsaf_get_node_stats_strings(char *data, int node)
>>  buff = buff + ETH_GSTRING_LEN;
>>  snprintf(buff, ETH_GSTRING_LEN, "innod%d_stp_drop_pkts",
>> node);
>>  buff = buff + ETH_GSTRING_LEN;
>> +if ((node < DSAF_SERVICE_NW_NUM) && (!is_ver1)) {
> 
> Redundant parens.
> 
>> +for (i = 0; i < DSAF_PRIO_NR; i++) {
>> +snprintf(buff, ETH_GSTRING_LEN,
>> + "inod%d_pfc_prio%d_pkts", node, i);
>> +buff = buff + ETH_GSTRING_LEN;
> 
> buff += ...
> 
>> +}
>> +for (i = 0; i < DSAF_PRIO_NR; i++) {
>> +snprintf(buff, ETH_GSTRING_LEN,
>> + "onod%d_pfc_prio%d_pkts", node, i);
>> +buff = buff + ETH_GSTRING_LEN;
> 
> Ditto.
> 
>>  {
>>  u64 *p = data;
>> +int i;
>>  struct dsaf_hw_stats *hw_stats = >hw_stats[node_num];
>> +bool is_ver1 = AE_IS_VER1(ddev->dsaf_ver);
>>  
>>  p[0] = hw_stats->pad_drop;
>>  p[1] = hw_stats->man_pkts;
>> @@ -2527,8 +2569,16 @@ static u64 *hns_dsaf_get_node_stats(struct
>> dsaf_device *ddev, u64 *data,
>>  p[10] = hw_stats->local_addr_false;
>>  p[11] = hw_stats->vlan_drop;
>>  p[12] = hw_stats->stp_drop;
>> -p[13] = hw_stats->tx_pkts;
>> +if ((node_num < DSAF_SERVICE_NW_NUM) && (!is_ver1)) {
>> +for (i = 0; i < DSAF_PRIO_NR; i++) {
>> +p[13 + i] = hw_stats->rx_pfc[i];
>> +p[13 + i + DSAF_PRIO_NR] = hw_stats-
>>> tx_pfc[i];
>> +}
> 
> Two different approaches how to assign data. Above uses 2 for-loops,
> here you put everything to one.

Above cann't be merged to 1 for-loop, because lenght of the string is 
unknowable.

And here we put everything to one to reduce codes.

I will generate a new patch to fix other comments.

Thanks,

Yisen

> 
>> +p[29] = hw_stats->tx_pkts;
>> +return [30];
>> +}
>>  
>> +p[13] = hw_stats->tx_pkts;
>>  return [14];
>>  }
> 



Re: [PATCH net-next 16/19] net: hns: fix bug that alloc skb fail lead to port unavailable

2016-06-21 Thread Yisen Zhuang


在 2016/6/21 21:25, Sergei Shtylyov 写道:
> Hello.
> 
> On 6/21/2016 6:56 AM, Yisen Zhuang wrote:
> 
>> From: Jun He 
>>
>> When hns_nic_poll_rx_skb alloc skb fail, it will break receive cycle and
>> read new fbd_num to start new receive cycle. It recomputes cycle num is
>> fbd_num minus clean_count, actually this cycle num is too big because
>> it drop out receive cycle. It brings about the port unavailable.
>>
>> So we will goto out when alloc skb fail to fix this bug.
>>
>> Signed-off-by: Jun He 
>> Signed-off-by: Ding Tianhong 
>> Signed-off-by: Yisen Zhuang 
>> ---
>>  drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
>> b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> index f49246d..c0ce37b 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
>> @@ -768,10 +768,10 @@ recv:
>>  clean_count = 0;
>>  }
>>
>> -/* poll one pkg*/
>> +/* poll one pkt*/

I will fix it with a new patch.

Thanks,

Yisen

> 
>How about adding a space before */?
> 
> [...]
> 
> MBR, Sergei
> 
> 
> .
> 



Re: [PATCH -next 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on next-20160621]

url:
https://github.com/0day-ci/linux/commits/Martin-KaFai-Lau/cgroup-bpf-cgroup2-membership-test-on-skb/20160622-082800
config: sh-titan_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   net/core/filter.c: In function 'bpf_skb_in_cgroup':
>> net/core/filter.c:2049:9: error: implicit declaration of function 
>> 'cgroup_is_descendant' [-Werror=implicit-function-declaration]
 return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), cgrp);
^
   net/core/filter.c:2049:30: error: implicit declaration of function 
'sock_cgroup_ptr' [-Werror=implicit-function-declaration]
 return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), cgrp);
 ^
   cc1: some warnings being treated as errors

vim +/cgroup_is_descendant +2049 net/core/filter.c

  2043  return -E2BIG;
  2044  
  2045  cgrp = READ_ONCE(array->ptrs[i]);
  2046  if (unlikely(!cgrp))
  2047  return -ENOENT;
  2048  
> 2049  return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), 
> cgrp);
  2050  }
  2051  
  2052  static const struct bpf_func_proto bpf_skb_in_cgroup_proto = {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

2016-06-21 Thread Jerry Chu
On Tue, Jun 21, 2016 at 1:29 AM, David Miller  wrote:
> From: Tom Herbert 
> Date: Mon, 20 Jun 2016 08:13:48 -0700
>
>> Routing around the problem is already being done.
>
> QUIC, a new protocol used for specific purposes and implemented in
> userspace from the start is significantly different from making the
> kernel's _TCP_ implementation bypassed into a userspace one just by
> UDP encapsulating it.
>
> That is a major and conscious change in our mentality.
>
> The consequences are far and wide, and I'm having a very hard time
> seeing the benefits you cite being larger than the negatives here.

I don't believe TOU will lead to a proliferation of TCP implementations in
the userland - getting a solid TCP implementation is hard. Yes any smart CS
student in the networking field can write one over a weekend, to get 3WHS
to work, and may even include graceful shutdown. But creating one from
scratch that is both high quality, compliant, highly inter-operable, and highly
performing is really hard. Just look at how much work folks on the list have
to continue to pour in to maintain the Linux TCP stack as the best on the
planet.

Yes TOU may lower the bar for random hacks by Joe Random. But I'd argue
no large organization would serious consider or dare deploy TCP stack
with random hacks. I know we have a very high bar to pass at Google. This
should limit the impact of bad TCP stacks on the Internet. If we continue
to keep up and make timely improvements to the Linux TCP stack, and
better yet, to continue to improve technology like UML and LKL to make it
easy for folks to access great technologies in the Linux kernel stack and
deploy them in the userland, it will probably take away all the motivations
for people to do their own random hacks.

Best,

Jerry


Re: [net-next] samples/bpf: set max locked memory to ulimited

2016-06-21 Thread Alexei Starovoitov
On Tue, Jun 21, 2016 at 09:05:58PM -0700, William Tu wrote:
> Signed-off-by: William Tu 

Acked-by: Alexei Starovoitov 



Re: [PATCH] ppc: Fix BPF JIT for ABIv2

2016-06-21 Thread Michael Ellerman
On Tue, 2016-06-21 at 14:28 +0530, Naveen N. Rao wrote:
> On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> > On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > Hi, Michael and Naveen.
> > > > 
> > > > I noticed independently that there is a problem with BPF JIT and ABIv2, 
> > > > and
> > > > worked out the patch below before I noticed Naveen's patchset and the 
> > > > latest
> > > > changes in ppc tree for a better way to check for ABI versions.
> > > > 
> > > > However, since the issue described below affect mainline and stable 
> > > > kernels,
> > > > would you consider applying it before merging your two patchsets, so 
> > > > that we can
> > > > more easily backport the fix?
> > > 
> > > Hi Cascardo,
> > > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > > fixing it. But, I can see why this would be a good thing to have for 
> > > -stable and existing distros. However, while your patch below may fix 
> > > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > > changes in bpf_jit_asm.S as well.
> > 
> > Hi, Naveen.
> > 
> > Any tips on how to exercise possible issues there? Or what changes you think
> > would be sufficient?
> 
> The calling convention is different with ABIv2 and so we'll need changes 
> in bpf_slow_path_common() and sk_negative_common().
> 
> However, rather than enabling classic JIT for ppc64le, are we better off 
> just disabling it?
> 
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -128,7 +128,7 @@ config PPC
> select IRQ_FORCED_THREADING
> select HAVE_RCU_TABLE_FREE if SMP
> select HAVE_SYSCALL_TRACEPOINTS
> -   select HAVE_CBPF_JIT
> +   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> select HAVE_ARCH_JUMP_LABEL
> select ARCH_HAVE_NMI_SAFE_CMPXCHG
> select ARCH_HAS_GCOV_PROFILE_ALL
> 
> 
> Michael,
> Let me know your thoughts on whether you intend to take this patch or 
> Cascardo's patch for -stable before the eBPF patches. I can redo my 
> patches accordingly.

Can one of you send me a proper version of this patch, with change log and
sign-off etc.

cheers



Re: [PATCH v10 08/22] IB/hns: Add icm support

2016-06-21 Thread Wei Hu (Xavier)



On 2016/6/21 19:55, Leon Romanovsky wrote:

On Tue, Jun 21, 2016 at 12:37:39PM +0800, Wei Hu (Xavier) wrote:


On 2016/6/20 21:04, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 05:48:15PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/20 17:27, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 03:49:24PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/20 14:06, Leon Romanovsky wrote:

On Mon, Jun 20, 2016 at 12:37:40PM +0800, Wei Hu (Xavier) wrote:

On 2016/6/17 17:58, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:16PM +0800, Lijun Ou wrote:

This patch mainly added icm support for RoCE. It initializes icm
which managers the relative memory blocks for RoCE. The data
structures of RoCE will be located in it. For example, CQ table,
QP table and MTPT table so on.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---

<...>


+

Another question which you didn't answer [1].

"I wonder if you have the same needs for ICM as it is in mlx4 device.
Do you have firmware?"

[1] http://marc.info/?l=linux-rdma=146545553104913=2

Hi, Leon
 Now we haven't firmware.
 But hardware still need memory for QPC\CQC\MTPT\mtt etc.

ICM stands for InfiniHost (Interconnect) Context Memory is a specific
memory place to share between host <-> FW and host <-> HW if HW is
aware of specific structures.

I assume that in your case, it is enough to allocate memory region and
supply it to HW. Am I right?

For Our hardware,
1. ICM has a memory management method, It's very good for QPC\CQC\MTPT\mtt
etc. we need it.

You need special HW to leverage its. AFAIK it is Mellanox specific.

For our hardware, we use ICM to memory management, the memory shared with
host and HW.
QPC\CQC\MTPT\mtt has specific memory requirement.
QPC\CQC\MTPT need continuous memory. we use ICM to management the block of
memory. It's very good!

I wasn't convinced why do you need to copy whole ICM logic which is
specific to Mellanox. Your requirements can be implemented by standard CMA
and/or DMA.

Hi, Leon

In hip06 soc,
Hardware need multiple memory blocks for QPC\CQC\MTPT, every block has 
continuous memory xxKbyte (like 128Kbyte),

We need to configure the first address of 128Kbyte to hardware.

For example:
//
example 1:
In create qp,
1. If the xx Kbyte memory that include QPC related with qpn, has not 
been allocated, do step 2.

   else do step 3.
2. dma_alloc xx Kbyte memory for QPC,  and configure the first address 
of xx Kbyte to hardware.

3. find the QPC memory in xx Kbyte, get the dma_addr.
4. send mailbox command to hardware to create QP.

In step 2, we call xx_table_get function as below to perform logic.
int hns_roce_table_get(struct hns_roce_dev *hr_dev,
   struct hns_roce_icm_table *table, unsigned long obj)
{

//dma_alloc_coherent 128Kbyte memory
hns_roce_alloc_icm(hr_dev,
  HNS_ROCE_TABLE_CHUNK_SIZE >> PAGE_SHIFT, );

/*configure the first address of xx Kbyte to hardware*/
hns_roce_map_icm(hr_dev, table, obj);

}

In step 3, we call xx_table_find function to perform logic.
void *hns_roce_table_find(struct hns_roce_icm_table *table, unsigned 
long obj,

  dma_addr_t *dma_handle);


example 2:
In modify qp:
1. find the QPC memory,  get the virtual addr.
2. modify the fields of QPC.
3. send mailbox command to hardware to modify QP.

In step 1,  we call xx_table_find function to perform logic.
//--


so, now we haven't a firmware, but ICM algorithm still suitable for 
hip06 soc perfectly.


Regards
Wei Hu

2. The meomry for QPC\CQC\MTPT\mtt only used for RoCE hardware and driver,
we don't want use MR.

I didn't mean Infiniband MR, but memory region returned from standard
allocation functions (kmalloc, ...).


3. Now we haven't firmware, maybe we need it next version.

You are always invited to add support once it will be needed, no need to
add it in advance.

Thanks







Re: [PATCH] ppc: Fix BPF JIT for ABIv2

2016-06-21 Thread Michael Ellerman
On Fri, 2016-06-17 at 10:00 -0300, Thadeu Lima de Souza Cascardo wrote:
> From a984dc02b6317a1d3a3c2302385adba5227be5bd Mon Sep 17 00:00:00 2001
> From: Thadeu Lima de Souza Cascardo 
> Date: Wed, 15 Jun 2016 13:22:12 -0300
> Subject: [PATCH] ppc: Fix BPF JIT for ABIv2
> 
> ABIv2 used for ppc64le does not use function descriptors. Without this patch,
> whenever BPF JIT is enabled, we get a crash as below.
> 
...

> diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
> index 889fd19..28b89ed 100644
> --- a/arch/powerpc/net/bpf_jit.h
> +++ b/arch/powerpc/net/bpf_jit.h
> @@ -70,7 +70,7 @@ DECLARE_LOAD_FUNC(sk_load_half);
>  DECLARE_LOAD_FUNC(sk_load_byte);
>  DECLARE_LOAD_FUNC(sk_load_byte_msh);
>  
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>  #define FUNCTION_DESCR_SIZE  24
>  #else
>  #define FUNCTION_DESCR_SIZE  0
> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index 2d66a84..035b887 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -664,7 +664,7 @@ void bpf_jit_compile(struct bpf_prog *fp)
>  
>   if (image) {
>   bpf_flush_icache(code_base, code_base + (proglen/4));
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>   /* Function descriptor nastiness: Address + TOC */
>   ((u64 *)image)[0] = (u64)code_base;
>   ((u64 *)image)[1] = local_paca->kernel_toc;


Confirmed that even with this patch we still crash:

  # echo 1 > /proc/sys/net/core/bpf_jit_enable
  # modprobe test_bpf
  BPF filter opcode 0020 (@3) unsupported
  BPF filter opcode 0020 (@2) unsupported
  BPF filter opcode 0020 (@0) unsupported
  Unable to handle kernel paging request for data at address 0xd54f65e8
  Faulting instruction address: 0xc08765f8
  cpu 0x0: Vector: 300 (Data Access) at [c34f3480]
  pc: c08765f8: skb_copy_bits+0x158/0x330
  lr: c008fb7c: bpf_slow_path_byte+0x28/0x54
  sp: c34f3700
 msr: 80010280b033
 dar: d54f65e8
   dsisr: 4000
current = 0xc001f857d8d0
paca= 0xc7b8 softe: 0irq_happened: 0x01
  pid   = 2993, comm = modprobe
  Linux version 4.7.0-rc3-00055-g9497a1c1c5b4-dirty 
(mich...@ka3.ozlabs.ibm.com) () #30 SMP Wed Jun 22 15:06:58 AEST 2016
  enter ? for help
  [c34f3770] c008fb7c bpf_slow_path_byte+0x28/0x54
  [c34f37e0] d7bb004c
  [c34f3900] d5331668 test_bpf_init+0x5fc/0x7f8 [test_bpf]
  [c34f3a30] c000b628 do_one_initcall+0x68/0x1d0
  [c34f3af0] c09beb24 do_init_module+0x90/0x240
  [c34f3b80] c01642bc load_module+0x206c/0x22f0
  [c34f3d30] c01648b0 SyS_finit_module+0x120/0x180
  [c34f3e30] c0009260 system_call+0x38/0x108
  --- Exception: c01 (System Call) at 3fff7ffa2db4


cheers



[PATCH net-next 02/13] liquidio: Vlan offloads changes

2016-06-21 Thread Raghu Vatsavayi
This patch adds support for vlan offloads for the driver and
receive header structures are also modified appropriately. Also
requestID will not be used in reveive header any more.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c| 26 +++-
 .../net/ethernet/cavium/liquidio/liquidio_common.h | 46 +++---
 2 files changed, 46 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c 
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 5a0977f..4b95dbf 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1849,6 +1849,7 @@ liquidio_push_packet(u32 octeon_id,
struct sk_buff *skb = (struct sk_buff *)skbuff;
struct skb_shared_hwtstamps *shhwtstamps;
u64 ns;
+   u16 vtag = 0;
struct net_device *netdev = (struct net_device *)arg;
struct octeon_droq *droq = container_of(param, struct octeon_droq,
napi);
@@ -1925,6 +1926,16 @@ liquidio_push_packet(u32 octeon_id,
else
skb->ip_summed = CHECKSUM_NONE;
 
+   /* inbound VLAN tag */
+   if ((netdev->features & NETIF_F_HW_VLAN_CTAG_RX) &&
+   (rh->r_dh.vlan != 0)) {
+   u16 vid = rh->r_dh.vlan;
+   u16 priority = rh->r_dh.priority;
+
+   vtag = priority << 13 | vid;
+   __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vtag);
+   }
+
packet_was_received = napi_gro_receive(napi, skb) != GRO_DROP;
 
if (packet_was_received) {
@@ -2900,6 +2911,11 @@ static int liquidio_xmit(struct sk_buff *skb, struct 
net_device *netdev)
tx_info->s.gso_size = skb_shinfo(skb)->gso_size;
tx_info->s.gso_segs = skb_shinfo(skb)->gso_segs;
}
+   /* HW insert VLAN tag */
+   if (skb_vlan_tag_present(skb)) {
+   irh->priority = skb_vlan_tag_get(skb) >> 13;
+   irh->vlan = skb_vlan_tag_get(skb) & 0xfff;
+   }
 
xmit_more = skb->xmit_more;
 
@@ -3301,11 +3317,17 @@ static int setup_nic_devices(struct octeon_device 
*octeon_dev)
| NETIF_F_LRO;
netif_set_gso_max_size(netdev, OCTNIC_GSO_MAX_SIZE);
 
-   netdev->features = (lio->dev_capability & ~NETIF_F_LRO);
-
netdev->vlan_features = lio->dev_capability;
+   /* Add any unchangeable hw features */
+   lio->dev_capability |=  NETIF_F_HW_VLAN_CTAG_RX |
+   NETIF_F_HW_VLAN_CTAG_TX;
+
+   netdev->features = (lio->dev_capability & ~NETIF_F_LRO);
 
netdev->hw_features = lio->dev_capability;
+   /*HW_VLAN_RX and HW_VLAN_FILTER is always on*/
+   netdev->hw_features = netdev->hw_features &
+   ~NETIF_F_HW_VLAN_CTAG_RX;
 
/* Point to the  properties for octeon device to which this
 * interface belongs.
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h 
b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index 2179691..c86421f 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -482,15 +482,15 @@ struct octeon_instr_irh {
u64 opcode:4;
u64 rflag:1;
u64 subcode:7;
-   u64 len:3;
-   u64 rid:13;
-   u64 reserved:4;
+   u64 vlan:12;
+   u64 priority:3;
+   u64 reserved:5;
u64 ossp:32; /* opcode/subcode specific parameters */
 #else
u64 ossp:32; /* opcode/subcode specific parameters */
-   u64 reserved:4;
-   u64 rid:13;
-   u64 len:3;
+   u64 reserved:5;
+   u64 priority:3;
+   u64 vlan:12;
u64 subcode:7;
u64 rflag:1;
u64 opcode:4;
@@ -517,28 +517,27 @@ union octeon_rh {
struct {
u64 opcode:4;
u64 subcode:8;
-   u64 len:3;   /** additional 64-bit words */
-   u64 rid:13;  /** request id in response to pkt sent by host 
*/
-   u64 reserved:4;
-   u64 ossp:32; /** opcode/subcode specific parameters */
+   u64 len:3; /** additional 64-bit words */
+   u64 reserved:17;
+   u64 ossp:32;   /** opcode/subcode specific parameters */
} r;
struct {
u64 opcode:4;
u64 subcode:8;
-   u64 

[PATCH net-next 04/13] liquidio: Napi rx/tx traffic

2016-06-21 Thread Raghu Vatsavayi
This Patch adds tx buffer handling  to Napi along with RX
traffic. Also separate spinlocks are introduced for handling
iq posting and buffer reclaim so that tx path and tx interrupt
do not compete against each other.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 .../net/ethernet/cavium/liquidio/cn66xx_device.c   |   3 +-
 .../net/ethernet/cavium/liquidio/cn66xx_device.h   |   3 +-
 drivers/net/ethernet/cavium/liquidio/lio_main.c| 150 +
 .../net/ethernet/cavium/liquidio/octeon_device.h   |   4 +-
 drivers/net/ethernet/cavium/liquidio/octeon_iq.h   |  12 +-
 .../net/ethernet/cavium/liquidio/request_manager.c | 110 +--
 6 files changed, 177 insertions(+), 105 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c 
b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
index c577559..d35864a 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
@@ -496,8 +496,7 @@ u32 lio_cn6xxx_bar1_idx_read(struct octeon_device *oct, u32 
idx)
 }
 
 u32
-lio_cn6xxx_update_read_index(struct octeon_device *oct __attribute__((unused)),
-struct octeon_instr_queue *iq)
+lio_cn6xxx_update_read_index(struct octeon_instr_queue *iq)
 {
u32 new_idx = readl(iq->inst_cnt_reg);
 
diff --git a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.h 
b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.h
index f779187..fe2932c 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.h
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.h
@@ -91,8 +91,7 @@ void lio_cn6xxx_bar1_idx_setup(struct octeon_device *oct, u64 
core_addr,
 void lio_cn6xxx_bar1_idx_write(struct octeon_device *oct, u32 idx, u32 mask);
 u32 lio_cn6xxx_bar1_idx_read(struct octeon_device *oct, u32 idx);
 u32
-lio_cn6xxx_update_read_index(struct octeon_device *oct __attribute__((unused)),
-struct octeon_instr_queue *iq);
+lio_cn6xxx_update_read_index(struct octeon_instr_queue *iq);
 void lio_cn6xxx_enable_interrupt(void *chip);
 void lio_cn6xxx_disable_interrupt(void *chip);
 void cn6xxx_get_pcie_qlmport(struct octeon_device *oct);
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c 
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 9f3a93b..8310eb8 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -365,7 +365,7 @@ static int wait_for_pending_requests(struct octeon_device 
*oct)
[OCTEON_ORDERED_SC_LIST].pending_req_count);
if (pcount)
schedule_timeout_uninterruptible(HZ / 10);
-else
+   else
break;
}
 
@@ -409,7 +409,7 @@ static inline void pcierror_quiesce_device(struct 
octeon_device *oct)
iq->octeon_read_index = iq->host_write_index;
iq->stats.instr_processed +=
atomic_read(>instr_pending);
-   lio_process_iq_request_list(oct, iq);
+   lio_process_iq_request_list(oct, iq, 0);
spin_unlock_bh(>lock);
}
}
@@ -959,6 +959,36 @@ static inline void update_link_status(struct net_device 
*netdev,
}
 }
 
+/* Runs in interrupt context. */
+static void update_txq_status(struct octeon_device *oct, int iq_num)
+{
+   struct net_device *netdev;
+   struct lio *lio;
+   struct octeon_instr_queue *iq = oct->instr_queue[iq_num];
+
+   /*octeon_update_iq_read_idx(oct, iq);*/
+
+   netdev = oct->props[iq->ifidx].netdev;
+
+   /* This is needed because the first IQ does not have
+* a netdev associated with it.
+*/
+   if (!netdev)
+   return;
+
+   lio = GET_LIO(netdev);
+   if (netif_is_multiqueue(netdev)) {
+   if (__netif_subqueue_stopped(netdev, iq->q_index) &&
+   lio->linfo.link.s.link_up &&
+   (!octnet_iq_is_full(oct, iq_num))) {
+   netif_wake_subqueue(netdev, iq->q_index);
+   } else {
+   if (!octnet_iq_is_full(oct, lio->txq))
+   wake_q(netdev, lio->txq);
+   }
+   }
+}
+
 /**
  * \brief Droq packet processor sceduler
  * @param oct octeon device
@@ -1246,6 +1276,7 @@ static void liquidio_destroy_nic_device(struct 
octeon_device *oct, int ifidx)
 {
struct net_device *netdev = oct->props[ifidx].netdev;
struct lio *lio;
+   struct napi_struct *napi, *n;
 
if (!netdev) {
  

[PATCH net-next 09/13] liquidio: New statistics support

2016-06-21 Thread Raghu Vatsavayi
This patch adds extensive support of statistics for data path,
control path and firmware.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 574 ++---
 drivers/net/ethernet/cavium/liquidio/lio_main.c|  48 +-
 .../net/ethernet/cavium/liquidio/liquidio_common.h |  10 +
 .../net/ethernet/cavium/liquidio/octeon_device.h   |   6 +
 drivers/net/ethernet/cavium/liquidio/octeon_iq.h   |   4 +
 .../net/ethernet/cavium/liquidio/octeon_network.h  |  11 +
 6 files changed, 588 insertions(+), 65 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c 
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 9c6b58a..2b03095 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -40,6 +40,8 @@
 #include "cn68xx_device.h"
 #include "liquidio_image.h"
 
+static int octnet_get_link_stats(struct net_device *netdev);
+
 struct oct_mdio_cmd_context {
int octeon_id;
wait_queue_head_t wc;
@@ -77,28 +79,109 @@ enum {
 #define OCT_ETHTOOL_REGDUMP_LEN  4096
 #define OCT_ETHTOOL_REGSVER  1
 
+/* statistics of PF */
+static const char oct_stats_strings[][ETH_GSTRING_LEN] = {
+   "rx_packets",
+   "tx_packets",
+   "rx_bytes",
+   "tx_bytes",
+   "rx_errors",/*jabber_err+l2_err+frame_err */
+   "tx_errors",/*fw_err_pko+fw_err_link+fw_err_drop */
+   "rx_dropped",   /*st->fromwire.total_rcvd - st->fromwire.fw_total_rcvd
+   *+st->fromwire.dmac_drop + st->fromwire.fw_err_drop
+   */
+   "tx_dropped",
+
+   "tx_total_sent",
+   "tx_total_fwd",
+   "tx_err_pko",
+   "tx_err_link",
+   "tx_err_drop",
+
+   "tx_tso",
+   "tx_tso_packets",
+   "tx_tso_err",
+
+   "mac_tx_total_pkts",
+   "mac_tx_total_bytes",
+   "mac_tx_mcast_pkts",
+   "mac_tx_bcast_pkts",
+   "mac_tx_ctl_packets",   /*oct->link_stats.fromhost.ctl_sent */
+   "mac_tx_total_collisions",
+   "mac_tx_one_collision",
+   "mac_tx_multi_collison",
+   "mac_tx_max_collision_fail",
+   "mac_tx_max_deferal_fail",
+   "mac_tx_fifo_err",
+   "mac_tx_runts",
+
+   "rx_total_rcvd",
+   "rx_total_fwd",
+   "rx_jabber_err",
+   "rx_l2_err",
+   "rx_frame_err",
+   "rx_err_pko",
+   "rx_err_link",
+   "rx_err_drop",
+
+   "rx_lro_pkts",
+   "rx_lro_bytes",
+   "rx_total_lro",
+
+   "rx_lro_aborts",
+   "rx_lro_aborts_port",
+   "rx_lro_aborts_seq",
+   "rx_lro_aborts_tsval",
+   "rx_lro_aborts_timer",
+   "rx_fwd_rate",
+
+   "mac_rx_total_rcvd",
+   "mac_rx_bytes",
+   "mac_rx_total_bcst",
+   "mac_rx_total_mcst",
+   "mac_rx_runts",
+   "mac_rx_ctl_packets",
+   "mac_rx_fifo_err",
+   "mac_rx_dma_drop",
+   "mac_rx_fcs_err",
+
+   "link_state_changes",
+};
+
+/* statistics of host tx queue */
 static const char oct_iq_stats_strings[][ETH_GSTRING_LEN] = {
-   "Instr posted",
-   "Instr processed",
-   "Instr dropped",
-   "Bytes Sent",
-   "Sgentry_sent",
-   "Inst cntreg",
-   "Tx done",
-   "Tx Iq busy",
-   "Tx dropped",
-   "Tx bytes",
+   "packets",  /*oct->instr_queue[iq_no]->stats.tx_done*/
+   "bytes",/*oct->instr_queue[iq_no]->stats.tx_tot_bytes*/
+   "dropped",
+   "iq_busy",
+   "sgentry_sent",
+
+   "fw_instr_posted",
+   "fw_instr_processed",
+   "fw_instr_dropped",
+   "fw_bytes_sent",
+
+   "tso",
+   "txq_restart",
 };
 
+/* statistics of host rx queue */
 static const char oct_droq_stats_strings[][ETH_GSTRING_LEN] = {
-   "OQ Pkts Received",
-   "OQ Bytes Received",
-   "Dropped no dispatch",
-   "Dropped nomem",
-   "Dropped toomany",
-   "Stack RX cnt",
-   "Stack RX Bytes",
-   "RX dropped",
+   "packets",  /*oct->droq[oq_no]->stats.rx_pkts_received */
+   "bytes",/*oct->droq[oq_no]->stats.rx_bytes_received */
+   "dropped",  /*oct->droq[oq_no]->stats.rx_dropped+
+*oct->droq[oq_no]->stats.dropped_nodispatch+
+*oct->droq[oq_no]->stats.dropped_toomany+
+*oct->droq[oq_no]->stats.dropped_nomem
+*/
+   "dropped_nomem",
+   "dropped_toomany",
+   "fw_dropped",
+   "fw_pkts_received",
+   "fw_bytes_received",
+   "fw_dropped_nodispatch",
+
+   "buffer_alloc_failure",
 };
 
 #define OCTNIC_NCMD_AUTONEG_ON  

[PATCH net-next 08/13] liquidio: tx rx interrupt moderation

2016-06-21 Thread Raghu Vatsavayi
This patch has new tx/rx interrupt moderation defaults of
count/timer for better throughput and utilisation.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 270 -
 drivers/net/ethernet/cavium/liquidio/lio_main.c|  22 +-
 .../net/ethernet/cavium/liquidio/liquidio_common.h |  49 ++--
 3 files changed, 200 insertions(+), 141 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c 
b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 56f465b..9c6b58a 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -616,50 +616,50 @@ static int lio_get_intr_coalesce(struct net_device 
*netdev,
 {
struct lio *lio = GET_LIO(netdev);
struct octeon_device *oct = lio->oct_dev;
-   struct octeon_cn6xxx *cn6xxx = (struct octeon_cn6xxx *)oct->chip;
struct octeon_instr_queue *iq;
struct oct_intrmod_cfg *intrmod_cfg;
 
intrmod_cfg = >intrmod;
 
switch (oct->chip_id) {
-   /* case OCTEON_CN73XX: Todo */
-   /*  break; */
case OCTEON_CN68XX:
-   case OCTEON_CN66XX:
-   if (!intrmod_cfg->intrmod_enable) {
+   case OCTEON_CN66XX: {
+   struct octeon_cn6xxx *cn6xxx =
+   (struct octeon_cn6xxx *)oct->chip;
+
+   if (!intrmod_cfg->rx_enable) {
intr_coal->rx_coalesce_usecs =
CFG_GET_OQ_INTR_TIME(cn6xxx->conf);
intr_coal->rx_max_coalesced_frames =
CFG_GET_OQ_INTR_PKT(cn6xxx->conf);
-   } else {
-   intr_coal->use_adaptive_rx_coalesce =
-   intrmod_cfg->intrmod_enable;
-   intr_coal->rate_sample_interval =
-   intrmod_cfg->intrmod_check_intrvl;
-   intr_coal->pkt_rate_high =
-   intrmod_cfg->intrmod_maxpkt_ratethr;
-   intr_coal->pkt_rate_low =
-   intrmod_cfg->intrmod_minpkt_ratethr;
-   intr_coal->rx_max_coalesced_frames_high =
-   intrmod_cfg->intrmod_maxcnt_trigger;
-   intr_coal->rx_coalesce_usecs_high =
-   intrmod_cfg->intrmod_maxtmr_trigger;
-   intr_coal->rx_coalesce_usecs_low =
-   intrmod_cfg->intrmod_mintmr_trigger;
-   intr_coal->rx_max_coalesced_frames_low =
-   intrmod_cfg->intrmod_mincnt_trigger;
}
 
iq = oct->instr_queue[lio->linfo.txpciq[0].s.q_no];
intr_coal->tx_max_coalesced_frames = iq->fill_threshold;
break;
-
+   }
default:
netif_info(lio, drv, lio->netdev, "Unknown Chip !!\n");
return -EINVAL;
}
-
+   if (intrmod_cfg->rx_enable) {
+   intr_coal->use_adaptive_rx_coalesce =
+   intrmod_cfg->rx_enable;
+   intr_coal->rate_sample_interval =
+   intrmod_cfg->check_intrvl;
+   intr_coal->pkt_rate_high =
+   intrmod_cfg->maxpkt_ratethr;
+   intr_coal->pkt_rate_low =
+   intrmod_cfg->minpkt_ratethr;
+   intr_coal->rx_max_coalesced_frames_high =
+   intrmod_cfg->rx_maxcnt_trigger;
+   intr_coal->rx_coalesce_usecs_high =
+   intrmod_cfg->rx_maxtmr_trigger;
+   intr_coal->rx_coalesce_usecs_low =
+   intrmod_cfg->rx_mintmr_trigger;
+   intr_coal->rx_max_coalesced_frames_low =
+   intrmod_cfg->rx_mincnt_trigger;
+   }
return 0;
 }
 
@@ -679,19 +679,20 @@ static void octnet_intrmod_callback(struct octeon_device 
*oct_dev,
else
dev_info(_dev->pci_dev->dev,
 "Rx-Adaptive Interrupt moderation enabled:%llx\n",
-oct_dev->intrmod.intrmod_enable);
+oct_dev->intrmod.rx_enable);
 
octeon_free_soft_command(oct_dev, sc);
 }
 
 /*  Configure interrupt moderation parameters */
-static int octnet_set_intrmod_cfg(void *oct, struct oct_intrmod_cfg *intr_cfg)
+static int octnet_set_intrmod_cfg(struct lio *lio,
+ struct oct_intrmod_cfg *intr_cfg)
 {
struct octeon_soft_command *sc;
struct oct_intrmod_cmd *cmd;
struct 

[PATCH net-next 05/13] liquidio: Firmware image download

2016-06-21 Thread Raghu Vatsavayi
This patch has firmware image related changes for: firmware
release upon failure, support latest firmware version and
firmware download in 4MB chunks.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c| 18 -
 .../net/ethernet/cavium/liquidio/liquidio_common.h | 10 +--
 .../net/ethernet/cavium/liquidio/octeon_device.c   | 79 --
 3 files changed, 65 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c 
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 8310eb8..5fb1b79 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1375,6 +1375,7 @@ static int octeon_chip_specific_setup(struct 
octeon_device *oct)
 {
u32 dev_id, rev_id;
int ret = 1;
+   char *s;
 
pci_read_config_dword(oct->pci_dev, 0, _id);
pci_read_config_dword(oct->pci_dev, 8, _id);
@@ -1384,22 +1385,27 @@ static int octeon_chip_specific_setup(struct 
octeon_device *oct)
case OCTEON_CN68XX_PCIID:
oct->chip_id = OCTEON_CN68XX;
ret = lio_setup_cn68xx_octeon_device(oct);
+   s = "CN68XX";
break;
 
case OCTEON_CN66XX_PCIID:
oct->chip_id = OCTEON_CN66XX;
ret = lio_setup_cn66xx_octeon_device(oct);
+   s = "CN66XX";
break;
+
default:
+   s = "?";
dev_err(>pci_dev->dev, "Unknown device found (dev_id: 
%x)\n",
dev_id);
}
 
if (!ret)
-   dev_info(>pci_dev->dev, "CN68XX PASS%d.%d %s\n",
+   dev_info(>pci_dev->dev, "%s PASS%d.%d %s Version: %s\n", s,
 OCTEON_MAJOR_REV(oct),
 OCTEON_MINOR_REV(oct),
-octeon_get_conf(oct)->card_name);
+octeon_get_conf(oct)->card_name,
+LIQUIDIO_VERSION);
 
return ret;
 }
@@ -1772,6 +1778,7 @@ static int load_firmware(struct octeon_device *oct)
if (ret) {
dev_err(>pci_dev->dev, "Request firmware failed. Could not 
find file %s.\n.",
fw_name);
+   release_firmware(fw);
return ret;
}
 
@@ -1841,6 +1848,9 @@ static void if_cfg_callback(struct octeon_device *oct,
CVM_CAST64(resp->status));
ACCESS_ONCE(ctx->cond) = 1;
 
+   snprintf(oct->fw_info.liquidio_firmware_version, 32, "%s",
+resp->cfg_info.liquidio_firmware_version);
+
/* This barrier is required to be sure that the response has been
 * written fully before waking up the handler
 */
@@ -3635,6 +3645,7 @@ static void nic_starter(struct work_struct *work)
 static int octeon_device_init(struct octeon_device *octeon_dev)
 {
int j, ret;
+   char bootcmd[] = "\n";
struct octeon_device_priv *oct_priv =
(struct octeon_device_priv *)octeon_dev->priv;
atomic_set(_dev->status, OCT_DEV_BEGIN_STATE);
@@ -3767,6 +3778,9 @@ static int octeon_device_init(struct octeon_device 
*octeon_dev)
return 1;
}
 
+   /* Divert uboot to take commands from host instead. */
+   ret = octeon_console_send_cmd(octeon_dev, bootcmd, 50);
+
dev_dbg(_dev->pci_dev->dev, "Initializing consoles\n");
ret = octeon_init_consoles(octeon_dev);
if (ret) {
diff --git a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h 
b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
index 3738877..1ef9001 100644
--- a/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
+++ b/drivers/net/ethernet/cavium/liquidio/liquidio_common.h
@@ -30,11 +30,10 @@
 
 #include "octeon_config.h"
 
-#define LIQUIDIO_VERSION"1.1.9"
-#define LIQUIDIO_MAJOR_VERSION  1
-#define LIQUIDIO_MINOR_VERSION  1
-#define LIQUIDIO_MICRO_VERSION  9
-
+#define LIQUIDIO_BASE_VERSION   "1.4"
+#define LIQUIDIO_MICRO_VERSION  ".1"
+#define LIQUIDIO_PACKAGE ""
+#define LIQUIDIO_VERSION  "1.4.1"
 #define CONTROL_IQ 0
 /** Tag types used by Octeon cores in its work. */
 enum octeon_tag_type {
@@ -712,6 +711,7 @@ struct liquidio_if_cfg_info {
u64 iqmask; /** mask for IQs enabled for  the port */
u64 oqmask; /** mask for OQs enabled for the port */
struct oct_link_info linfo; /** initial link information */
+   char   liquidio_firmware_version[32];
 };
 
 /** Stats for each NIC port in RX direction. */
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c 
b/drivers/net/ethernet/cavium/liquidio/octeon_device.c

[PATCH net-next 06/13] liquidio: New unload state

2016-06-21 Thread Raghu Vatsavayi
This patch adds new state so that the ctrl packets are not sent
to firmware during unload time and only rx packets are allowed.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c  |  4 
 drivers/net/ethernet/cavium/liquidio/octeon_device.h |  6 ++
 drivers/net/ethernet/cavium/liquidio/octeon_nic.c| 20 ++--
 .../net/ethernet/cavium/liquidio/response_manager.c  |  2 ++
 4 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c 
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 5fb1b79..4440086 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1327,6 +1327,10 @@ static int liquidio_stop_nic_module(struct octeon_device 
*oct)
return 1;
}
 
+   spin_lock_bh(>cmd_resp_wqlock);
+   oct->cmd_resp_state = OCT_DRV_OFFLINE;
+   spin_unlock_bh(>cmd_resp_wqlock);
+
for (i = 0; i < oct->ifcount; i++) {
lio = GET_LIO(oct->props[i].netdev);
for (j = 0; j < lio->linfo.num_rxpciq; j++)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.h 
b/drivers/net/ethernet/cavium/liquidio/octeon_device.h
index abfc0d6..ceb905d 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.h
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.h
@@ -383,6 +383,10 @@ struct octeon_device {
 
struct cavium_wq dma_comp_wq;
 
+   /** Lock for dma response list */
+   spinlock_t cmd_resp_wqlock;
+   u32 cmd_resp_state;
+
struct cavium_wq check_db_wq[MAX_POSSIBLE_OCTEON_INSTR_QUEUES];
 
struct cavium_wk nic_poll_work;
@@ -392,6 +396,8 @@ struct octeon_device {
void *priv;
 };
 
+#define  OCT_DRV_ONLINE 1
+#define  OCT_DRV_OFFLINE 2
 #define  OCTEON_CN6XXX(oct)   ((oct->chip_id == OCTEON_CN66XX) || \
   (oct->chip_id == OCTEON_CN68XX))
 #define CHIP_FIELD(oct, TYPE, field) \
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_nic.c 
b/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
index 7843b8a..36f1970 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_nic.c
@@ -171,20 +171,36 @@ octnet_send_nic_ctrl_pkt(struct octeon_device *oct,
int retval;
struct octeon_soft_command *sc = NULL;
 
+   spin_lock_bh(>cmd_resp_wqlock);
+   /* Allow only rx ctrl command to stop traffic on the chip
+* during offline operations
+*/
+   if ((oct->cmd_resp_state == OCT_DRV_OFFLINE) &&
+   (nctrl->ncmd.s.cmd != OCTNET_CMD_RX_CTL)) {
+   spin_unlock_bh(>cmd_resp_wqlock);
+   dev_err(>pci_dev->dev,
+   "%s cmd:%d not processed since driver offline\n",
+   __func__, nctrl->ncmd.s.cmd);
+   return -1;
+   }
+
sc = octnic_alloc_ctrl_pkt_sc(oct, nctrl);
if (!sc) {
dev_err(>pci_dev->dev, "%s soft command alloc failed\n",
__func__);
+   spin_unlock_bh(>cmd_resp_wqlock);
return -1;
}
 
retval = octeon_send_soft_command(oct, sc);
if (retval == IQ_SEND_FAILED) {
octeon_free_soft_command(oct, sc);
-   dev_err(>pci_dev->dev, "%s soft command send failed 
status: %x\n",
-   __func__, retval);
+   dev_err(>pci_dev->dev, "%s soft command:%d send failed 
status: %x\n",
+   __func__, nctrl->ncmd.s.cmd, retval);
+   spin_unlock_bh(>cmd_resp_wqlock);
return -1;
}
 
+   spin_unlock_bh(>cmd_resp_wqlock);
return retval;
 }
diff --git a/drivers/net/ethernet/cavium/liquidio/response_manager.c 
b/drivers/net/ethernet/cavium/liquidio/response_manager.c
index e2e9103..c93210f 100644
--- a/drivers/net/ethernet/cavium/liquidio/response_manager.c
+++ b/drivers/net/ethernet/cavium/liquidio/response_manager.c
@@ -54,6 +54,7 @@ int octeon_setup_response_list(struct octeon_device *oct)
spin_lock_init(>response_list[i].lock);
atomic_set(>response_list[i].pending_req_count, 0);
}
+   spin_lock_init(>cmd_resp_wqlock);
 
oct->dma_comp_wq.wq = alloc_workqueue("dma-comp", WQ_MEM_RECLAIM, 0);
if (!oct->dma_comp_wq.wq) {
@@ -64,6 +65,7 @@ int octeon_setup_response_list(struct octeon_device *oct)
cwq = >dma_comp_wq;
INIT_DELAYED_WORK(>wk.work, oct_poll_req_completion);
cwq->wk.ctxptr = oct;
+   oct->cmd_resp_state = 

[PATCH net-next 07/13] liquidio: chip reset changes

2016-06-21 Thread Raghu Vatsavayi
This patch resolves the order of chip reset while destroying
the resources by postoponing soft reset in destroy resources
function until all queues are removed properly.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c 
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 4440086..56b1d67 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1180,12 +1180,6 @@ static void octeon_destroy_resources(struct 
octeon_device *oct)
if (oct->flags & LIO_FLAG_MSI_ENABLED)
pci_disable_msi(oct->pci_dev);
 
-   /* Soft reset the octeon device before exiting */
-   oct->fn_list.soft_reset(oct);
-
-   /* Disable the device, releasing the PCI INT */
-   pci_disable_device(oct->pci_dev);
-
/* fallthrough */
case OCT_DEV_IN_RESET:
case OCT_DEV_DROQ_INIT_DONE:
@@ -1232,11 +1226,18 @@ static void octeon_destroy_resources(struct 
octeon_device *oct)
 
/* fallthrough */
case OCT_DEV_PCI_MAP_DONE:
+
+   /* Soft reset the octeon device before exiting */
+   oct->fn_list.soft_reset(oct);
+
octeon_unmap_pci_barx(oct, 0);
octeon_unmap_pci_barx(oct, 1);
 
/* fallthrough */
case OCT_DEV_BEGIN_STATE:
+   /* Disable the device, releasing the PCI INT */
+   pci_disable_device(oct->pci_dev);
+
/* Nothing to be done here either */
break;
}   /* end switch(oct->status) */
-- 
1.8.3.1



[PATCH net-next 03/13] liquidio: Vlan filtering

2016-06-21 Thread Raghu Vatsavayi
This patch adds supports for Vlan filtering for liquidio driver.

Signed-off-by: Derek Chickles 
Signed-off-by: Satanand Burla 
Signed-off-by: Felix Manlunas 
Signed-off-by: Raghu Vatsavayi 
Signed-off-by: Raghu Vatsavayi 
---
 drivers/net/ethernet/cavium/liquidio/lio_main.c| 82 +-
 .../net/ethernet/cavium/liquidio/liquidio_common.h |  4 ++
 2 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c 
b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 4b95dbf..9f3a93b 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -2310,6 +2310,21 @@ void liquidio_link_ctrl_cmd_completion(void *nctrl_ptr)
 netdev->name);
break;
 
+   case OCTNET_CMD_ENABLE_VLAN_FILTER:
+   dev_info(>pci_dev->dev, "%s VLAN filter enabled\n",
+netdev->name);
+   break;
+
+   case OCTNET_CMD_ADD_VLAN_FILTER:
+   dev_info(>pci_dev->dev, "%s VLAN filter %d added\n",
+netdev->name, nctrl->ncmd.s.param1);
+   break;
+
+   case OCTNET_CMD_DEL_VLAN_FILTER:
+   dev_info(>pci_dev->dev, "%s VLAN filter %d removed\n",
+netdev->name, nctrl->ncmd.s.param1);
+   break;
+
case OCTNET_CMD_SET_SETTINGS:
dev_info(>pci_dev->dev, "%s settings changed\n",
 netdev->name);
@@ -2965,6 +2980,61 @@ static void liquidio_tx_timeout(struct net_device 
*netdev)
txqs_wake(netdev);
 }
 
+static int liquidio_vlan_rx_add_vid(struct net_device *netdev,
+   __be16 proto __attribute__((unused)),
+   u16 vid)
+{
+   struct lio *lio = GET_LIO(netdev);
+   struct octeon_device *oct = lio->oct_dev;
+   struct octnic_ctrl_pkt nctrl;
+   int ret = 0;
+
+   memset(, 0, sizeof(struct octnic_ctrl_pkt));
+
+   nctrl.ncmd.u64 = 0;
+   nctrl.ncmd.s.cmd = OCTNET_CMD_ADD_VLAN_FILTER;
+   nctrl.ncmd.s.param1 = vid;
+   nctrl.iq_no = lio->linfo.txpciq[0].s.q_no;
+   nctrl.wait_time = 100;
+   nctrl.netpndev = (u64)netdev;
+   nctrl.cb_fn = liquidio_link_ctrl_cmd_completion;
+
+   ret = octnet_send_nic_ctrl_pkt(lio->oct_dev, );
+   if (ret < 0) {
+   dev_err(>pci_dev->dev, "Add VLAN filter failed in core 
(ret: 0x%x)\n",
+   ret);
+   }
+
+   return ret;
+}
+
+static int liquidio_vlan_rx_kill_vid(struct net_device *netdev,
+__be16 proto __attribute__((unused)),
+u16 vid)
+{
+   struct lio *lio = GET_LIO(netdev);
+   struct octeon_device *oct = lio->oct_dev;
+   struct octnic_ctrl_pkt nctrl;
+   int ret = 0;
+
+   memset(, 0, sizeof(struct octnic_ctrl_pkt));
+
+   nctrl.ncmd.u64 = 0;
+   nctrl.ncmd.s.cmd = OCTNET_CMD_DEL_VLAN_FILTER;
+   nctrl.ncmd.s.param1 = vid;
+   nctrl.iq_no = lio->linfo.txpciq[0].s.q_no;
+   nctrl.wait_time = 100;
+   nctrl.netpndev = (u64)netdev;
+   nctrl.cb_fn = liquidio_link_ctrl_cmd_completion;
+
+   ret = octnet_send_nic_ctrl_pkt(lio->oct_dev, );
+   if (ret < 0) {
+   dev_err(>pci_dev->dev, "Add VLAN filter failed in core 
(ret: 0x%x)\n",
+   ret);
+   }
+   return ret;
+}
+
 int liquidio_set_feature(struct net_device *netdev, int cmd, u16 param1)
 {
struct lio *lio = GET_LIO(netdev);
@@ -3056,6 +3126,9 @@ static struct net_device_ops lionetdevops = {
.ndo_set_mac_address= liquidio_set_mac,
.ndo_set_rx_mode= liquidio_set_mcast_list,
.ndo_tx_timeout = liquidio_tx_timeout,
+
+   .ndo_vlan_rx_add_vid= liquidio_vlan_rx_add_vid,
+   .ndo_vlan_rx_kill_vid   = liquidio_vlan_rx_kill_vid,
.ndo_change_mtu = liquidio_change_mtu,
.ndo_do_ioctl   = liquidio_ioctl,
.ndo_fix_features   = liquidio_fix_features,
@@ -3319,7 +3392,8 @@ static int setup_nic_devices(struct octeon_device 
*octeon_dev)
 
netdev->vlan_features = lio->dev_capability;
/* Add any unchangeable hw features */
-   lio->dev_capability |=  NETIF_F_HW_VLAN_CTAG_RX |
+   lio->dev_capability |=  NETIF_F_HW_VLAN_CTAG_FILTER |
+   NETIF_F_HW_VLAN_CTAG_RX |
NETIF_F_HW_VLAN_CTAG_TX;
 
netdev->features = (lio->dev_capability & ~NETIF_F_LRO);
@@ -3377,9 +3451,11 @@ static int setup_nic_devices(struct octeon_device 
*octeon_dev)
liquidio_set_feature(netdev, 

Re: [PATCH net-next v3] tcp: use RFC6298 compliant TCP RTO calculation

2016-06-21 Thread Yuchung Cheng
On Fri, Jun 17, 2016 at 11:56 AM, Yuchung Cheng  wrote:
>
> On Fri, Jun 17, 2016 at 11:32 AM, David Miller  wrote:
> >
> > From: Daniel Metz 
> > Date: Wed, 15 Jun 2016 20:00:03 +0200
> >
> > > This patch adjusts Linux RTO calculation to be RFC6298 Standard
> > > compliant. MinRTO is no longer added to the computed RTO, RTO damping
> > > and overestimation are decreased.
> >  ...
> >
> > Yuchung, I assume I am waiting for you to do the testing you said
> > you would do for this patch, right?
> Yes I spent the last two days resolving some unrelated glitches to
> start my testing on Web servers. I should be able to get some results
> over the weekend.
>
> I will test
> 0) current Linux
> 1) this patch
> 2) RFC6298 with min_RTO=1sec
> 3) RFC6298 with minimum RTTVAR of 200ms (so it is more like current
> Linux style of min RTO which only applies to RTTVAR)
>
> and collect the TCP latency (how long to send an HTTP response) and
> (spurious) timeout & retransmission stats.
>
Thanks for the patience. I've collected data from some Google Web
servers. They serve both a mix of US and SouthAm users using
HTTP1 and HTTP2. The traffic is Web browsing (e.g., search, maps,
gmails, etc but not Youtube videos). The mean RTT is about 100ms.

The user connections were split into 4 groups of different TCP RTO
configs. Each group has many millions of connections but the
size variation among groups is well under 1%.

B: baseline Linux
D: this patch
R: change RTTYAR averaging as in D, but bound RTO to 1sec per RFC6298
Y: change RTTVAR averaging as in D, but bound RTTVAR to 200ms instead (like B)

For mean TCP latency of HTTP responses (first byte sent to last byte
acked), B < R < Y < D. But the differences are so insignificant (<1%).
The median, 95pctl, and 99pctl has similar indifference. In summary
there's hardly visible impact on latency. I also look at only response
less than 4KB but do not see a different picture.

The main difference is the retransmission rate where R =~ Y < B =~D.
R and Y are ~20% lower than B and D. Parsing the SNMP stats reveal
more interesting details. The table shows the deltas in percentage to
the baseline B.

D  R Y
--
Timeout  +12%   -16%  -16%
TailLossProb +28%-7%   -7%
DSACK_rcvd   +37%-7%   -7%
Cwnd-undo+16%   -29%  -29%

RTO change affects TLP because TLP will use the min of RTO and TLP
timer value to arm the probe timer.

The stats indicate that the main culprit of spurious timeouts / rtx is
the RTO lower-bound. But they also show the RFC RTTVAR averaging is as
good as current Linux approach.

Given that I would recommend we revise this patch to use the RFC
averaging but keep existing lower-bound (of RTTVAR to 200ms). We can
further experiment the lower-bound and change that in a separate
patch.


Re: [PATCH -next 4/4] cgroup: bpf: Add an example to do cgroup checking in BPF

2016-06-21 Thread Alexei Starovoitov
On Tue, Jun 21, 2016 at 05:23:22PM -0700, Martin KaFai Lau wrote:
> test_cgrp2_array_pin.c:
> A userland program that creates a bpf_map (BPF_MAP_TYPE_GROUP_ARRAY),
> pouplates/updates it with a cgroup2's backed fd and pins it to a
> bpf-fs's file.  The pinned file can be loaded by tc and then used
> by the bpf prog later.  This program can also update an existing pinned
> array and it could be useful for debugging/testing purpose.
> 
> test_cgrp2_tc_kern.c:
> A bpf prog which should be loaded by tc.  It is to demonstrate
> the usage of bpf_skb_in_cgroup.
> 
> test_cgrp2_tc.sh:
> A script that glues the test_cgrp2_array_pin.c and
> test_cgrp2_tc_kern.c together.  The idea is like:
> 1. Use test_cgrp2_array_pin.c to populate a BPF_MAP_TYPE_CGROUP_ARRAY
>with a cgroup fd
> 2. Load the test_cgrp2_tc_kern.o by tc
> 3. Do a 'ping -6 ff02::1%ve' to ensure the packet has been
>dropped because of a match on the cgroup
> 
> Most of the lines in test_cgrp2_tc.sh is the boilerplate
> to setup the cgroup/bpf-fs/net-devices/netns...etc.  It is
> not bulletproof on errors but should work well enough and
> give enough debug info if things did not go well.
> 
> Signed-off-by: Martin KaFai Lau 
> Cc: Alexei Starovoitov 
> Cc: Daniel Borkmann 
> Cc: Tejun Heo 
> ---
>  samples/bpf/Makefile   |   3 +
>  samples/bpf/bpf_helpers.h  |   2 +
>  samples/bpf/test_cgrp2_array_pin.c | 109 +
>  samples/bpf/test_cgrp2_tc.sh   | 189 
> +
>  samples/bpf/test_cgrp2_tc_kern.c   |  71 ++
>  5 files changed, 374 insertions(+)
...
> +struct bpf_elf_map SEC("maps") test_cgrp2_array_pin = {
> + .type   = BPF_MAP_TYPE_CGROUP_ARRAY,
> + .size_key   = sizeof(uint32_t),
> + .size_value = sizeof(uint32_t),
> + .pinning= PIN_GLOBAL_NS,
> + .max_elem   = 1,
> +};
> +
> +SEC("filter")
> +int handle_egress(struct __sk_buff *skb)
> +{
> + void *data = (void *)(long)skb->data;
> + struct eth_hdr *eth = data;
> + struct ipv6hdr *ip6h = data + sizeof(*eth);
> + void *data_end = (void *)(long)skb->data_end;
> + char dont_care_msg[] = "dont care %04x %d\n";
> + char pass_msg[] = "pass\n";
> + char reject_msg[] = "reject\n";
> +
> + /* single length check */
> + if (data + sizeof(*eth) + sizeof(*ip6h) > data_end)
> + return TC_ACT_OK;

love the test case.
It's using tc + clsact + cls_bpf in da mode + bpffs + direct packet access
and new cgroup helper.
All the most recent features I can think of :)

Acked-by: Alexei Starovoitov 



[PATCH iproute2 1/3] ss: Refactor inet_show_sock

2016-06-21 Thread David Ahern
Extract parsing of sockstat and filter from inet_show_sock.
While moving run_ssfilter into callers of inet_show_sock enable
userspace filtering before the kill.

Signed-off-by: David Ahern 
---
 misc/ss.c | 68 ---
 1 file changed, 43 insertions(+), 25 deletions(-)

diff --git a/misc/ss.c b/misc/ss.c
index 02be7e7407df..a22cfebadfa2 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -2038,42 +2038,47 @@ static void tcp_show_info(const struct nlmsghdr *nlh, 
struct inet_diag_msg *r,
}
 }
 
-static int inet_show_sock(struct nlmsghdr *nlh, struct filter *f, int protocol)
+static void parse_diag_msg(struct nlmsghdr *nlh, struct sockstat *s)
 {
struct rtattr *tb[INET_DIAG_MAX+1];
struct inet_diag_msg *r = NLMSG_DATA(nlh);
-   struct sockstat s = {};
 
parse_rtattr(tb, INET_DIAG_MAX, (struct rtattr *)(r+1),
 nlh->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
 
-   s.state = r->idiag_state;
-   s.local.family  = s.remote.family = r->idiag_family;
-   s.lport = ntohs(r->id.idiag_sport);
-   s.rport = ntohs(r->id.idiag_dport);
-   s.wq= r->idiag_wqueue;
-   s.rq= r->idiag_rqueue;
-   s.ino   = r->idiag_inode;
-   s.uid   = r->idiag_uid;
-   s.iface = r->id.idiag_if;
-   s.sk= cookie_sk_get(>id.idiag_cookie[0]);
-
-   if (s.local.family == AF_INET) {
-   s.local.bytelen = s.remote.bytelen = 4;
+   s->state= r->idiag_state;
+   s->local.family = s->remote.family = r->idiag_family;
+   s->lport= ntohs(r->id.idiag_sport);
+   s->rport= ntohs(r->id.idiag_dport);
+   s->wq   = r->idiag_wqueue;
+   s->rq   = r->idiag_rqueue;
+   s->ino  = r->idiag_inode;
+   s->uid  = r->idiag_uid;
+   s->iface= r->id.idiag_if;
+   s->sk   = cookie_sk_get(>id.idiag_cookie[0]);
+
+   if (s->local.family == AF_INET) {
+   s->local.bytelen = s->remote.bytelen = 4;
} else {
-   s.local.bytelen = s.remote.bytelen = 16;
+   s->local.bytelen = s->remote.bytelen = 16;
}
 
-   memcpy(s.local.data, r->id.idiag_src, s.local.bytelen);
-   memcpy(s.remote.data, r->id.idiag_dst, s.local.bytelen);
+   memcpy(s->local.data, r->id.idiag_src, s->local.bytelen);
+   memcpy(s->remote.data, r->id.idiag_dst, s->local.bytelen);
+}
 
-   if (f && f->f && run_ssfilter(f->f, ) == 0)
-   return 0;
+static int inet_show_sock(struct nlmsghdr *nlh, struct sockstat *s, int 
protocol)
+{
+   struct rtattr *tb[INET_DIAG_MAX+1];
+   struct inet_diag_msg *r = NLMSG_DATA(nlh);
+
+   parse_rtattr(tb, INET_DIAG_MAX, (struct rtattr *)(r+1),
+nlh->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
 
if (tb[INET_DIAG_PROTOCOL])
protocol = *(__u8 *)RTA_DATA(tb[INET_DIAG_PROTOCOL]);
 
-   inet_stats_print(, protocol);
+   inet_stats_print(s, protocol);
 
if (show_options) {
struct tcpstat t = {};
@@ -2085,8 +2090,8 @@ static int inet_show_sock(struct nlmsghdr *nlh, struct 
filter *f, int protocol)
}
 
if (show_details) {
-   sock_details_print();
-   if (s.local.family == AF_INET6 && tb[INET_DIAG_SKV6ONLY]) {
+   sock_details_print(s);
+   if (s->local.family == AF_INET6 && tb[INET_DIAG_SKV6ONLY]) {
unsigned char v6only;
 
v6only = *(__u8 *)RTA_DATA(tb[INET_DIAG_SKV6ONLY]);
@@ -2268,9 +2273,16 @@ static int show_one_inet_sock(const struct sockaddr_nl 
*addr,
int err;
struct inet_diag_arg *diag_arg = arg;
struct inet_diag_msg *r = NLMSG_DATA(h);
+   struct sockstat s = {};
 
if (!(diag_arg->f->families & (1 << r->idiag_family)))
return 0;
+
+   parse_diag_msg(h, );
+
+   if (diag_arg->f->f && run_ssfilter(diag_arg->f->f, ) == 0)
+   return 0;
+
if (diag_arg->f->kill && kill_inet_sock(h, arg) != 0) {
if (errno == EOPNOTSUPP || errno == ENOENT) {
/* Socket can't be closed, or is already closed. */
@@ -2280,7 +2292,7 @@ static int show_one_inet_sock(const struct sockaddr_nl 
*addr,
return -1;
}
}
-   if ((err = inet_show_sock(h, diag_arg->f, diag_arg->protocol)) < 0)
+   if ((err = inet_show_sock(h, , diag_arg->protocol)) < 0)
return err;
 
return 0;
@@ -2345,6 +2357,7 @@ static int tcp_show_netlink_file(struct filter *f)
while (1) {
int status, err;
struct nlmsghdr *h = (struct nlmsghdr *)buf;
+   struct sockstat s = {};
 
status = fread(buf, 1, sizeof(*h), fp);

[PATCH iproute2 0/3] ss: Add support to filter by device

2016-06-21 Thread David Ahern
Add support for specifying device name in the filter to ss.
The kernel does not provide support for iface filtering, so if
the user specifies 'dev == NAME' or 'dev != NAME' all filtering
is done in userspace.

I will send a patch to add support for iface filtering in the kernel,
but the reality is that ss will need to accommodate both (ie., lack of
kernel support) for some time - which this set provides.

David Ahern (3):
  ss: Refactor inet_show_sock
  ss: Allow ssfilter_bytecompile to return 0
  ss: Add support to filter on device

 misc/ss.c   | 152 +---
 misc/ssfilter.h |   2 +
 misc/ssfilter.y |  22 +++-
 3 files changed, 135 insertions(+), 41 deletions(-)

-- 
2.1.4



[PATCH iproute2 3/3] ss: Add support to filter on device

2016-06-21 Thread David Ahern
Add support for device names in the filter. Example:

root@kenny:~# ss -t  'sport == :22 && dev == red'
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
ESTAB  0  0  10.100.1.2%red:ssh  10.100.1.254:47814
ESTAB  0  0   2100:1::2%red:ssh2100:1::64:49406

Since kernel does not support iface in the filter specifying a
device name means all filtering is done in userspace.

Signed-off-by: David Ahern 
---
 misc/ss.c   | 32 
 misc/ssfilter.h |  2 ++
 misc/ssfilter.y | 22 +-
 3 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/misc/ss.c b/misc/ss.c
index 3419a88c33be..6f0ad0295918 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1043,6 +1043,7 @@ static void inet_addr_print(const inet_prefix *a, int 
port, unsigned int ifindex
 struct aafilter {
inet_prefix addr;
int port;
+   unsigned intiface;
struct aafilter *next;
 };
 
@@ -1157,7 +1158,12 @@ static int run_ssfilter(struct ssfilter *f, struct 
sockstat *s)
 
return s->lport <= a->port;
}
+   case SSF_DEVCOND:
+   {
+   struct aafilter *a = (void *)f->pred;
 
+   return s->iface == a->iface;
+   }
/* Yup. It is recursion. Sorry. */
case SSF_AND:
return run_ssfilter(f->pred, s) && run_ssfilter(f->post, s);
@@ -1328,6 +1334,11 @@ static int ssfilter_bytecompile(struct ssfilter *f, char 
**bytecode)
*bytecode = a;
return l1+4;
}
+   case SSF_DEVCOND:
+   {
+   /* bytecompile for SSF_DEVCOND not supported yet */
+return 0;
+   }
default:
abort();
}
@@ -1416,6 +1427,27 @@ static int xll_name_to_index(const char *dev)
return ll_name_to_index(dev);
 }
 
+void *parse_devcond(char *name)
+{
+   struct aafilter a = { .iface = 0 };
+   struct aafilter *res;
+
+   a.iface = xll_name_to_index(name);
+   if (a.iface == 0) {
+   char *end;
+   unsigned long res;
+
+   res = strtoul(name, , 0);
+   if (!end || end == name || *end || res > UINT_MAX)
+   return NULL;
+   }
+
+   res = malloc(sizeof(*res));
+   *res = a;
+
+   return res;
+}
+
 void *parse_hostcond(char *addr, bool is_port)
 {
char *port = NULL;
diff --git a/misc/ssfilter.h b/misc/ssfilter.h
index 53922a844457..c7db8eee9578 100644
--- a/misc/ssfilter.h
+++ b/misc/ssfilter.h
@@ -8,6 +8,7 @@
 #define SSF_S_GE  7
 #define SSF_S_LE  8
 #define SSF_S_AUTO  9
+#define SSF_DEVCOND 10
 
 #include 
 
@@ -20,3 +21,4 @@ struct ssfilter
 
 int ssfilter_parse(struct ssfilter **f, int argc, char **argv, FILE *fp);
 void *parse_hostcond(char *addr, bool is_port);
+void *parse_devcond(char *name);
diff --git a/misc/ssfilter.y b/misc/ssfilter.y
index a258d04b85d7..14bf9817f2c3 100644
--- a/misc/ssfilter.y
+++ b/misc/ssfilter.y
@@ -36,7 +36,7 @@ static void yyerror(char *s)
 
 %}
 
-%token HOSTCOND DCOND SCOND DPORT SPORT LEQ GEQ NEQ AUTOBOUND
+%token HOSTCOND DCOND SCOND DPORT SPORT LEQ GEQ NEQ AUTOBOUND DEVCOND DEVNAME
 %left '|'
 %left '&'
 %nonassoc '!'
@@ -108,6 +108,14 @@ expr:  DCOND HOSTCOND
 {
$$ = alloc_node(SSF_NOT, alloc_node(SSF_SCOND, $3));
 }
+| DEVNAME '=' DEVCOND
+{
+   $$ = alloc_node(SSF_DEVCOND, $3);
+}
+| DEVNAME NEQ DEVCOND
+{
+   $$ = alloc_node(SSF_NOT, alloc_node(SSF_DEVCOND, $3));
+}
 
 | AUTOBOUND
 {
@@ -237,6 +245,10 @@ int yylex(void)
tok_type = SPORT;
return SPORT;
}
+   if (strcmp(curtok, "dev") == 0) {
+   tok_type = DEVNAME;
+   return DEVNAME;
+   }
if (strcmp(curtok, ">=") == 0 ||
strcmp(curtok, "ge") == 0 ||
strcmp(curtok, "geq") == 0)
@@ -263,6 +275,14 @@ int yylex(void)
tok_type = AUTOBOUND;
return AUTOBOUND;
}
+   if (tok_type == DEVNAME) {
+   yylval = (void*)parse_devcond(curtok);
+   if (yylval == NULL) {
+   fprintf(stderr, "Cannot parse device.\n");
+   exit(1);
+   }
+   return DEVCOND;
+   }
yylval = (void*)parse_hostcond(curtok, tok_type == SPORT || tok_type == 
DPORT);
if (yylval == NULL) {
fprintf(stderr, "Cannot parse dst/src address.\n");
-- 
2.1.4



[PATCH iproute2 2/3] ss: Allow ssfilter_bytecompile to return 0

2016-06-21 Thread David Ahern
Allow ssfilter_bytecompile to return 0 for filter ops the kernel
does not support. If such an op is in the filter string then all
filtering is done in userspace.

Signed-off-by: David Ahern 
---
 misc/ss.c | 52 +---
 1 file changed, 37 insertions(+), 15 deletions(-)

diff --git a/misc/ss.c b/misc/ss.c
index a22cfebadfa2..3419a88c33be 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -1273,11 +1273,16 @@ static int ssfilter_bytecompile(struct ssfilter *f, 
char **bytecode)
 
case SSF_AND:
{
-   char *a1, *a2, *a;
+   char *a1 = NULL, *a2 = NULL, *a;
int l1, l2;
 
l1 = ssfilter_bytecompile(f->pred, );
l2 = ssfilter_bytecompile(f->post, );
+   if (!l1 || !l2) {
+   free(a1);
+   free(a2);
+   return 0;
+   }
if (!(a = malloc(l1+l2))) abort();
memcpy(a, a1, l1);
memcpy(a+l1, a2, l2);
@@ -1288,11 +1293,16 @@ static int ssfilter_bytecompile(struct ssfilter *f, 
char **bytecode)
}
case SSF_OR:
{
-   char *a1, *a2, *a;
+   char *a1 = NULL, *a2 = NULL, *a;
int l1, l2;
 
l1 = ssfilter_bytecompile(f->pred, );
l2 = ssfilter_bytecompile(f->post, );
+   if (!l1 || !l2) {
+   free(a1);
+   free(a2);
+   return 0;
+   }
if (!(a = malloc(l1+l2+4))) abort();
memcpy(a, a1, l1);
memcpy(a+l1+4, a2, l2);
@@ -1303,10 +1313,14 @@ static int ssfilter_bytecompile(struct ssfilter *f, 
char **bytecode)
}
case SSF_NOT:
{
-   char *a1, *a;
+   char *a1 = NULL, *a;
int l1;
 
l1 = ssfilter_bytecompile(f->pred, );
+   if (!l1) {
+   free(a1);
+   return 0;
+   }
if (!(a = malloc(l1+4))) abort();
memcpy(a, a1, l1);
free(a1);
@@ -2126,6 +2140,7 @@ static int tcpdiag_send(int fd, int protocol, struct 
filter *f)
struct msghdr msg;
struct rtattr rta;
struct iovec iov[3];
+   int iovlen = 1;
 
if (protocol == IPPROTO_UDP)
return -1;
@@ -2161,18 +2176,21 @@ static int tcpdiag_send(int fd, int protocol, struct 
filter *f)
};
if (f->f) {
bclen = ssfilter_bytecompile(f->f, );
-   rta.rta_type = INET_DIAG_REQ_BYTECODE;
-   rta.rta_len = RTA_LENGTH(bclen);
-   iov[1] = (struct iovec){ , sizeof(rta) };
-   iov[2] = (struct iovec){ bc, bclen };
-   req.nlh.nlmsg_len += RTA_LENGTH(bclen);
+   if (bclen) {
+   rta.rta_type = INET_DIAG_REQ_BYTECODE;
+   rta.rta_len = RTA_LENGTH(bclen);
+   iov[1] = (struct iovec){ , sizeof(rta) };
+   iov[2] = (struct iovec){ bc, bclen };
+   req.nlh.nlmsg_len += RTA_LENGTH(bclen);
+   iovlen = 3;
+   }
}
 
msg = (struct msghdr) {
.msg_name = (void *),
.msg_namelen = sizeof(nladdr),
.msg_iov = iov,
-   .msg_iovlen = f->f ? 3 : 1,
+   .msg_iovlen = iovlen,
};
 
if (sendmsg(fd, , 0) < 0) {
@@ -2193,6 +2211,7 @@ static int sockdiag_send(int family, int fd, int 
protocol, struct filter *f)
struct msghdr msg;
struct rtattr rta;
struct iovec iov[3];
+   int iovlen = 1;
 
if (family == PF_UNSPEC)
return tcpdiag_send(fd, protocol, f);
@@ -2221,18 +2240,21 @@ static int sockdiag_send(int family, int fd, int 
protocol, struct filter *f)
};
if (f->f) {
bclen = ssfilter_bytecompile(f->f, );
-   rta.rta_type = INET_DIAG_REQ_BYTECODE;
-   rta.rta_len = RTA_LENGTH(bclen);
-   iov[1] = (struct iovec){ , sizeof(rta) };
-   iov[2] = (struct iovec){ bc, bclen };
-   req.nlh.nlmsg_len += RTA_LENGTH(bclen);
+   if (bclen) {
+   rta.rta_type = INET_DIAG_REQ_BYTECODE;
+   rta.rta_len = RTA_LENGTH(bclen);
+   iov[1] = (struct iovec){ , sizeof(rta) };
+   iov[2] = (struct iovec){ bc, bclen };
+   req.nlh.nlmsg_len += RTA_LENGTH(bclen);
+   iovlen = 3;
+   }
}
 
msg = (struct msghdr) {
.msg_name = (void *),
.msg_namelen = sizeof(nladdr),
.msg_iov = iov,
-   .msg_iovlen = f->f ? 3 : 1,
+   

Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

2016-06-21 Thread Leon Romanovsky
On Tue, Jun 21, 2016 at 09:01:57PM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2016/6/21 19:28, Leon Romanovsky wrote:
> >On Tue, Jun 21, 2016 at 06:50:51PM +0800, Wei Hu (Xavier) wrote:
> >>
> >>On 2016/6/20 21:33, Leon Romanovsky wrote:
> >>>On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:
> This patch added the operation for cmd, and added some functions
> for initializing eq table and selecting cmd mode.
> 
> Signed-off-by: Wei Hu 
> Signed-off-by: Nenglong Zhao 
> Signed-off-by: Lijun Ou 
> ---
> PATCH v9/v8/v7/v6:
> - No change over the PATCH v5
> 
> PATCH v5:
> - The initial patch which was redesigned based on the second patch
>    in PATCH v4
> ---
> >>><...>
> >>>
> +#define CMD_MAX_NUM  32
> +
> +int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> +{
> + struct device *dev = _dev->pdev->dev;
> +
> + mutex_init(_dev->cmd.hcr_mutex);
> + sema_init(_dev->cmd.poll_sem, 1);
> + hr_dev->cmd.use_events = 0;
> + hr_dev->cmd.toggle = 1;
> + hr_dev->cmd.max_cmds = CMD_MAX_NUM;
> >>><...>
> >>>
> + for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
> +  hr_cmd->token_mask <<= 1)
> + ;
> + --hr_cmd->token_mask;
> >>>It doesn't look that you dynamically change max_cmds supported.
> >>>Why do you need to calculate token_mask dynamically?
> >>Hi, Leon
> >>
> >> 1. The four lines above are in the function named
> >>hns_roce_cmd_use_events.
> >>  and now this function is only called once in hns_roce_probe.
> >> 2. In hns_roce_cmd_use_events,
> >> we use these 4 lines to achieve the value of hr_cmd->token_mask
> >>according to hr_cmd->max_cmds dynamically,
> >> then we only define one marco for hr_cmd->max_cmds as below:
> >>
> >>#define CMD_MAX_NUM 32
> >>
> >>And it looks more flexible.
> >It is called over engineering.
> >I would recommend to you to remove it.
> >
> >We don't need over complicated code which is executed
> >once with need to maintain with zero benefit.
> >
> >The other places need such simplification too.
> Hi, Leon
> 
> We will modify this place as below:
> In hns_roce_hw_v1.c(for hip06 soc) file:
> 
> void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
> {
> 
> caps->max_cmds = 32;
> 
> }
> 
> In hns_roce_cmd.c file:
> 
> int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
> {
>
>hr_dev->cmd.max_cmds = hr_dev->caps->max_cmds;
>   
>   }
> 
>Can you give more suggestions?

I would be happy to do it if I had enough time to review this code.

General suggestion will be to ask yourself, if value is going to be
changed during the runtime. In case the answer is no, there is no room
to additional logic which translate constant to different value which
will be other constant.

You should do it across all the patchset.

So, in this specific case, the proposed change is not enough, you are
not solving an issue, but hiding it.

Thanks

> 
> 
> Regards
> Wei Hu
> >>Regards
> >>Wei Hu
> >>
> >>
> >>
> 
> 


signature.asc
Description: Digital signature


Re: [PATCH] ibmvnic: fix to use list_for_each_safe() when delete items

2016-06-21 Thread Wei Yongjun

Hi  Thomas Falcon,

Thanks for found this. I will send new patch include your changes.

Regards,
Yongjun Wei

On 06/22/2016 12:01 AM, Thomas Falcon wrote:

On 06/20/2016 10:50 AM, Thomas Falcon wrote:

On 06/17/2016 09:53 PM, weiyj...@163.com wrote:

From: Wei Yongjun 

Since we will remove items off the list using list_del() we need
to use a safe version of the list_for_each() macro aptly named
list_for_each_safe().

Signed-off-by: Wei Yongjun 
---
  drivers/net/ethernet/ibm/ibmvnic.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 864cb21..0b6a922 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -3141,14 +3141,14 @@ static void handle_request_ras_comp_num_rsp(union 
ibmvnic_crq *crq,
  
  static void ibmvnic_free_inflight(struct ibmvnic_adapter *adapter)

  {
-   struct ibmvnic_inflight_cmd *inflight_cmd;
+   struct ibmvnic_inflight_cmd *inflight_cmd, *tmp1;
struct device *dev = >vdev->dev;
-   struct ibmvnic_error_buff *error_buff;
+   struct ibmvnic_error_buff *error_buff, *tmp2;
unsigned long flags;
unsigned long flags2;
  
  	spin_lock_irqsave(>inflight_lock, flags);

-   list_for_each_entry(inflight_cmd, >inflight, list) {
+   list_for_each_entry_safe(inflight_cmd, tmp1, >inflight, list) {
switch (inflight_cmd->crq.generic.cmd) {
case LOGIN:
dma_unmap_single(dev, adapter->login_buf_token,
@@ -3165,8 +3165,8 @@ static void ibmvnic_free_inflight(struct ibmvnic_adapter 
*adapter)
break;
case REQUEST_ERROR_INFO:
spin_lock_irqsave(>error_list_lock, flags2);
-   list_for_each_entry(error_buff, >errors,
-   list) {
+   list_for_each_entry_safe(error_buff, tmp2,
+>errors, list) {
dma_unmap_single(dev, error_buff->dma,
 error_buff->len,
 DMA_FROM_DEVICE);


Thanks!

Acked-by: Thomas Falcon 

Hello, I apologize for prematurely ack'ing this.  There is another situation 
where you could use list_for_each_entry_safe in the function 
handle_error_info_rsp.  Could you include this in your patch, please?

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 864cb21..e9968d9 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2121,7 +2121,7 @@ static void handle_error_info_rsp(union ibmvnic_crq *crq,
   struct ibmvnic_adapter *adapter)
  {
 struct device *dev = >vdev->dev;
-   struct ibmvnic_error_buff *error_buff;
+   struct ibmvnic_error_buff *error_buff, *tmp;
 unsigned long flags;
 bool found = false;
 int i;
@@ -2133,7 +2133,7 @@ static void handle_error_info_rsp(union ibmvnic_crq *crq,
 }
  
 spin_lock_irqsave(>error_list_lock, flags);

-   list_for_each_entry(error_buff, >errors, list)
+   list_for_each_entry_safe(error_buff, tmp, >errors, list)
 if (error_buff->error_id == crq->request_error_rsp.error_id) {
 found = true;
 list_del(_buff->list);



___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev







[PATCH net-next] cxgb4vf: Synchronize access to mailbox

2016-06-21 Thread Hariprasad Shenai
The issue comes when there are multiple threads attempting to use the
mailbox facility at the same time. The issue is the for the Virtual
Function Driver, the only way to get the Virtual Interface statistics
is to issue mailbox commands to ask the firmware for the VI Stats.
And, because the VI Stats command can only retrieve a smallish number of
stats per mailbox command, we have to issue three mailbox commands in quick
succession. When ethtool or netstat command to get interface stats and
interface up/down is run in a loop for every 0.1 sec, we observed
mailbox collisions. And out of the two commands one would fail with
the present code, since we don't queue the second command.

To overcome the above issue, added a queue to access the mailbox.
Whenever a mailbox command is issued add it to the queue. If its at the
head issue the mailbox command, else wait for the existing command to
complete. Usually command takes less than a milli-second to complete.
Also timeout from the loop, if the command under execution takes
long time to run.

In reality, the number of mailbox access collisions is going to be very
rare since no one runs such abusive script.

Signed-off-by: Hariprasad Shenai 
---
 drivers/net/ethernet/chelsio/cxgb4vf/adapter.h |  8 
 .../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c|  2 +
 drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 55 ++
 3 files changed, 65 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h 
b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
index 734dd776c22f..109bc630408b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
@@ -353,6 +353,10 @@ struct hash_mac_addr {
u8 addr[ETH_ALEN];
 };
 
+struct mbox_list {
+   struct list_head list;
+};
+
 /*
  * Per-"adapter" (Virtual Function) information.
  */
@@ -387,6 +391,10 @@ struct adapter {
/* various locks */
spinlock_t stats_lock;
 
+   /* lock for mailbox cmd list */
+   spinlock_t mbox_lock;
+   struct mbox_list mlist;
+
/* support for mailbox command/reply logging */
 #define T4VF_OS_LOG_MBOX_CMDS 256
struct mbox_cmd_log *mbox_log;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index 8d9b2cb74aa2..9f5526478d2f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2774,6 +2774,8 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
 * Initialize SMP data synchronization resources.
 */
spin_lock_init(>stats_lock);
+   spin_lock_init(>mbox_lock);
+   INIT_LIST_HEAD(>mlist.list);
 
/*
 * Map our I/O registers in BAR0.
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
index 955ff7c61f1b..61bfe86da86d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c
@@ -139,6 +139,7 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void 
*cmd, int size,
u32 mbox_ctl = T4VF_CIM_BASE_ADDR + CIM_VF_EXT_MAILBOX_CTRL;
u32 cmd_op = FW_CMD_OP_G(be32_to_cpu(((struct fw_cmd_hdr *)cmd)->hi));
__be64 cmd_rpl[MBOX_LEN / 8];
+   struct mbox_list entry;
 
/* In T6, mailbox size is changed to 128 bytes to avoid
 * invalidating the entire prefetch buffer.
@@ -156,6 +157,51 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void 
*cmd, int size,
size > NUM_CIM_VF_MAILBOX_DATA_INSTANCES * 4)
return -EINVAL;
 
+   /* Queue ourselves onto the mailbox access list.  When our entry is at
+* the front of the list, we have rights to access the mailbox.  So we
+* wait [for a while] till we're at the front [or bail out with an
+* EBUSY] ...
+*/
+   spin_lock(>mbox_lock);
+   list_add_tail(, >mlist.list);
+   spin_unlock(>mbox_lock);
+
+   delay_idx = 0;
+   ms = delay[0];
+
+   for (i = 0; ; i += ms) {
+   /* If we've waited too long, return a busy indication.  This
+* really ought to be based on our initial position in the
+* mailbox access list but this is a start.  We very rearely
+* contend on access to the mailbox ...
+*/
+   if (i > FW_CMD_MAX_TIMEOUT) {
+   spin_lock(>mbox_lock);
+   list_del();
+   spin_unlock(>mbox_lock);
+   ret = -EBUSY;
+   t4vf_record_mbox(adapter, cmd, size, access, ret);
+   return ret;
+   }
+
+   /* If we're at the head, break out and start the mailbox
+* protocol.
+*/
+   if (list_first_entry(>mlist.list, struct 

[net-next] samples/bpf: set max locked memory to ulimited

2016-06-21 Thread William Tu
Signed-off-by: William Tu 
---
 samples/bpf/sockex2_user.c | 3 +++
 samples/bpf/sockex3_user.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/samples/bpf/sockex2_user.c b/samples/bpf/sockex2_user.c
index 29a276d..8a4085c 100644
--- a/samples/bpf/sockex2_user.c
+++ b/samples/bpf/sockex2_user.c
@@ -5,6 +5,7 @@
 #include "bpf_load.h"
 #include 
 #include 
+#include 
 
 struct pair {
__u64 packets;
@@ -13,11 +14,13 @@ struct pair {
 
 int main(int ac, char **argv)
 {
+   struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
char filename[256];
FILE *f;
int i, sock;
 
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
+   setrlimit(RLIMIT_MEMLOCK, );
 
if (load_bpf_file(filename)) {
printf("%s", bpf_log_buf);
diff --git a/samples/bpf/sockex3_user.c b/samples/bpf/sockex3_user.c
index 2617772..d4184ab 100644
--- a/samples/bpf/sockex3_user.c
+++ b/samples/bpf/sockex3_user.c
@@ -5,6 +5,7 @@
 #include "bpf_load.h"
 #include 
 #include 
+#include 
 
 struct flow_keys {
__be32 src;
@@ -23,11 +24,13 @@ struct pair {
 
 int main(int argc, char **argv)
 {
+   struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
char filename[256];
FILE *f;
int i, sock;
 
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
+   setrlimit(RLIMIT_MEMLOCK, );
 
if (load_bpf_file(filename)) {
printf("%s", bpf_log_buf);
-- 
2.5.0



Re: [PATCH] ppc: Fix BPF JIT for ABIv2

2016-06-21 Thread Michael Ellerman
On Tue, 2016-06-21 at 08:45 -0700, Alexei Starovoitov wrote:
> On 6/21/16 7:47 AM, Thadeu Lima de Souza Cascardo wrote:
> > > > 
> > > > The calling convention is different with ABIv2 and so we'll need changes
> > > > in bpf_slow_path_common() and sk_negative_common().
> > > 
> > > How big would those changes be? Do we know?
> > > 
> > > How come no one reported this was broken previously? This is the first 
> > > I've
> > > heard of it being broken.
> > > 
> > 
> > I just heard of it less than two weeks ago, and only could investigate it 
> > last
> > week, when I realized mainline was also affected.
> > 
> > It looks like the little-endian support for classic JIT were done before the
> > conversion to ABIv2. And as JIT is disabled by default, no one seems to have
> > exercised it.
> 
> it's not a surprise unfortunately. The JITs that were written before
> test_bpf.ko was developed were missing corner cases. Typical tcpdump
> would be fine, but fragmented packets, negative offsets and
> out-out-bounds wouldn't be handled correctly.
> I'd suggest to validate the stable backport with test_bpf as well.
 
OK thanks.

I have been running seltests/net/test_bpf, but I realise now it doesn't enable
the JIT.

cheers



Re: [PATCH net-next 0/8] tou: Transports over UDP - part I

2016-06-21 Thread David Ahern

On 6/21/16 9:42 PM, Jerry Chu wrote:

Yes TOU may lower the bar for random hacks by Joe Random. But I'd argue
no large organization would serious consider or dare deploy TCP stack
with random hacks.


There are userspace network stacks that have been around for years and 
widely deployed on devices that basically use Linux as the boot OS.


[PATCH iproute2] man: ip-link: Add vrf type

2016-06-21 Thread David Ahern
Add description for vrf type to ip-link man page.

Signed-off-by: David Ahern 
---
 man/man8/ip-link.8.in | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index d5673639d9dd..97042beaf4cc 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -65,7 +65,8 @@ ip-link \- network device configuration
 .BR nlmon " |"
 .BR ipvlan " |"
 .BR lowpan " |"
-.BR geneve " ]"
+.BR geneve " |"
+.BR vrf " ]"
 
 .ti -8
 .BR "ip link delete " {
@@ -263,6 +264,9 @@ specifies the type of the new device.
 .sp
 .BR macsec
 - Interface for IEEE 802.1AE MAC Security (MACsec)
+.sp
+.BR vrf
+- Interface for L3 VRF domains
 .in -8
 
 .TP
@@ -966,6 +970,20 @@ For a link of type
 
 .in -8
 
+.TP
+VRF Type Support
+For a link of type
+.I VRF
+the following additional arguments are supported:
+
+.BI "ip link add " DEVICE " type vrf table " TABLE
+
+.in +8
+.sp
+.BR table " table id associated with VRF device"
+
+.in -8
+
 .SS ip link delete - delete virtual link
 
 .TP
-- 
2.1.4



Re: [PATCH -next 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

2016-06-21 Thread Alexei Starovoitov
On Tue, Jun 21, 2016 at 05:23:20PM -0700, Martin KaFai Lau wrote:
> Add a BPF_MAP_TYPE_CGROUP_ARRAY and its bpf_map_ops's implementations.
> To update an element, the caller is expected to obtain a cgroup2 backed
> fd by open(cgroup2_dir) and then update the array with that fd.
> 
> Signed-off-by: Martin KaFai Lau 
> Cc: Alexei Starovoitov 
> Cc: Daniel Borkmann 
> Cc: Tejun Heo 

Acked-by: Alexei Starovoitov 


Re: [PATCH net-next 01/19] net: hns: bug fix of ge reset sequence

2016-06-21 Thread Yisen Zhuang


在 2016/6/21 18:35, Andy Shevchenko 写道:
> On Tue, 2016-06-21 at 11:56 +0800, Yisen Zhuang wrote:
>> From: Qianqian Xie 
>>
>> The bit fileds of PPE reset register are different between HNS v1 and
>> HNS v2, but the current procedure just only match HNS v1. Here is a
>> patch to fix it.
>>
>> Signed-off-by: Kejian Yan 
>> Signed-off-by: Qianqian Xie 
>> Signed-off-by: Yisen Zhuang 
>> ---
>>  drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
>> b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
>> index 96cb628..09e60d6 100644
>> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
>> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
>> @@ -271,7 +271,11 @@ static void hns_dsaf_ge_srst_by_port(struct
>> dsaf_device *dsaf_dev, u32 port,
>>  }
>>  } else {
>>  reg_val_1 = 0x15540 << dsaf_dev->reset_offset;
>> -reg_val_2 = 0x100 << dsaf_dev->reset_offset;
>> +
>> +if (AE_IS_VER1(dsaf_dev->dsaf_ver))
>> +reg_val_2 = 0x100 << dsaf_dev->reset_offset;
>> +else
>> +reg_val_2 = 0x40 << dsaf_dev->reset_offset;
> 
> reg_val_1 = 0x15540;
> reg_val_2 = AE_IS_VER1(dsaf_dev->dsaf_ver) ? 0x100 : 0x40;
> 
> reg_val_1 <<= dsaf_dev->reset_offset;
> reg_val_2 <<= dsaf_dev-

I will fix it with a new patch.

Thanks,

Yisen

>> reset_offset;
> 
> 
>>  
>>  if (!dereset) {
>>  dsaf_write_sub(dsaf_dev,
>> DSAF_SUB_SC_GE_RESET_REQ1_REG,
> 



Re: [PATCH -next 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on next-20160621]

url:
https://github.com/0day-ci/linux/commits/Martin-KaFai-Lau/cgroup-bpf-cgroup2-membership-test-on-skb/20160622-082800
config: i386-randconfig-s1-201625 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   net/core/filter.c: In function 'bpf_skb_in_cgroup':
>> net/core/filter.c:2049:30: error: implicit declaration of function 
>> 'sock_cgroup_ptr' [-Werror=implicit-function-declaration]
 return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), cgrp);
 ^~~
>> net/core/filter.c:2049:30: warning: passing argument 1 of 
>> 'cgroup_is_descendant' makes pointer from integer without a cast 
>> [-Wint-conversion]
   In file included from include/net/netprio_cgroup.h:17:0,
from include/linux/netdevice.h:48,
from net/core/filter.c:31:
   include/linux/cgroup.h:492:20: note: expected 'struct cgroup *' but argument 
is of type 'int'
static inline bool cgroup_is_descendant(struct cgroup *cgrp,
   ^~~~
   cc1: some warnings being treated as errors

vim +/sock_cgroup_ptr +2049 net/core/filter.c

  2043  return -E2BIG;
  2044  
  2045  cgrp = READ_ONCE(array->ptrs[i]);
  2046  if (unlikely(!cgrp))
  2047  return -ENOENT;
  2048  
> 2049  return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), 
> cgrp);
  2050  }
  2051  
  2052  static const struct bpf_func_proto bpf_skb_in_cgroup_proto = {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH -next 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

2016-06-21 Thread kbuild test robot
Hi,

[auto build test ERROR on next-20160621]

url:
https://github.com/0day-ci/linux/commits/Martin-KaFai-Lau/cgroup-bpf-cgroup2-membership-test-on-skb/20160622-082800
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All error/warnings (new ones prefixed by >>):

   kernel/bpf/arraymap.c: In function 'cgroup_fd_array_get_ptr':
>> kernel/bpf/arraymap.c:547:2: error: implicit declaration of function 
>> 'cgroup_get_from_fd' [-Werror=implicit-function-declaration]
 return cgroup_get_from_fd(fd);
 ^
>> kernel/bpf/arraymap.c:547:2: warning: return makes pointer from integer 
>> without a cast
   kernel/bpf/arraymap.c: In function 'cgroup_fd_array_put_ptr':
>> kernel/bpf/arraymap.c:553:2: error: implicit declaration of function 
>> 'cgroup_put' [-Werror=implicit-function-declaration]
 cgroup_put(ptr);
 ^
   cc1: some warnings being treated as errors

vim +/cgroup_get_from_fd +547 kernel/bpf/arraymap.c

   541  late_initcall(register_perf_event_array_map);
   542  
   543  static void *cgroup_fd_array_get_ptr(struct bpf_map *map,
   544   struct file *map_file /* not used 
*/,
   545   int fd)
   546  {
 > 547  return cgroup_get_from_fd(fd);
   548  }
   549  
   550  static void cgroup_fd_array_put_ptr(void *ptr)
   551  {
   552  /* cgroup_put free cgrp after a rcu grace period */
 > 553  cgroup_put(ptr);
   554  }
   555  
   556  static void cgroup_fd_array_free(struct bpf_map *map)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH -next 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

2016-06-21 Thread Alexei Starovoitov
On Tue, Jun 21, 2016 at 05:23:21PM -0700, Martin KaFai Lau wrote:
> Adds a bpf helper, bpf_skb_in_cgroup, to decide if a skb->sk
> belongs to a descendant of a cgroup2.  It is similar to the
> feature added in netfilter:
> commit c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")
> 
> The user is expected to populate a BPF_MAP_TYPE_CGROUP_ARRAY
> which will be used by the bpf_skb_in_cgroup.
> 
> Modifications to the bpf verifier is to ensure BPF_MAP_TYPE_CGROUP_ARRAY
> and bpf_skb_in_cgroup() are always used together.
> 
> Signed-off-by: Martin KaFai Lau 
> Cc: Alexei Starovoitov 
> Cc: Daniel Borkmann 
> Cc: Tejun Heo 
> ---
>  include/uapi/linux/bpf.h |  1 +
>  kernel/bpf/verifier.c|  8 
>  net/core/filter.c| 36 
>  3 files changed, 45 insertions(+)
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index ef4e386..a91714bd 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -314,6 +314,7 @@ enum bpf_func_id {
>*/
>   BPF_FUNC_skb_get_tunnel_opt,
>   BPF_FUNC_skb_set_tunnel_opt,
> + BPF_FUNC_skb_in_cgroup,
...
> +static u64 bpf_skb_in_cgroup(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +{
...
> + if (unlikely(!cgrp))
> + return -ENOENT;
> +
> + return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), cgrp);

if you'd need to respin the patch for other reasons please add kdoc
to bpf.h for this new helper similar to other helpers.
To say that 0 or 1 return values is indication of cg2 descendant relation
and < 0 in case of error.

Acked-by: Alexei Starovoitov 



[PATCH v2] ibmvnic: fix to use list_for_each_safe() when delete items

2016-06-21 Thread Wei Yongjun

Since we will remove items off the list using list_del() we need
to use a safe version of the list_for_each() macro aptly named
list_for_each_safe().

Signed-off-by: Wei Yongjun 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index 864cb21..ecdb685 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2121,7 +2121,7 @@ static void handle_error_info_rsp(union ibmvnic_crq *crq,
  struct ibmvnic_adapter *adapter)
 {
struct device *dev = >vdev->dev;
-   struct ibmvnic_error_buff *error_buff;
+   struct ibmvnic_error_buff *error_buff, *tmp;
unsigned long flags;
bool found = false;
int i;
@@ -2133,7 +2133,7 @@ static void handle_error_info_rsp(union ibmvnic_crq *crq,
}
 
 	spin_lock_irqsave(>error_list_lock, flags);

-   list_for_each_entry(error_buff, >errors, list)
+   list_for_each_entry_safe(error_buff, tmp, >errors, list)
if (error_buff->error_id == crq->request_error_rsp.error_id) {
found = true;
list_del(_buff->list);
@@ -3141,14 +3141,14 @@ static void handle_request_ras_comp_num_rsp(union 
ibmvnic_crq *crq,
 
 static void ibmvnic_free_inflight(struct ibmvnic_adapter *adapter)

 {
-   struct ibmvnic_inflight_cmd *inflight_cmd;
+   struct ibmvnic_inflight_cmd *inflight_cmd, *tmp1;
struct device *dev = >vdev->dev;
-   struct ibmvnic_error_buff *error_buff;
+   struct ibmvnic_error_buff *error_buff, *tmp2;
unsigned long flags;
unsigned long flags2;
 
 	spin_lock_irqsave(>inflight_lock, flags);

-   list_for_each_entry(inflight_cmd, >inflight, list) {
+   list_for_each_entry_safe(inflight_cmd, tmp1, >inflight, list) {
switch (inflight_cmd->crq.generic.cmd) {
case LOGIN:
dma_unmap_single(dev, adapter->login_buf_token,
@@ -3165,8 +3165,8 @@ static void ibmvnic_free_inflight(struct ibmvnic_adapter 
*adapter)
break;
case REQUEST_ERROR_INFO:
spin_lock_irqsave(>error_list_lock, flags2);
-   list_for_each_entry(error_buff, >errors,
-   list) {
+   list_for_each_entry_safe(error_buff, tmp2,
+>errors, list) {
dma_unmap_single(dev, error_buff->dma,
 error_buff->len,
 DMA_FROM_DEVICE);





[PATCH -next 4/4] cgroup: bpf: Add an example to do cgroup checking in BPF

2016-06-21 Thread Martin KaFai Lau
test_cgrp2_array_pin.c:
A userland program that creates a bpf_map (BPF_MAP_TYPE_GROUP_ARRAY),
pouplates/updates it with a cgroup2's backed fd and pins it to a
bpf-fs's file.  The pinned file can be loaded by tc and then used
by the bpf prog later.  This program can also update an existing pinned
array and it could be useful for debugging/testing purpose.

test_cgrp2_tc_kern.c:
A bpf prog which should be loaded by tc.  It is to demonstrate
the usage of bpf_skb_in_cgroup.

test_cgrp2_tc.sh:
A script that glues the test_cgrp2_array_pin.c and
test_cgrp2_tc_kern.c together.  The idea is like:
1. Use test_cgrp2_array_pin.c to populate a BPF_MAP_TYPE_CGROUP_ARRAY
   with a cgroup fd
2. Load the test_cgrp2_tc_kern.o by tc
3. Do a 'ping -6 ff02::1%ve' to ensure the packet has been
   dropped because of a match on the cgroup

Most of the lines in test_cgrp2_tc.sh is the boilerplate
to setup the cgroup/bpf-fs/net-devices/netns...etc.  It is
not bulletproof on errors but should work well enough and
give enough debug info if things did not go well.

Signed-off-by: Martin KaFai Lau 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Tejun Heo 
---
 samples/bpf/Makefile   |   3 +
 samples/bpf/bpf_helpers.h  |   2 +
 samples/bpf/test_cgrp2_array_pin.c | 109 +
 samples/bpf/test_cgrp2_tc.sh   | 189 +
 samples/bpf/test_cgrp2_tc_kern.c   |  71 ++
 5 files changed, 374 insertions(+)
 create mode 100644 samples/bpf/test_cgrp2_array_pin.c
 create mode 100755 samples/bpf/test_cgrp2_tc.sh
 create mode 100644 samples/bpf/test_cgrp2_tc_kern.c

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 0bf2478..a98b780 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -20,6 +20,7 @@ hostprogs-y += offwaketime
 hostprogs-y += spintest
 hostprogs-y += map_perf_test
 hostprogs-y += test_overhead
+hostprogs-y += test_cgrp2_array_pin
 
 test_verifier-objs := test_verifier.o libbpf.o
 test_maps-objs := test_maps.o libbpf.o
@@ -40,6 +41,7 @@ offwaketime-objs := bpf_load.o libbpf.o offwaketime_user.o
 spintest-objs := bpf_load.o libbpf.o spintest_user.o
 map_perf_test-objs := bpf_load.o libbpf.o map_perf_test_user.o
 test_overhead-objs := bpf_load.o libbpf.o test_overhead_user.o
+test_cgrp2_array_pin-objs := libbpf.o test_cgrp2_array_pin.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
@@ -61,6 +63,7 @@ always += map_perf_test_kern.o
 always += test_overhead_tp_kern.o
 always += test_overhead_kprobe_kern.o
 always += parse_varlen.o parse_simple.o parse_ldabs.o
+always += test_cgrp2_tc_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 7904a2a..84e3fd9 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -70,6 +70,8 @@ static int (*bpf_l3_csum_replace)(void *ctx, int off, int 
from, int to, int flag
(void *) BPF_FUNC_l3_csum_replace;
 static int (*bpf_l4_csum_replace)(void *ctx, int off, int from, int to, int 
flags) =
(void *) BPF_FUNC_l4_csum_replace;
+static int (*bpf_skb_in_cgroup)(void *ctx, void *map, int index) =
+   (void *) BPF_FUNC_skb_in_cgroup;
 
 #if defined(__x86_64__)
 
diff --git a/samples/bpf/test_cgrp2_array_pin.c 
b/samples/bpf/test_cgrp2_array_pin.c
new file mode 100644
index 000..70e86f7
--- /dev/null
+++ b/samples/bpf/test_cgrp2_array_pin.c
@@ -0,0 +1,109 @@
+/* Copyright (c) 2016 Facebook
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "libbpf.h"
+
+static void usage(void)
+{
+   printf("Usage: test_cgrp2_array_pin [...]\n");
+   printf("   -FFile to pin an BPF cgroup array\n");
+   printf("   -UUpdate an already pinned BPF cgroup 
array\n");
+   printf("   -v   Full path of the cgroup2\n");
+   printf("   -h  Display this help\n");
+}
+
+int main(int argc, char **argv)
+{
+   const char *pinned_file = NULL, *cg2 = NULL;
+   int create_array = 1;
+   int array_key = 0;
+   int array_fd = -1;
+   int cg2_fd = -1;
+   int ret = -1;
+   int opt;
+
+   while ((opt = getopt(argc, argv, "F:U:v:")) != -1) {
+   switch (opt) {
+   /* General args */
+   case 'F':
+   pinned_file = optarg;
+   break;
+   case 'U':
+   pinned_file = optarg;
+   create_array = 0;
+   break;
+   case 'v':
+   cg2 = optarg;
+   break;
+   default:
+   usage();
+

[PATCH -next 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

2016-06-21 Thread Martin KaFai Lau
Adds a bpf helper, bpf_skb_in_cgroup, to decide if a skb->sk
belongs to a descendant of a cgroup2.  It is similar to the
feature added in netfilter:
commit c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")

The user is expected to populate a BPF_MAP_TYPE_CGROUP_ARRAY
which will be used by the bpf_skb_in_cgroup.

Modifications to the bpf verifier is to ensure BPF_MAP_TYPE_CGROUP_ARRAY
and bpf_skb_in_cgroup() are always used together.

Signed-off-by: Martin KaFai Lau 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Tejun Heo 
---
 include/uapi/linux/bpf.h |  1 +
 kernel/bpf/verifier.c|  8 
 net/core/filter.c| 36 
 3 files changed, 45 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index ef4e386..a91714bd 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -314,6 +314,7 @@ enum bpf_func_id {
 */
BPF_FUNC_skb_get_tunnel_opt,
BPF_FUNC_skb_set_tunnel_opt,
+   BPF_FUNC_skb_in_cgroup,
__BPF_FUNC_MAX_ID,
 };
 
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 668e079..68753e0 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1062,6 +1062,10 @@ static int check_map_func_compatibility(struct bpf_map 
*map, int func_id)
if (func_id != BPF_FUNC_get_stackid)
goto error;
break;
+   case BPF_MAP_TYPE_CGROUP_ARRAY:
+   if (func_id != BPF_FUNC_skb_in_cgroup)
+   goto error;
+   break;
default:
break;
}
@@ -1081,6 +1085,10 @@ static int check_map_func_compatibility(struct bpf_map 
*map, int func_id)
if (map->map_type != BPF_MAP_TYPE_STACK_TRACE)
goto error;
break;
+   case BPF_FUNC_skb_in_cgroup:
+   if (map->map_type != BPF_MAP_TYPE_CGROUP_ARRAY)
+   goto error;
+   break;
default:
break;
}
diff --git a/net/core/filter.c b/net/core/filter.c
index df6860c..410da89 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2024,6 +2024,40 @@ bpf_get_skb_set_tunnel_proto(enum bpf_func_id which)
}
 }
 
+static u64 bpf_skb_in_cgroup(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+   struct sk_buff *skb = (struct sk_buff *)(long)r1;
+   struct bpf_map *map = (struct bpf_map *)(long)r2;
+   struct bpf_array *array = container_of(map, struct bpf_array, map);
+   u32 i = (u32)r3;
+   struct cgroup *cgrp;
+   struct sock *sk;
+
+   WARN_ON_ONCE(!rcu_read_lock_held());
+
+   sk = skb->sk;
+   if (!sk || !sk_fullsock(sk))
+   return -ENOENT;
+
+   if (unlikely(i >= array->map.max_entries))
+   return -E2BIG;
+
+   cgrp = READ_ONCE(array->ptrs[i]);
+   if (unlikely(!cgrp))
+   return -ENOENT;
+
+   return cgroup_is_descendant(sock_cgroup_ptr(>sk_cgrp_data), cgrp);
+}
+
+static const struct bpf_func_proto bpf_skb_in_cgroup_proto = {
+   .func   = bpf_skb_in_cgroup,
+   .gpl_only   = false,
+   .ret_type   = RET_INTEGER,
+   .arg1_type  = ARG_PTR_TO_CTX,
+   .arg2_type  = ARG_CONST_MAP_PTR,
+   .arg3_type  = ARG_ANYTHING,
+};
+
 static const struct bpf_func_proto *
 sk_filter_func_proto(enum bpf_func_id func_id)
 {
@@ -2086,6 +2120,8 @@ tc_cls_act_func_proto(enum bpf_func_id func_id)
return _get_route_realm_proto;
case BPF_FUNC_perf_event_output:
return bpf_get_event_output_proto();
+   case BPF_FUNC_skb_in_cgroup:
+   return _skb_in_cgroup_proto;
default:
return sk_filter_func_proto(func_id);
}
-- 
2.5.1



[PATCH -next 1/4] cgroup: Add cgroup_get_from_fd

2016-06-21 Thread Martin KaFai Lau
Add a helper function to get a cgroup2 from a fd.  It will be
stored in a bpf array (BPF_MAP_TYPE_CGROUP_ARRAY) which will
be introduced in the later patch.

Signed-off-by: Martin KaFai Lau 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Tejun Heo 
---
 include/linux/cgroup.h |  1 +
 kernel/cgroup.c| 26 ++
 2 files changed, 27 insertions(+)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index a20320c..984f73b 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -87,6 +87,7 @@ struct cgroup_subsys_state *css_tryget_online_from_dir(struct 
dentry *dentry,
   struct cgroup_subsys 
*ss);
 
 struct cgroup *cgroup_get_from_path(const char *path);
+struct cgroup *cgroup_get_from_fd(int fd);
 
 int cgroup_attach_task_all(struct task_struct *from, struct task_struct *);
 int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from);
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 86cb5c6..616c751 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -6205,6 +6206,31 @@ struct cgroup *cgroup_get_from_path(const char *path)
 }
 EXPORT_SYMBOL_GPL(cgroup_get_from_path);
 
+struct cgroup *cgroup_get_from_fd(int fd)
+{
+   struct cgroup_subsys_state *css;
+   struct cgroup *cgrp;
+   struct file *f;
+
+   f = fget_raw(fd);
+   if (!f)
+   return NULL;
+
+   css = css_tryget_online_from_dir(f->f_path.dentry, NULL);
+   fput(f);
+   if (IS_ERR(css))
+   return ERR_CAST(css);
+
+   cgrp = css->cgroup;
+   if (!cgroup_on_dfl(cgrp)) {
+   cgroup_put(cgrp);
+   return ERR_PTR(-EINVAL);
+   }
+
+   return cgrp;
+}
+EXPORT_SYMBOL_GPL(cgroup_get_from_fd);
+
 /*
  * sock->sk_cgrp_data handling.  For more info, see sock_cgroup_data
  * definition in cgroup-defs.h.
-- 
2.5.1



[PATCH -next 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

2016-06-21 Thread Martin KaFai Lau
Add a BPF_MAP_TYPE_CGROUP_ARRAY and its bpf_map_ops's implementations.
To update an element, the caller is expected to obtain a cgroup2 backed
fd by open(cgroup2_dir) and then update the array with that fd.

Signed-off-by: Martin KaFai Lau 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Tejun Heo 
---
 include/uapi/linux/bpf.h |  1 +
 kernel/bpf/arraymap.c| 41 +
 kernel/bpf/syscall.c |  3 ++-
 3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 406459b..ef4e386 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -84,6 +84,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_PERCPU_HASH,
BPF_MAP_TYPE_PERCPU_ARRAY,
BPF_MAP_TYPE_STACK_TRACE,
+   BPF_MAP_TYPE_CGROUP_ARRAY,
 };
 
 enum bpf_prog_type {
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 5af3073..5e279ec 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -539,3 +539,44 @@ static int __init register_perf_event_array_map(void)
return 0;
 }
 late_initcall(register_perf_event_array_map);
+
+static void *cgroup_fd_array_get_ptr(struct bpf_map *map,
+struct file *map_file /* not used */,
+int fd)
+{
+   return cgroup_get_from_fd(fd);
+}
+
+static void cgroup_fd_array_put_ptr(void *ptr)
+{
+   /* cgroup_put free cgrp after a rcu grace period */
+   cgroup_put(ptr);
+}
+
+static void cgroup_fd_array_free(struct bpf_map *map)
+{
+   bpf_fd_array_map_clear(map);
+   fd_array_map_free(map);
+}
+
+static const struct bpf_map_ops cgroup_array_ops = {
+   .map_alloc = fd_array_map_alloc,
+   .map_free = cgroup_fd_array_free,
+   .map_get_next_key = array_map_get_next_key,
+   .map_lookup_elem = fd_array_map_lookup_elem,
+   .map_delete_elem = fd_array_map_delete_elem,
+   .map_fd_get_ptr = cgroup_fd_array_get_ptr,
+   .map_fd_put_ptr = cgroup_fd_array_put_ptr,
+};
+
+static struct bpf_map_type_list cgroup_array_type __read_mostly = {
+   .ops = _array_ops,
+   .type = BPF_MAP_TYPE_CGROUP_ARRAY,
+};
+
+static int __init register_cgroup_array_map(void)
+{
+   bpf_register_map_type(_array_type);
+   return 0;
+}
+late_initcall(register_cgroup_array_map);
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index c23a4e93..cac13f1 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -393,7 +393,8 @@ static int map_update_elem(union bpf_attr *attr)
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
err = bpf_percpu_array_update(map, key, value, attr->flags);
} else if (map->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY ||
-  map->map_type == BPF_MAP_TYPE_PROG_ARRAY) {
+  map->map_type == BPF_MAP_TYPE_PROG_ARRAY ||
+  map->map_type == BPF_MAP_TYPE_CGROUP_ARRAY) {
rcu_read_lock();
err = bpf_fd_array_map_update_elem(map, f.file, key, value,
   attr->flags);
-- 
2.5.1



[PATCH -next 0/4] cgroup: bpf: cgroup2 membership test on skb

2016-06-21 Thread Martin KaFai Lau
This series is to implement a bpf-way to
check the cgroup2 membership of a skb (sk_buff).

It is similar to the feature added in netfilter:
c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match")

The current target is the tc-like usage.



Re: [ovs-dev] [RFC PATCH net v2 2/2] openvswitch: Only set mark and labels with a commit flag.

2016-06-21 Thread Joe Stringer
On 21 June 2016 at 14:59, Jarno Rajahalme  wrote:
> Only set conntrack mark or labels when the commit flag is specified.
> This makes sure we can not set them before the connection has been
> persisted, as in that case the mark and labels would be lost in an
> event of an userspace upcall.
>
> OVS userspace already requires the commit flag to accept setting
> ct_mark and/or ct_labels.  Validate for this in the kernel API.
>
> Signed-off-by: Jarno Rajahalme 

As this is walling off an inconsistent corner of the ct action, and
OVS userspace already enforces this constraint, this looks OK to me.


Re: 802.3ad bonding aggregator reselection

2016-06-21 Thread Jay Vosburgh

Veli-Matti Lintu  wrote:
[...]
>>>The ports are configured in switch settings (HP Procurve 2530-48G) in
>>>same trunk group (TrkX) and trunk group type is set as LACP.
>>>/proc/net/bonding/bond0 also shows that the three ports belong to same
>>>aggregator and bandwidth tests also support this. In my understanding
>>>Procurve's trunk group is pretty much the same as etherchannel in
>>>Cisco's terminology. The bonded link comes always up properly, but
>>>handling of links going down is the problem. Are there known
>>>differences between different vendors there?
>>
>> I did the original LACP reselection testing on a Cisco switch,
>> but I have an HP 2530 now; I'll test it later today or tomorrow and see
>> if it behaves properly, and whether your proposed patch is needed.
>
>Thanks for taking a look at this. Here are some more details about the
>setup as Zhu Yanjun also requested.

Summary (because anything involving a standard tends to get long
winded):

This is not a switch problem.  Bonding appears to be following
the standard in this case.  I've identified when this behavior changed,
and I think we should violate the standard in this case for ad_select
set to "bandwidth" or "count," neither of which is the default value.

Long winded version:

I've reproduced the issue locally, and it does not appear to be
anything particular to the switch.  It appears to be due to changes from

commit 7bb11dc9f59ddcb33ee317da77b235235aaa582a
Author: Mahesh Bandewar 
Date:   Sat Oct 31 12:45:06 2015 -0700

bonding: unify all places where actor-oper key needs to be updated.

Specifically this block:

 void bond_3ad_handle_link_change(struct slave *slave, char link)
[...]
-   /* there is no need to reselect a new aggregator, just signal the
-* state machines to reinitialize
-*/
-   port->sm_vars |= AD_PORT_BEGIN;

Previously, setting BEGIN would cause the port in question to be
reinitialized, which in turn would trigger reselection.

I'm not sure that adding this section back is the correct fix
from the point of view of the standard, however, as 802.1AX 5.2.3.1.2
defines BEGIN as:

A Boolean variable that is set to TRUE when the System is
initialized or reinitialized, and is set to FALSE when
(re-)initialization has completed.

and in this case we're not reinitializing the System (i.e., the
bond).

Further, 802.1AX 5.4.12 says:

If the port becomes inoperable and a BEGIN event has not
occurred, the state machine enters the PORT_DISABLED
state. Partner_Oper_Port_State.Synchronization is set to
FALSE. This state allows the current Selection state to remain
undisturbed, so that, in the event that the port is still
connected to the same Partner and Partner port when it becomes
operable again, there will be no disturbance caused to higher
layers by unneccessary re-configuration.

At the moment, bonding is doing what 5.4.12 specifies, by
placing the port into PORT_DISABLED state.  bond_3ad_handle_link_change
clears port->is_enabled, which causes ad_rx_machine to clear
AD_PORT_MATCHED but leave AD_PORT_SELECTED set.  This in turn cause the
selection logic to skip this port, resulting in the observed behavior
(that the port is link down, but stays in the aggregator).

Bonding will still remove the slave from the bond->slave_arr, so
it won't actually try to send on this slave.  I'll further note that
802.1AX 5.4.7 defines port_enabled as:

A variable indicating that the physical layer has indicated that
the link has been established and the port is operable.
Value: Boolean
TRUE if the physical layer has indicated that the port is operable.
FALSE otherwise.

So, it appears that bonding is in conformance with the standard
in this case.

I don't see an issue with the above behavior when ad_select is
set to the default value of "stable"; bonding does reselect a new
aggregator when all links fail, and it appears to follow the standard.

I think a reasonable compromise here is to utilize a modified
version of your patch that clears SELECTED (to trigger reselection) when
a link goes down, but only if ad_select is not "stable", for example:

diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
index b9304a295f86..1ee5a3a5e658 100644
--- a/drivers/net/bonding/bond_3ad.c
+++ b/drivers/net/bonding/bond_3ad.c
@@ -2458,6 +2458,8 @@ void bond_3ad_handle_link_change(struct slave *slave, 
char link)
/* link has failed */
port->is_enabled = false;
ad_update_actor_keys(port, true);
+   if (__get_agg_selection_mode(port) != BOND_AD_STABLE)
+   port->port->sm_vars &= ~AD_PORT_SELECTED;
}

RE: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

2016-06-21 Thread Machani, Yaniv
Yes,
TI driver have added support in our latest release (TI git).
http://software-dl.ti.com/ecs/WiLink8/R8_7/exports/release_notes_R8_7.html

Patches will be shared with mainline in the near future.

Thanks,
Yaniv Machani

-Original Message-
From: Bob Copeland [mailto:m...@bobcopeland.com] 
Sent: Tuesday, June 21, 2016 15:19
To: Altshul, Maxim
Cc: johan...@sipsolutions.net; kv...@codeaurora.org; el...@wizery.com; Machani, 
Yaniv; Mishol, Guy; a...@wizery.com; linux-wirel...@vger.kernel.org; 
netdev@vger.kernel.org; da...@davemloft.net
Subject: Re: [PATCH 0/3] *** Mesh Path Selection Metric Calculation ***

On Mon, Jun 20, 2016 at 04:00:19PM +0300, Maxim Altshul wrote:
> 2. Implements the opcode and the mechanism that reports the rates in 
> TI driver.

Does this mean TI driver will support mesh at some point?

--
Bob Copeland %% http://bobcopeland.com/


Re: [PATCH v10 06/22] IB/hns: Add initial cmd operation

2016-06-21 Thread Wei Hu (Xavier)



On 2016/6/21 19:28, Leon Romanovsky wrote:

On Tue, Jun 21, 2016 at 06:50:51PM +0800, Wei Hu (Xavier) wrote:


On 2016/6/20 21:33, Leon Romanovsky wrote:

On Thu, Jun 16, 2016 at 10:35:14PM +0800, Lijun Ou wrote:

This patch added the operation for cmd, and added some functions
for initializing eq table and selecting cmd mode.

Signed-off-by: Wei Hu 
Signed-off-by: Nenglong Zhao 
Signed-off-by: Lijun Ou 
---
PATCH v9/v8/v7/v6:
- No change over the PATCH v5

PATCH v5:
- The initial patch which was redesigned based on the second patch
   in PATCH v4
---

<...>


+#define CMD_MAX_NUM32
+
+int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
+{
+   struct device *dev = _dev->pdev->dev;
+
+   mutex_init(_dev->cmd.hcr_mutex);
+   sema_init(_dev->cmd.poll_sem, 1);
+   hr_dev->cmd.use_events = 0;
+   hr_dev->cmd.toggle = 1;
+   hr_dev->cmd.max_cmds = CMD_MAX_NUM;

<...>


+   for (hr_cmd->token_mask = 1; hr_cmd->token_mask < hr_cmd->max_cmds;
+hr_cmd->token_mask <<= 1)
+   ;
+   --hr_cmd->token_mask;

It doesn't look that you dynamically change max_cmds supported.
Why do you need to calculate token_mask dynamically?

Hi, Leon

 1. The four lines above are in the function named
hns_roce_cmd_use_events.
  and now this function is only called once in hns_roce_probe.
 2. In hns_roce_cmd_use_events,
 we use these 4 lines to achieve the value of hr_cmd->token_mask
according to hr_cmd->max_cmds dynamically,
 then we only define one marco for hr_cmd->max_cmds as below:

#define CMD_MAX_NUM 32

And it looks more flexible.

It is called over engineering.
I would recommend to you to remove it.

We don't need over complicated code which is executed
once with need to maintain with zero benefit.

The other places need such simplification too.

Hi, Leon

We will modify this place as below:
In hns_roce_hw_v1.c(for hip06 soc) file:

void hns_roce_v1_profile(struct hns_roce_dev *hr_dev)
{

caps->max_cmds = 32;

}

In hns_roce_cmd.c file:

  int hns_roce_cmd_init(struct hns_roce_dev *hr_dev)
  {
 
 hr_dev->cmd.max_cmds = hr_dev->caps->max_cmds;

  }

   Can you give more suggestions?


Regards
Wei Hu

Regards
Wei Hu








[PATCH net] MAINTAINERS: Update Mellanox's mlx4 Eth NIC driver entry

2016-06-21 Thread Or Gerlitz
Tariq Toukan is replacing Eugenia (Jenny) Emantayev as the mlx4
Ethernet driver maintainer, thanks to Jenny and good luck to him.

Signed-off-by: Or Gerlitz 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2ebe195..8cffceb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7406,7 +7406,7 @@ F:drivers/scsi/megaraid.*
 F: drivers/scsi/megaraid/
 
 MELLANOX ETHERNET DRIVER (mlx4_en)
-M: Eugenia Emantayev 
+M: Tariq Toukan 
 L: netdev@vger.kernel.org
 S: Supported
 W: http://www.mellanox.com
-- 
2.3.7



Re: [PATCH 1/2] ath10k: remove unused

2016-06-21 Thread Sergei Shtylyov

Hello.

On 6/21/2016 2:45 PM, Chaehyun Lim wrote:


 is not used anymore, so just remove it.


   s/it/#include/?


Signed-off-by: Chaehyun Lim 

[...]


diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index cc82718..0c55cd9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 struct ath10k;


MBR, Sergei



[PATCH v2] net: stmmac: dwmac-rk: add rk3228-specific data

2016-06-21 Thread Xing Zheng
Add constants and callback functions for the dwmac on rk3228/rk3229 socs.
As can be seen, the base structure is the same, only registers and the
bits in them moved slightly.

Signed-off-by: Xing Zheng 
---

Changes in v2:
- the "rk322x" is not clear to SoC decription, rename it to "rk3228"

 .../devicetree/bindings/net/rockchip-dwmac.txt |3 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c |  117 
 2 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt 
b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
index 93eac7c..cccd945 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
@@ -3,7 +3,8 @@ Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
 The device node has following properties.
 
 Required properties:
- - compatible: Can be one of "rockchip,rk3288-gmac", "rockchip,rk3368-gmac"
+ - compatible: Can be one of "rockchip,rk3228-gmac", "rockchip,rk3288-gmac",
+ "rockchip,rk3368-gmac"
  - reg: addresses and length of the register sets for the device.
  - interrupts: Should contain the GMAC interrupts.
  - interrupt-names: Should contain the interrupt names "macirq".
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 0cd3ecf..25eb797 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -72,6 +72,122 @@ struct rk_priv_data {
 #define GRF_BIT(nr)(BIT(nr) | BIT(nr+16))
 #define GRF_CLR_BIT(nr)(BIT(nr+16))
 
+#define RK3228_GRF_MAC_CON00x0900
+#define RK3228_GRF_MAC_CON10x0904
+
+/* RK3228_GRF_MAC_CON0 */
+#define RK3228_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 7)
+#define RK3228_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
+
+/* RK3228_GRF_MAC_CON1 */
+#define RK3228_GMAC_PHY_INTF_SEL_RGMII \
+   (GRF_BIT(4) | GRF_CLR_BIT(5) | GRF_CLR_BIT(6))
+#define RK3228_GMAC_PHY_INTF_SEL_RMII  \
+   (GRF_CLR_BIT(4) | GRF_CLR_BIT(5) | GRF_BIT(6))
+#define RK3228_GMAC_FLOW_CTRL  GRF_BIT(3)
+#define RK3228_GMAC_FLOW_CTRL_CLR  GRF_CLR_BIT(3)
+#define RK3228_GMAC_SPEED_10M  GRF_CLR_BIT(2)
+#define RK3228_GMAC_SPEED_100M GRF_BIT(2)
+#define RK3228_GMAC_RMII_CLK_25M   GRF_BIT(7)
+#define RK3228_GMAC_RMII_CLK_2_5M  GRF_CLR_BIT(7)
+#define RK3228_GMAC_CLK_125M   (GRF_CLR_BIT(8) | GRF_CLR_BIT(9))
+#define RK3228_GMAC_CLK_25M(GRF_BIT(8) | GRF_BIT(9))
+#define RK3228_GMAC_CLK_2_5M   (GRF_CLR_BIT(8) | GRF_BIT(9))
+#define RK3228_GMAC_RMII_MODE  GRF_BIT(10)
+#define RK3228_GMAC_RMII_MODE_CLR  GRF_CLR_BIT(10)
+#define RK3228_GMAC_TXCLK_DLY_ENABLE   GRF_BIT(0)
+#define RK3228_GMAC_TXCLK_DLY_DISABLE  GRF_CLR_BIT(0)
+#define RK3228_GMAC_RXCLK_DLY_ENABLE   GRF_BIT(1)
+#define RK3228_GMAC_RXCLK_DLY_DISABLE  GRF_CLR_BIT(1)
+
+static void rk3228_set_to_rgmii(struct rk_priv_data *bsp_priv,
+   int tx_delay, int rx_delay)
+{
+   struct device *dev = _priv->pdev->dev;
+
+   if (IS_ERR(bsp_priv->grf)) {
+   dev_err(dev, "Missing rockchip,grf property\n");
+   return;
+   }
+
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON1,
+RK3228_GMAC_PHY_INTF_SEL_RGMII |
+RK3228_GMAC_RMII_MODE_CLR |
+RK3228_GMAC_RXCLK_DLY_ENABLE |
+RK3228_GMAC_TXCLK_DLY_ENABLE);
+
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON0,
+RK3228_GMAC_CLK_RX_DL_CFG(rx_delay) |
+RK3228_GMAC_CLK_TX_DL_CFG(tx_delay));
+}
+
+static void rk3228_set_to_rmii(struct rk_priv_data *bsp_priv)
+{
+   struct device *dev = _priv->pdev->dev;
+
+   if (IS_ERR(bsp_priv->grf)) {
+   dev_err(dev, "Missing rockchip,grf property\n");
+   return;
+   }
+
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON1,
+RK3228_GMAC_PHY_INTF_SEL_RMII |
+RK3228_GMAC_RMII_MODE);
+
+   /* set MAC to RMII mode */
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON1, GRF_BIT(11));
+}
+
+static void rk3228_set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
+{
+   struct device *dev = _priv->pdev->dev;
+
+   if (IS_ERR(bsp_priv->grf)) {
+   dev_err(dev, "Missing rockchip,grf property\n");
+   return;
+   }
+
+   if (speed == 10)
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON1,
+RK3228_GMAC_CLK_2_5M);
+   else if (speed == 100)
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON1,
+RK3228_GMAC_CLK_25M);
+   else if (speed == 1000)
+   regmap_write(bsp_priv->grf, RK3228_GRF_MAC_CON1,
+ 

Re: [PATCH net-next 12/18] IB/mlx5: Add kernel offload flow-tag

2016-06-21 Thread Saeed Mahameed
On Tue, Jun 21, 2016 at 5:18 AM, Alexei Starovoitov
 wrote:
> On Sat, Jun 18, 2016 at 01:31:26AM +0300, Saeed Mahameed wrote:
>>
>> We simply want to selectively be able to see RoCE/RDMA ETH standard
>> traffic in tcpdump, for diagnostic purposes.
>> so in order to not overwhelm the kernel TCP/IP stack with this
>> traffic, this patch in particular
>> configures ConnectX4 hardware to tag those packets, so in downstream
>> patches mlx5 netdevice will mark the SKBs of those packets
>> to skip the TCP/IP stack and go only to tcpdump.
>
> such 'feature' doesn't make sense to me.
> 'not overwhelming' kernel, but to 'overwhelm' userspace tcpdump?
> Kernel can drop packets way faster than userspace, so such bypass
> scheme has no prartical usage other than building a first step towards
> complete dpdk-like bypass.
>

Alexei , I don't understand your concern.
We already have a full/complete working dpdk bypass solution in
userspace nothing extra is required from the kernel.

We just want to see this traffic and any other rdma traffic in tcpdump
or other standard sniffing tools.

Anyway we brainstormed this internally today and we don't like the
"skb->protocol = 0x" solution,
we will suggest a plugin for libpcap in user space to extend libpcap
ability to sniff RDMA/raw eth traffic.
This way userspace RDMA traffic will be sniffed also via a userspace
RDMA channel.

I will ask Dave to drop this series.


Re: [PATCH net-next 16/19] net: hns: fix bug that alloc skb fail lead to port unavailable

2016-06-21 Thread Sergei Shtylyov

Hello.

On 6/21/2016 6:56 AM, Yisen Zhuang wrote:


From: Jun He 

When hns_nic_poll_rx_skb alloc skb fail, it will break receive cycle and
read new fbd_num to start new receive cycle. It recomputes cycle num is
fbd_num minus clean_count, actually this cycle num is too big because
it drop out receive cycle. It brings about the port unavailable.

So we will goto out when alloc skb fail to fix this bug.

Signed-off-by: Jun He 
Signed-off-by: Ding Tianhong 
Signed-off-by: Yisen Zhuang 
---
 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c 
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index f49246d..c0ce37b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -768,10 +768,10 @@ recv:
clean_count = 0;
}

-   /* poll one pkg*/
+   /* poll one pkt*/


   How about adding a space before */?

[...]

MBR, Sergei



Fwd: Re: [PATCH net-next 00/15] net/smc: Shared Memory Communications - RDMA

2016-06-21 Thread Ursula Braun

Dave,

the SMC-R patches submitted 2016-06-03 show up in state "Changes 
Requested" on patchwork:

https://patchwork.ozlabs.org/project/netdev/list/?submitter=2266=*=1

You had requested a change of the SMC-R description in the cover letter. 
We came up with the response below. Do you need anything else from us?


Kind regards,
Ursula Braun

 Forwarded Message 
Subject: Re: [PATCH net-next 00/15] net/smc: Shared Memory 
Communications - RDMA

Date: Thu,  9 Jun 2016 17:36:28 +0200
From: Ursula Braun 
To: da...@davemloft.net
CC: netdev@vger.kernel.org, linux-s...@vger.kernel.org, 
schwidef...@de.ibm.com, heiko.carst...@de.ibm.com


On Tue, 2016-06-07 at 15:07 -0700, David Miller wrote:

In case my previous reply wasn't clear enough, I require that you provide
a more accurate description of what the implications of this feature are.

Namely, that important _CORE_ networking features are completely bypassed
and unusable when SMC applies to a connection.

Specifically, all packet shaping, filtering, traffic inspection, and
flow management facilitites in the kernel will not be able to see nor
act upon the data flow of these TCP connections once established.

It is always important, and in my opinion required, to list the
negative aspects of your change and not just the "wow, amazing"
positive aspects.

Thanks.



Correct, the SMC-R data stream bypasses TCP and thus cannot enjoy its
features. This is the price for leveraging the TCP application ecosystem
and reducing CPU load.

When a load balancer allows the TCP handshake to take place between a
worker node and the TCP client, RDMA will be used between these two
nodes. So anything based on TCP connection establishment (including a
firewall) can apply to SMC-R, too. To be clear -- yes, the data flow
later on is not subject to these features anymore.  At least VLAN
isolation from the TCP part can be leveraged for RDMA traffic. From our
experience, discussions, etc., that tradeoff seems acceptable in a
classical data center environment.

Improving our cover letter would result in the following new
introductory motivation part at the beginning and a slightly modified 
list of

planned enhancements at the end:

On Fri, 2016-06-03 at 17:26 +0200, Ursula Braun wrote:


These patches are the initial part of the implementation of the
"Shared Memory Communications-RDMA" (SMC-R) protocol. The protocol is
defined in RFC7609 [1]. It allows transformation of TCP connections
using the "Remote Direct Memory Access over Converged Ethernet" (RoCE)
feature of specific communication hardware for data center environments.

SMC-R inherits TCP qualities such as reliable connections, host-based
firewall packet filtering (on connection establishment) and unmodified
application of communication encryption such as TLS (transport layer
security) or SSL (secure sockets layer). It is transparent to most existing
TCP connection load balancers that are commonly used in the enterprise data
center environment for multi-tier application workloads.

Being designed for the data center network switched fabric environment, it
does not need congestion control and thus reaches line speed right away
without having to go through slow start as with TCP. This can be beneficial
for short living flows including request response patterns requiring
reliability. A full SMC-R implementation also provides seamless high
availability and load-balancing demanded by enterprise installations.

SMC-R does not require an RDMA communication manager (RDMA CM). Its use of
RDMA provides CPU savings transparently for unmodified applications.
For instance, when running 10 parallel connections with uperf, we measured
a decrease of 60% in CPU consumption with SMC-R compared to TCP/IP
(with throughput and latency comparable;
measured on x86_64 with the same RoCE card and port).


These patches are the initial part of the implementation of the
"Shared Memory Communications-RDMA" (SMC-R) protocol as defined in
RFC7609 [1].  While SMC-R does not aim to replace TCP,
it taps a wealth of existing data center TCP socket applications
to become more efficient without the need for rewriting them.
SMC-R uses RDMA over Converged Ethernet (RoCE) to save CPU consumption.
For instance, when running 10 parallel connections with uperf, we measured
a decrease of 60% in CPU consumption with SMC-R compared to TCP/IP
(with throughput and latency comparable;
measured on x86_64 with the same RoCE card and port).

SMC-R does not require an RDMA communication manager (RDMA CM).

SMC-R inherits TCP qualities such as reliable connections, host-based
firewall packet filtering (on connection establishment) and unmodified
application of communication encryption such as TLS (transport layer
security) or SSL (secure sockets layer). Since original TCP is used to
establish SMC-R connections, load balancers and packet inspection based
on TCP/IP connection establishment continue to work for SMC-R.

On the other hand 

Re: [PATCH net-next 00/18] mlx5 RoCE/RDMA packet sniffer

2016-06-21 Thread Saeed Mahameed
On Fri, Jun 17, 2016 at 5:43 PM, Saeed Mahameed  wrote:
> Hi Dave,
>
> This patch set introduces mlx5 RoCE/RDMA packet sniffer, it allows
> mlx5e netdevice to receive RoCE/RDMA or RAW ETH traffic which isn't
> supposed to be passed to the kernel stack, for sniffing and diagnostics
> purposes.  This traffic is still not supposed to go through the whole
> network stack processing and should only go to the non-protocol specific
> handlers (ptype_all). e.g: tcpdump, etc ..

Dave,

I would like to drop this series, we did some evaluation and there is
no straightforward way to tell the kernel to not process traffic that
should only go to tcpdump or (ptype_all).

We are evaluating a semi-pure userspace solution to sniff user space
traffic directly form userspace into libpcap. (verbs/rdma
plugin/extension for libpcap)

Sorry for any inconvenience,

Thanks,
Saeed.


Re: [PATCH] ppc: Fix BPF JIT for ABIv2

2016-06-21 Thread Thadeu Lima de Souza Cascardo
On Tue, Jun 21, 2016 at 09:15:48PM +1000, Michael Ellerman wrote:
> On Tue, 2016-06-21 at 14:28 +0530, Naveen N. Rao wrote:
> > On 2016/06/20 03:56PM, Thadeu Lima de Souza Cascardo wrote:
> > > On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote:
> > > > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote:
> > > > > 
> > > > > Hi, Michael and Naveen.
> > > > > 
> > > > > I noticed independently that there is a problem with BPF JIT and 
> > > > > ABIv2, and
> > > > > worked out the patch below before I noticed Naveen's patchset and the 
> > > > > latest
> > > > > changes in ppc tree for a better way to check for ABI versions.
> > > > > 
> > > > > However, since the issue described below affect mainline and stable 
> > > > > kernels,
> > > > > would you consider applying it before merging your two patchsets, so 
> > > > > that we can
> > > > > more easily backport the fix?
> > > > 
> > > > Hi Cascardo,
> > > > Given that this has been broken on ABIv2 since forever, I didn't bother 
> > > > fixing it. But, I can see why this would be a good thing to have for 
> > > > -stable and existing distros. However, while your patch below may fix 
> > > > the crash you're seeing on ppc64le, it is not sufficient -- you'll need 
> > > > changes in bpf_jit_asm.S as well.
> > > 
> > > Hi, Naveen.
> > > 
> > > Any tips on how to exercise possible issues there? Or what changes you 
> > > think
> > > would be sufficient?
> > 
> > The calling convention is different with ABIv2 and so we'll need changes 
> > in bpf_slow_path_common() and sk_negative_common().
> 
> How big would those changes be? Do we know?
> 
> How come no one reported this was broken previously? This is the first I've
> heard of it being broken.
> 

I just heard of it less than two weeks ago, and only could investigate it last
week, when I realized mainline was also affected.

It looks like the little-endian support for classic JIT were done before the
conversion to ABIv2. And as JIT is disabled by default, no one seems to have
exercised it.

> > However, rather than enabling classic JIT for ppc64le, are we better off 
> > just disabling it?
> > 
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -128,7 +128,7 @@ config PPC
> > select IRQ_FORCED_THREADING
> > select HAVE_RCU_TABLE_FREE if SMP
> > select HAVE_SYSCALL_TRACEPOINTS
> > -   select HAVE_CBPF_JIT
> > +   select HAVE_CBPF_JIT if CPU_BIG_ENDIAN
> > select HAVE_ARCH_JUMP_LABEL
> > select ARCH_HAVE_NMI_SAFE_CMPXCHG
> > select ARCH_HAS_GCOV_PROFILE_ALL
> > 
> > 
> > Michael,
> > Let me know your thoughts on whether you intend to take this patch or 
> > Cascardo's patch for -stable before the eBPF patches. I can redo my 
> > patches accordingly.
> 
> This patch sounds like the best option at the moment for something we can
> backport. Unless the changes to fix it are minimal.
> 
> cheers
> 

With my patch only, I can run a minimal tcpdump tcp port 22 with success. It
correctly filter packets. But as pointed out, slow paths may not be taken.

I don't have strong opinions on what to apply to stable, just that it would be
nice to have something for the crash before applying all the nice changes by
Naveen.

Cascardo.


Re: [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

2016-06-21 Thread Hannes Frederic Sowa
On 21.06.2016 01:22, David Miller wrote:
> From: Tom Herbert 
> Date: Mon, 20 Jun 2016 10:05:01 -0700
> 
>> Generally, this means it needs to at least match by local addresses
>> and port for an unconnected/unbound socket, the source address for
>> an unconnected/bound socket, a the full 4-tuple for a connected
>> socket.
> 
> These lookup keys are all insufficient.
> 
> At the very least the network namespace must be in the lookup key as
> well if you want to match "sockets".  And this is just the tip of the
> iceberg in my opinion.
> 
> The namespace bypassing to me is the biggest flaw in the UDP tunnel
> offloads.  That is creating real dangers right now.
> 
> But anyways, the vastness of the key is why we want to keep "sockets"
> out of network cards, because proper support of "sockets" requires
> access to information the card simply does not and should not have.

We can't look up UDP sockets without having the namespace. We inherit
the namespace from the device the packet showed up on. So I think in
regards to namespaces this looks more or less fine.

Not being able to match on the destination ip or even not considering
the routing infrastructure is kind of dangerous (e.g. we might want to
make the socket not reachable from an interface via ip rules or
blackhole routes, but they wouldn't be considered, too).

Bye,
Hannes



Re: [PATCH iproute2 net-next] bridge: vlan: add support to display per-vlan statistics

2016-06-21 Thread Nikolay Aleksandrov
On 21/06/16 18:01, Stephen Hemminger wrote:
> On Mon, 20 Jun 2016 12:13:19 +0200
> Nikolay Aleksandrov  wrote:
> 
>> This patch adds support for the -statistics (-s) argument to the bridge
>> vlan show command which will display the per-vlan statistics and the bridge
>> device each vlan belongs to. The show command filtering options are both
>> supported, also the man page is updated to explain the new option.
>> This patch uses the new RTM_GETSTATS interface with a filter_mask to dump
>> only the bridge vlans. Later we can add support for using the per-device
>> dump and filter it in the kernel instead.
>>
>> Example:
>> $ bridge -s vlan
>> port vlan id stats
>> br0   1   RX: 33724730 bytes 492075 packets TX: 67409922 bytes 984029 
>> packets
>>   100 RX: 0 bytes 0 packets TX: 0 bytes 0 packets
>>   200 RX: 0 bytes 0 packets TX: 0 bytes 0 packets
>>   300 RX: 0 bytes 0 packets TX: 0 bytes 0 packets
>>   301 RX: 169562135 bytes 790877 packets TX: 169550926 bytes 790824 
>> packets
>> br1   1   RX: 0 bytes 0 packets TX: 0 bytes 0 packets
>>
>> Note that it will print the per-vlan statistics for all vlans in a bridge
>> even if the vlan is only added to ports. Later when we add per-port
>> per-vlan statistics support, we'll be able to print the exact ports each
>> vlan belongs to, not only the bridge.
>>
>> Signed-off-by: Nikolay Aleksandrov 
> 
> Thanks, this is a useful tool, but I think the formatting of output may need 
> to be
> reworked.  The bridge tool works similar to ip command. And in the ip command 
> the
> -s flag causes additional lines, but does not change the output format.

Indeed, I agree that it needs refinement.

> 
> There is also double line spacing in current output, which scrolls off when
> managing in little VM windows. Plush the port name is too narrow a field width

The port name width is the same as vlan show - 1 tab and a space.

> 
> Why not something like:
> 
> $ bridge vlan
> port vlan ids
> virbr1   1 PVID Egress Untagged
> virbr4   1 PVID Egress Untagged
> virbr0   1 PVID Egress Untagged
> 
> $ bridge -s vlan
> virbr1   1 PVID Egress Untagged
>  RX: 33724730 bytes 492075 packets
>  TX: 67409922 bytes 984029 packets
> virbr0   1 PVID Egress Untagged
>  RX: 169562135 bytes 790877 packets 
>  TX: 169550926 bytes 790824 packets
> 
> The -d detail flag would also be useful to implement
> 

Yep, this was one of the formats I tested. The only thing that we currently
cannot implement is the flags printing as they're not exported via the stats
utility and really can't be because some of these entries may not exist on
the bridge device itself and it will get too confusing.
I left a few padding fields and I can export the flags if the entry exists
on the bridge device, then some will have the flags while others
will not, but it still sounds confusing to me. I'd prefer to just leave the
flags to the normal vlan show. What do you think ?

With your example:
 $ bridge -s vlan
 virbr1 1 
  RX: 33724730 bytes 492075 packets
  TX: 67409922 bytes 984029 packets

This way we can later add more fields like broadcast packets or multicast if
we ever start counting them.

I'll later add the "-brief" flag and print them on one line since with
thousands of vlans it comes in handy.

Cheers,
 Nik



[iproute PATCH v2 1/7] tc: m_action: Improve conversion to C99 style initializers

2016-06-21 Thread Phil Sutter
This improves my initial change in the following points:

- Drop superfluous comma after last expression in block.
- No need to initialize variables to zero as the key feature of C99
  initializers is to do this implicitly.
- By relocating the declaration of struct rtattr *tail, it can be
  initialized at the same time.

Fixes: a0a73b298a579 ("tc: m_action: Use C99 style initializers for struct req")
Signed-off-by: Phil Sutter 
---
 tc/m_action.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/tc/m_action.c b/tc/m_action.c
index ea16817aefd4f..ce399d2e43ccc 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -398,10 +398,9 @@ static int tc_action_gd(int cmd, unsigned int flags, int 
*argc_p, char ***argv_p
.n = {
.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg)),
.nlmsg_flags = NLM_F_REQUEST | flags,
-   .nlmsg_type = cmd,
+   .nlmsg_type = cmd
},
-   .t.tca_family = AF_UNSPEC,
-   .buf = { 0 }
+   .t.tca_family = AF_UNSPEC
};
 
argc -= 1;
@@ -491,8 +490,6 @@ static int tc_action_modify(int cmd, unsigned int flags, 
int *argc_p, char ***ar
int argc = *argc_p;
char **argv = *argv_p;
int ret = 0;
-
-   struct rtattr *tail;
struct {
struct nlmsghdr n;
struct tcamsg   t;
@@ -501,13 +498,12 @@ static int tc_action_modify(int cmd, unsigned int flags, 
int *argc_p, char ***ar
.n = {
.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg)),
.nlmsg_flags = NLM_F_REQUEST | flags,
-   .nlmsg_type = cmd,
+   .nlmsg_type = cmd
},
-   .t.tca_family = AF_UNSPEC,
-   .buf = { 0 }
+   .t.tca_family = AF_UNSPEC
};
+   struct rtattr *tail = NLMSG_TAIL();
 
-   tail = NLMSG_TAIL();
argc -= 1;
argv += 1;
if (parse_action(, , TCA_ACT_TAB, )) {
@@ -539,8 +535,7 @@ static int tc_act_list_or_flush(int argc, char **argv, int 
event)
charbuf[MAX_MSG];
} req = {
.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcamsg)),
-   .t.tca_family = AF_UNSPEC,
-   .buf = { 0 }
+   .t.tca_family = AF_UNSPEC
};
 
tail = NLMSG_TAIL();
-- 
2.8.2



[iproute PATCH v2 6/7] misc/ifstat: simplify unsigned value comparison

2016-06-21 Thread Phil Sutter
By directly comparing the value of both unsigned variables, casting to
signed becomes unnecessary.

This also fixes for compiling with older versions of gcc (at least
<=3.4.6) which emit the following warning:

| ifstat.c: In function `update_db':
| ifstat.c:542: warning: comparison is always false due to limited range of 
data type

Signed-off-by: Phil Sutter 
---
 misc/ifstat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/misc/ifstat.c b/misc/ifstat.c
index abbb4e732fcef..9a44da487599e 100644
--- a/misc/ifstat.c
+++ b/misc/ifstat.c
@@ -539,7 +539,7 @@ static void update_db(int interval)
int i;
 
for (i = 0; i < MAXS; i++) {
-   if ((long)(h1->ival[i] - n->ival[i]) < 
0) {
+   if (h1->ival[i] < n->ival[i]) {
memset(n->ival, 0, 
sizeof(n->ival));
break;
}
-- 
2.8.2



  1   2   >