[pull request][net 0/8] Mellanox, mlx5 fixes 2018-07-18

[pull request][net 0/8] Mellanox, mlx5 fixes 2018-07-18

[Saeed Mahameed]

Hi Dave,

The following series provides fixes to mlx5 core and net device driver.

Please pull and let me know if there's any problem.

For -stable v4.7
    net/mlx5e: Don't allow aRFS for encapsulated packets
    net/mlx5e: Fix quota counting in aRFS expire flow

For -stable v4.15
    net/mlx5e: Only allow offloading decap egress (egdev) flows
    net/mlx5e: Refine ets validation function
    net/mlx5: Adjust clock overflow work period

For -stable v4.17
    net/mlx5: E-Switch, UBSAN fix undefined behavior in mlx5_eswitch_mode

Thanks,
Saeed.

---

The following changes since commit e56b8ce363a36fb7b74b80aaa5cc9084f2c908b4:

  tcp: identify cryptic messages as TCP seq # bugs (2018-07-18 15:26:33 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-fixes-2018-07-18

for you to fetch changes up to 7e29392eee7a1e3318eeb1099807264a49f60e33:

  net/mlx5e: Only allow offloading decap egress (egdev) flows (2018-07-18 18:16:59 -0700)

----------------------------------------------------------------
mlx5-fixes-2018-07-18

----------------------------------------------------------------
Ariel Levkovich (1):
      net/mlx5: Adjust clock overflow work period

Eran Ben Elisha (2):
      net/mlx5e: Fix quota counting in aRFS expire flow
      net/mlx5e: Don't allow aRFS for encapsulated packets

Raed Salem (1):
      net/mlx5: Fix 'DON'T_TRAP' functionality

Roi Dayan (1):
      net/mlx5e: Only allow offloading decap egress (egdev) flows

Saeed Mahameed (1):
      net/mlx5: E-Switch, UBSAN fix undefined behavior in mlx5_eswitch_mode

Shay Agroskin (1):
      net/mlx5e: Refine ets validation function

Tariq Toukan (1):
      net/mlx5: Fix QP fragmented buffer allocation

 drivers/net/ethernet/mellanox/mlx5/core/alloc.c    |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c  |  7 +++--
 drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 17 +++++------
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c    |  4 +++
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c  |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c  |  2 +-
 .../net/ethernet/mellanox/mlx5/core/lib/clock.c    | 12 ++++++--
 drivers/net/ethernet/mellanox/mlx5/core/wq.c       | 34 ++++++++++++++--------
 include/linux/mlx5/driver.h                        | 18 ++++++++++--
 9 files changed, 67 insertions(+), 31 deletions(-)

[net 1/8] net/mlx5e: Refine ets validation function

[Saeed Mahameed]

From: Shay Agroskin <shayag@mellanox.com>

Removed an error message received when configuring ETS total
bandwidth to be zero.
Our hardware doesn't support such configuration, so we shall
reject it in the driver. Nevertheless, we removed the error message
in order to eliminate error messages caused by old userspace tools
who try to pass such configuration.

Fixes: ff0891915cd7 ("net/mlx5e: Fix ETS BW check")
Signed-off-by: Shay Agroskin <shayag@mellanox.com>
Reviewed-by: Huy Nguyen <huyn@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 .../net/ethernet/mellanox/mlx5/core/en_dcbnl.c  | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
index 0a52f31fef37..86bc9ac99586 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -275,7 +275,8 @@ int mlx5e_dcbnl_ieee_setets_core(struct mlx5e_priv *priv, struct ieee_ets *ets)
 }
 
 static int mlx5e_dbcnl_validate_ets(struct net_device *netdev,
-				    struct ieee_ets *ets)
+				    struct ieee_ets *ets,
+				    bool zero_sum_allowed)
 {
 	bool have_ets_tc = false;
 	int bw_sum = 0;
@@ -300,8 +301,9 @@ static int mlx5e_dbcnl_validate_ets(struct net_device *netdev,
 	}
 
 	if (have_ets_tc && bw_sum != 100) {
-		netdev_err(netdev,
-			   "Failed to validate ETS: BW sum is illegal\n");
+		if (bw_sum || (!bw_sum && !zero_sum_allowed))
+			netdev_err(netdev,
+				   "Failed to validate ETS: BW sum is illegal\n");
 		return -EINVAL;
 	}
 	return 0;
@@ -316,7 +318,7 @@ static int mlx5e_dcbnl_ieee_setets(struct net_device *netdev,
 	if (!MLX5_CAP_GEN(priv->mdev, ets))
 		return -EOPNOTSUPP;
 
-	err = mlx5e_dbcnl_validate_ets(netdev, ets);
+	err = mlx5e_dbcnl_validate_ets(netdev, ets, false);
 	if (err)
 		return err;
 
@@ -642,12 +644,9 @@ static u8 mlx5e_dcbnl_setall(struct net_device *netdev)
 			  ets.prio_tc[i]);
 	}
 
-	err = mlx5e_dbcnl_validate_ets(netdev, &ets);
-	if (err) {
-		netdev_err(netdev,
-			   "%s, Failed to validate ETS: %d\n", __func__, err);
+	err = mlx5e_dbcnl_validate_ets(netdev, &ets, true);
+	if (err)
 		goto out;
-	}
 
 	err = mlx5e_dcbnl_ieee_setets_core(priv, &ets);
 	if (err) {
-- 
2.17.0

[net 2/8] net/mlx5: Adjust clock overflow work period

[Saeed Mahameed]

From: Ariel Levkovich <lariel@mellanox.com>

When driver converts HW timestamp to wall clock time it subtracts
the last saved cycle counter from the HW timestamp and converts the
difference to nanoseconds.
The conversion is done by multiplying the cycles difference with the
clock multiplier value as a first step and therefore the cycles
difference should be small enough so that the multiplication product
doesn't exceed 64bit.

The overflow handling routine is in charge of updating the last saved
cycle counter in driver and it is called periodically using kernel
delayed workqueue.

The delay period for this work is calculated using the max HW cycle
counter value (a 41 bit mask) as a base which doesn't take the 64bit
limit into account so the delay period may be incorrect and too
long to prevent a large difference between the HW counter and the last
saved counter in SW.

This change adjusts the work period for the HW clock overflow work by
taking the minimum between the previous value and the quotient of max
u64 value and the clock multiplier value.

Fixes: ef9814deafd0 ("net/mlx5e: Add HW timestamping (TS) support")
Signed-off-by: Ariel Levkovich <lariel@mellanox.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
index 1e062e6b2587..3f767cde4c1d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
@@ -488,6 +488,7 @@ void mlx5_pps_event(struct mlx5_core_dev *mdev,
 void mlx5_init_clock(struct mlx5_core_dev *mdev)
 {
 	struct mlx5_clock *clock = &mdev->clock;
+	u64 overflow_cycles;
 	u64 ns;
 	u64 frac = 0;
 	u32 dev_freq;
@@ -511,10 +512,17 @@ void mlx5_init_clock(struct mlx5_core_dev *mdev)
 
 	/* Calculate period in seconds to call the overflow watchdog - to make
 	 * sure counter is checked at least once every wrap around.
+	 * The period is calculated as the minimum between max HW cycles count
+	 * (The clock source mask) and max amount of cycles that can be
+	 * multiplied by clock multiplier where the result doesn't exceed
+	 * 64bits.
 	 */
-	ns = cyclecounter_cyc2ns(&clock->cycles, clock->cycles.mask,
+	overflow_cycles = div64_u64(~0ULL >> 1, clock->cycles.mult);
+	overflow_cycles = min(overflow_cycles, clock->cycles.mask >> 1);
+
+	ns = cyclecounter_cyc2ns(&clock->cycles, overflow_cycles,
 				 frac, &frac);
-	do_div(ns, NSEC_PER_SEC / 2 / HZ);
+	do_div(ns, NSEC_PER_SEC / HZ);
 	clock->overflow_period = ns;
 
 	mdev->clock_info_page = alloc_page(GFP_KERNEL);
-- 
2.17.0

[net 3/8] net/mlx5e: Fix quota counting in aRFS expire flow

[Saeed Mahameed]

From: Eran Ben Elisha <eranbe@mellanox.com>

Quota should follow the amount of rules which do expire, and not the
number of rules that were examined, fixed that.

Fixes: 18c908e477dc ("net/mlx5e: Add accelerated RFS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
index 75e4308ba786..7b54a4999cf3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
@@ -381,14 +381,14 @@ static void arfs_may_expire_flow(struct mlx5e_priv *priv)
 	HLIST_HEAD(del_list);
 	spin_lock_bh(&priv->fs.arfs.arfs_lock);
 	mlx5e_for_each_arfs_rule(arfs_rule, htmp, priv->fs.arfs.arfs_tables, i, j) {
-		if (quota++ > MLX5E_ARFS_EXPIRY_QUOTA)
-			break;
 		if (!work_pending(&arfs_rule->arfs_work) &&
 		    rps_may_expire_flow(priv->netdev,
 					arfs_rule->rxq, arfs_rule->flow_id,
 					arfs_rule->filter_id)) {
 			hlist_del_init(&arfs_rule->hlist);
 			hlist_add_head(&arfs_rule->hlist, &del_list);
+			if (quota++ > MLX5E_ARFS_EXPIRY_QUOTA)
+				break;
 		}
 	}
 	spin_unlock_bh(&priv->fs.arfs.arfs_lock);
-- 
2.17.0

[net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

[Saeed Mahameed]

From: Eran Ben Elisha <eranbe@mellanox.com>

Driver is yet to support aRFS for encapsulated packets, return early
error in such case.

Fixes: 18c908e477dc ("net/mlx5e: Add accelerated RFS support")
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
index 7b54a4999cf3..d258bb679271 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c
@@ -711,6 +711,9 @@ int mlx5e_rx_flow_steer(struct net_device *dev, const struct sk_buff *skb,
 	    skb->protocol != htons(ETH_P_IPV6))
 		return -EPROTONOSUPPORT;
 
+	if (skb->encapsulation)
+		return -EPROTONOSUPPORT;
+
 	arfs_t = arfs_get_table(arfs, arfs_get_ip_proto(skb), skb->protocol);
 	if (!arfs_t)
 		return -EPROTONOSUPPORT;
-- 
2.17.0

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

[Or Gerlitz]

On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
> From: Eran Ben Elisha <eranbe@mellanox.com>
>
> Driver is yet to support aRFS for encapsulated packets, return early
> error in such case.


Eran,

Isn't that something which is done wrong by the arfs stack code?

If the kernel has an SKB which has encap set and an arfs steering
rule is programed into the driver, the API should include a driver neutral
description for the encap header for the HW to match, so maybe we can just do

diff --git a/net/core/dev.c b/net/core/dev.c
index 0df1771..b93008f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3934,6 +3934,10 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
                flow_table = rcu_dereference(rxqueue->rps_flow_table);
                if (!flow_table)
                        goto out;
+
+               if (skb->encapsulation)
+                       return -EPROTONOSUPPORT;
+
                flow_id = skb_get_hash(skb) & flow_table->mask;
                rc = dev->netdev_ops->ndo_rx_flow_steer(dev, skb,
                                                        rxq_index, flow_id);

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

[Eran Ben Elisha]

On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>> From: Eran Ben Elisha <eranbe@mellanox.com>
>>
>> Driver is yet to support aRFS for encapsulated packets, return early
>> error in such case.
>
>
> Eran,
>
> Isn't that something which is done wrong by the arfs stack code?
>
> If the kernel has an SKB which has encap set and an arfs steering
> rule is programed into the driver, the API should include a driver neutral
> description for the encap header for the HW to match, so maybe we can just do
>

Hi Or,
This could break existing drivers support for tunneled aRFS, and hurts
their RX performance dramatically..
IMHO, it is expected from the driver to figure out that the skb holds
encap packet and act accordingly.


> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0df1771..b93008f 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3934,6 +3934,10 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
>                 flow_table = rcu_dereference(rxqueue->rps_flow_table);
>                 if (!flow_table)
>                         goto out;
> +
> +               if (skb->encapsulation)
> +                       return -EPROTONOSUPPORT;
> +
>                 flow_id = skb_get_hash(skb) & flow_table->mask;
>                 rc = dev->netdev_ops->ndo_rx_flow_steer(dev, skb,
>                                                         rxq_index, flow_id);

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

[Or Gerlitz]

On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha
<eranlinuxmellanox@gmail.com> wrote:
> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>>> From: Eran Ben Elisha <eranbe@mellanox.com>
>>>
>>> Driver is yet to support aRFS for encapsulated packets, return early
>>> error in such case.
>>
>>
>> Eran,
>>
>> Isn't that something which is done wrong by the arfs stack code?
>>
>> If the kernel has an SKB which has encap set and an arfs steering
>> rule is programed into the driver, the API should include a driver neutral
>> description for the encap header for the HW to match, so maybe we can just do
>>
>
> Hi Or,
> This could break existing drivers support for tunneled aRFS, and hurts
> their RX performance dramatically..

> IMHO, it is expected from the driver to figure out that the skb holds
> encap packet and act accordingly.

I don't think this one bit indication on the skb is enough for
any HW driver (e.g mlx4, mlx5 and others) to properly set
the steering rules.

The problem you indicate typically doesn't come into play in the presence
of VMs, since the host TCP stack isn't active on such traffic.

This is maybe why it wasn't pointed earlier.

I believe that more drivers are broken (mlx4?)

Looking now on bnxt, I see they dissect the skb and then check the
FLOW_DIS_ENCAPSULATION flag but not always err.

If we want to make sure we don't break anyone else, we can indeed have
the check done in our drivers.

It seems that the check done by bnxt is more general, thoughts?

Or.

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

[Eran Ben Elisha]

On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha
> <eranlinuxmellanox@gmail.com> wrote:
>> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>>>> From: Eran Ben Elisha <eranbe@mellanox.com>
>>>>
>>>> Driver is yet to support aRFS for encapsulated packets, return early
>>>> error in such case.
>>>
>>>
>>> Eran,
>>>
>>> Isn't that something which is done wrong by the arfs stack code?
>>>
>>> If the kernel has an SKB which has encap set and an arfs steering
>>> rule is programed into the driver, the API should include a driver neutral
>>> description for the encap header for the HW to match, so maybe we can just do
>>>
>>
>> Hi Or,
>> This could break existing drivers support for tunneled aRFS, and hurts
>> their RX performance dramatically..
>
>> IMHO, it is expected from the driver to figure out that the skb holds
>> encap packet and act accordingly.
>
> I don't think this one bit indication on the skb is enough for
> any HW driver (e.g mlx4, mlx5 and others) to properly set
> the steering rules.

why do you think it is not enough?
mlx5e currently cannot offload tunneled packets, so this info is
perfectly fit in order to reject.

>
> The problem you indicate typically doesn't come into play in the presence
> of VMs, since the host TCP stack isn't active on such traffic.
>
> This is maybe why it wasn't pointed earlier.
>
> I believe that more drivers are broken (mlx4?)

We can do a fix for that latter.

>
> Looking now on bnxt, I see they dissect the skb and then check the
> FLOW_DIS_ENCAPSULATION flag but not always err.
>
> If we want to make sure we don't break anyone else, we can indeed have
> the check done in our drivers.
>
> It seems that the check done by bnxt is more general, thoughts?

I see bnxt driver checking protocol using this mechanism as well,
in mlx5e it was selected via skb metadata, let's keep going with this approach.

>
> Or.

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

[Or Gerlitz]

On Thu, Jul 19, 2018 at 12:02 PM, Eran Ben Elisha
<eranlinuxmellanox@gmail.com> wrote:
> On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha
>> <eranlinuxmellanox@gmail.com> wrote:
>>> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed <saeedm@mellanox.com> wrote:
>>>>> From: Eran Ben Elisha <eranbe@mellanox.com>
>>>>>
>>>>> Driver is yet to support aRFS for encapsulated packets, return early
>>>>> error in such case.
>>>>
>>>>
>>>> Eran,
>>>>
>>>> Isn't that something which is done wrong by the arfs stack code?
>>>>
>>>> If the kernel has an SKB which has encap set and an arfs steering
>>>> rule is programed into the driver, the API should include a driver neutral
>>>> description for the encap header for the HW to match, so maybe we can just do
>>>>
>>>
>>> Hi Or,
>>> This could break existing drivers support for tunneled aRFS, and hurts
>>> their RX performance dramatically..
>>
>>> IMHO, it is expected from the driver to figure out that the skb holds
>>> encap packet and act accordingly.
>>
>> I don't think this one bit indication on the skb is enough for
>> any HW driver (e.g mlx4, mlx5 and others) to properly set
>> the steering rules.
>
> why do you think it is not enough?
> mlx5e currently cannot offload tunneled packets, so this info is
> perfectly fit in order to reject.

Do we know that all the flows in stack that deals with reception of packets do
this marking for encapsulated packets? is this documented some/where? if
this is what we think, then the patch is ok.

[net 5/8] net/mlx5: E-Switch, UBSAN fix undefined behavior in mlx5_eswitch_mode

[Saeed Mahameed]

With debug kernel UBSAN detects the following issue, which might happen
when eswitch instance is not created, fix this by testing the eswitch
pointer before returning the eswitch mode, if not set return mode =
SRIOV_NONE.

[   32.528951] UBSAN: Undefined behaviour in drivers/net/ethernet/mellanox/mlx5/core/eswitch.c:2219:12
[   32.528951] member access within null pointer of type 'struct mlx5_eswitch'
[   32.528951] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc3-dirty #181
[   32.528951] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
[   32.528951] Call Trace:
[   32.528951]  dump_stack+0xc7/0x13b
[   32.528951]  ? show_regs_print_info+0x5/0x5
[   32.528951]  ? __pm_runtime_use_autosuspend+0x140/0x140
[   32.528951]  ubsan_epilogue+0x9/0x49
[   32.528951]  ubsan_type_mismatch_common+0x1f9/0x2c0
[   32.528951]  ? ucs2_as_utf8+0x310/0x310
[   32.528951]  ? device_initialize+0x229/0x2e0
[   32.528951]  __ubsan_handle_type_mismatch+0x9f/0xc9
[   32.528951]  ? __ubsan_handle_divrem_overflow+0x19b/0x19b
[   32.578008]  ? ib_device_get_by_index+0xf0/0xf0
[   32.578008]  mlx5_eswitch_mode+0x30/0x40
[   32.578008]  mlx5_ib_add+0x1e0/0x4a0

Fixes: 57cbd893c4c5 ("net/mlx5: E-Switch, Move representors definition to a global scope")
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index b79d74860a30..dd01ad4c0b54 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -2216,6 +2216,6 @@ int mlx5_eswitch_get_vport_stats(struct mlx5_eswitch *esw,
 
 u8 mlx5_eswitch_mode(struct mlx5_eswitch *esw)
 {
-	return esw->mode;
+	return ESW_ALLOWED(esw) ? esw->mode : SRIOV_NONE;
 }
 EXPORT_SYMBOL_GPL(mlx5_eswitch_mode);
-- 
2.17.0

[net 6/8] net/mlx5: Fix 'DON'T_TRAP' functionality

[Saeed Mahameed]

From: Raed Salem <raeds@mellanox.com>

The flow counters binding support commit introduced a code change where
none NULL 'rule_dest' is always passed to mlx5_add_flow_rules, this breaks
'DON'T_TRAP' rules insertion.

The fix uses the equivalent 'dest_num' value instead of dest pointer
at the failed check.

fixes: 3b3233fbf02e ('IB/mlx5: Add flow counters binding support')
Signed-off-by: Raed Salem <raeds@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index f1a86cea86a0..6ddb2565884d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1887,7 +1887,7 @@ mlx5_add_flow_rules(struct mlx5_flow_table *ft,
 	if (flow_act->action == MLX5_FLOW_CONTEXT_ACTION_FWD_NEXT_PRIO) {
 		if (!fwd_next_prio_supported(ft))
 			return ERR_PTR(-EOPNOTSUPP);
-		if (dest)
+		if (dest_num)
 			return ERR_PTR(-EINVAL);
 		mutex_lock(&root->chain_lock);
 		next_ft = find_next_chained_ft(prio);
-- 
2.17.0

[net 7/8] net/mlx5: Fix QP fragmented buffer allocation

[Saeed Mahameed]

From: Tariq Toukan <tariqt@mellanox.com>

Fix bad alignment of SQ buffer in fragmented QP allocation.
It should start directly after RQ buffer ends.

Take special care of the end case where the RQ buffer does not occupy
a whole page. RQ size is a power of two, so would be the case only for
small RQ sizes (RQ size < PAGE_SIZE).

Fix wrong assignments for sqb->size (mistakenly assigned RQ size),
and for npages value of RQ and SQ.

Fixes: 3a2f70331226 ("net/mlx5: Use order-0 allocations for all WQ types")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 .../net/ethernet/mellanox/mlx5/core/alloc.c   |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/wq.c  | 34 ++++++++++++-------
 include/linux/mlx5/driver.h                   | 18 ++++++++--
 3 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/alloc.c b/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
index 323ffe8bf7e4..456f30007ad6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/alloc.c
@@ -123,7 +123,7 @@ int mlx5_frag_buf_alloc_node(struct mlx5_core_dev *dev, int size,
 	int i;
 
 	buf->size = size;
-	buf->npages = 1 << get_order(size);
+	buf->npages = DIV_ROUND_UP(size, PAGE_SIZE);
 	buf->page_shift = PAGE_SHIFT;
 	buf->frags = kcalloc(buf->npages, sizeof(struct mlx5_buf_list),
 			     GFP_KERNEL);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/wq.c b/drivers/net/ethernet/mellanox/mlx5/core/wq.c
index b97bb72b4db4..86478a6b99c5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/wq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/wq.c
@@ -113,35 +113,45 @@ int mlx5_wq_cyc_create(struct mlx5_core_dev *mdev, struct mlx5_wq_param *param,
 	return err;
 }
 
-static void mlx5e_qp_set_frag_buf(struct mlx5_frag_buf *buf,
-				  struct mlx5_wq_qp *qp)
+static void mlx5_qp_set_frag_buf(struct mlx5_frag_buf *buf,
+				 struct mlx5_wq_qp *qp)
 {
+	struct mlx5_frag_buf_ctrl *sq_fbc;
 	struct mlx5_frag_buf *rqb, *sqb;
 
-	rqb = &qp->rq.fbc.frag_buf;
+	rqb  = &qp->rq.fbc.frag_buf;
 	*rqb = *buf;
 	rqb->size   = mlx5_wq_cyc_get_byte_size(&qp->rq);
-	rqb->npages = 1 << get_order(rqb->size);
+	rqb->npages = DIV_ROUND_UP(rqb->size, PAGE_SIZE);
 
-	sqb = &qp->sq.fbc.frag_buf;
-	*sqb = *buf;
-	sqb->size   = mlx5_wq_cyc_get_byte_size(&qp->rq);
-	sqb->npages = 1 << get_order(sqb->size);
+	sq_fbc = &qp->sq.fbc;
+	sqb    = &sq_fbc->frag_buf;
+	*sqb   = *buf;
+	sqb->size   = mlx5_wq_cyc_get_byte_size(&qp->sq);
+	sqb->npages = DIV_ROUND_UP(sqb->size, PAGE_SIZE);
 	sqb->frags += rqb->npages; /* first part is for the rq */
+	if (sq_fbc->strides_offset)
+		sqb->frags--;
 }
 
 int mlx5_wq_qp_create(struct mlx5_core_dev *mdev, struct mlx5_wq_param *param,
 		      void *qpc, struct mlx5_wq_qp *wq,
 		      struct mlx5_wq_ctrl *wq_ctrl)
 {
+	u32 sq_strides_offset;
 	int err;
 
 	mlx5_fill_fbc(MLX5_GET(qpc, qpc, log_rq_stride) + 4,
 		      MLX5_GET(qpc, qpc, log_rq_size),
 		      &wq->rq.fbc);
-	mlx5_fill_fbc(ilog2(MLX5_SEND_WQE_BB),
-		      MLX5_GET(qpc, qpc, log_sq_size),
-		      &wq->sq.fbc);
+
+	sq_strides_offset =
+		((wq->rq.fbc.frag_sz_m1 + 1) % PAGE_SIZE) / MLX5_SEND_WQE_BB;
+
+	mlx5_fill_fbc_offset(ilog2(MLX5_SEND_WQE_BB),
+			     MLX5_GET(qpc, qpc, log_sq_size),
+			     sq_strides_offset,
+			     &wq->sq.fbc);
 
 	err = mlx5_db_alloc_node(mdev, &wq_ctrl->db, param->db_numa_node);
 	if (err) {
@@ -156,7 +166,7 @@ int mlx5_wq_qp_create(struct mlx5_core_dev *mdev, struct mlx5_wq_param *param,
 		goto err_db_free;
 	}
 
-	mlx5e_qp_set_frag_buf(&wq_ctrl->buf, wq);
+	mlx5_qp_set_frag_buf(&wq_ctrl->buf, wq);
 
 	wq->rq.db  = &wq_ctrl->db.db[MLX5_RCV_DBR];
 	wq->sq.db  = &wq_ctrl->db.db[MLX5_SND_DBR];
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 80cbb7fdce4a..83957920653a 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -358,6 +358,7 @@ struct mlx5_frag_buf_ctrl {
 	struct mlx5_frag_buf	frag_buf;
 	u32			sz_m1;
 	u32			frag_sz_m1;
+	u32			strides_offset;
 	u8			log_sz;
 	u8			log_stride;
 	u8			log_frag_strides;
@@ -983,14 +984,22 @@ static inline u32 mlx5_base_mkey(const u32 key)
 	return key & 0xffffff00u;
 }
 
-static inline void mlx5_fill_fbc(u8 log_stride, u8 log_sz,
-				 struct mlx5_frag_buf_ctrl *fbc)
+static inline void mlx5_fill_fbc_offset(u8 log_stride, u8 log_sz,
+					u32 strides_offset,
+					struct mlx5_frag_buf_ctrl *fbc)
 {
 	fbc->log_stride = log_stride;
 	fbc->log_sz     = log_sz;
 	fbc->sz_m1	= (1 << fbc->log_sz) - 1;
 	fbc->log_frag_strides = PAGE_SHIFT - fbc->log_stride;
 	fbc->frag_sz_m1	= (1 << fbc->log_frag_strides) - 1;
+	fbc->strides_offset = strides_offset;
+}
+
+static inline void mlx5_fill_fbc(u8 log_stride, u8 log_sz,
+				 struct mlx5_frag_buf_ctrl *fbc)
+{
+	mlx5_fill_fbc_offset(log_stride, log_sz, 0, fbc);
 }
 
 static inline void mlx5_core_init_cq_frag_buf(struct mlx5_frag_buf_ctrl *fbc,
@@ -1004,7 +1013,10 @@ static inline void mlx5_core_init_cq_frag_buf(struct mlx5_frag_buf_ctrl *fbc,
 static inline void *mlx5_frag_buf_get_wqe(struct mlx5_frag_buf_ctrl *fbc,
 					  u32 ix)
 {
-	unsigned int frag = (ix >> fbc->log_frag_strides);
+	unsigned int frag;
+
+	ix  += fbc->strides_offset;
+	frag = ix >> fbc->log_frag_strides;
 
 	return fbc->frag_buf.frags[frag].buf +
 		((fbc->frag_sz_m1 & ix) << fbc->log_stride);
-- 
2.17.0

[net 8/8] net/mlx5e: Only allow offloading decap egress (egdev) flows

[Saeed Mahameed]

From: Roi Dayan <roid@mellanox.com>

We get egress rules through the egdev mechanism when the ingress device
is not supporting offload, with the expected use-case of tunnel decap
ingress rule set on shared tunnel device.

Make sure to offload egress/egdev rules only if decap action (tunnel key
unset) exists there and err otherwise.

Fixes: 717503b9cf57 ("net: sched: convert cls_flower->egress_dev users to tc_setup_cb_egdev infra")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 0edf4751a8ba..3a2c4e548226 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1957,6 +1957,10 @@ static bool actions_match_supported(struct mlx5e_priv *priv,
 	else
 		actions = flow->nic_attr->action;
 
+	if (flow->flags & MLX5E_TC_FLOW_EGRESS &&
+	    !(actions & MLX5_FLOW_CONTEXT_ACTION_DECAP))
+		return false;
+
 	if (actions & MLX5_FLOW_CONTEXT_ACTION_MOD_HDR)
 		return modify_header_match_supported(&parse_attr->spec, exts);
 
-- 
2.17.0

Re: [pull request][net 0/8] Mellanox, mlx5 fixes 2018-07-18

[David Miller]

From: Saeed Mahameed <saeedm@mellanox.com>
Date: Wed, 18 Jul 2018 18:26:04 -0700

> The following series provides fixes to mlx5 core and net device driver.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Saeed.

Based upon the thread with Or, it would be useful to do some auditing
and make sure all tunnels set skb->encapsulation.

> For -stable v4.7
>     net/mlx5e: Don't allow aRFS for encapsulated packets
>     net/mlx5e: Fix quota counting in aRFS expire flow
> 
> For -stable v4.15
>     net/mlx5e: Only allow offloading decap egress (egdev) flows
>     net/mlx5e: Refine ets validation function
>     net/mlx5: Adjust clock overflow work period
> 
> For -stable v4.17
>     net/mlx5: E-Switch, UBSAN fix undefined behavior in mlx5_eswitch_mode

Queued up.

Thanks.

Re: [pull request][net 0/8] Mellanox, mlx5 fixes 2018-07-18

[Saeed Mahameed]

On Sat, 2018-07-21 at 10:20 -0700, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Wed, 18 Jul 2018 18:26:04 -0700
> 
> > The following series provides fixes to mlx5 core and net device
> > driver.
> > 
> > Please pull and let me know if there's any problem.
> 
> Pulled, thanks Saeed.
> 
> Based upon the thread with Or, it would be useful to do some auditing
> and make sure all tunnels set skb->encapsulation.
> 

Thanks Dave, Eran's patch relies on our driver setting skb-
>encapsulation, since the rps rule is injected directly from the device
rx path once netif_receive_skb_internal is called via the gro stack way
before forwarding the skb to the tunnel netdev.

> > For -stable v4.7
> >     net/mlx5e: Don't allow aRFS for encapsulated packets
> >     net/mlx5e: Fix quota counting in aRFS expire flow
> > 
> > For -stable v4.15
> >     net/mlx5e: Only allow offloading decap egress (egdev) flows
> >     net/mlx5e: Refine ets validation function
> >     net/mlx5: Adjust clock overflow work period
> > 
> > For -stable v4.17
> >     net/mlx5: E-Switch, UBSAN fix undefined behavior in
> > mlx5_eswitch_mode
> 
> Queued up.
> 
> Thanks.