[PATCH net-next 0/5] mlx4 misc fixes and improvements

Hi Dave,

This patchset contains some bug fixes, a cleanup, and small improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Thanks,
Tariq.

Jack Morgenstein (1):
  net/mlx4_core: Fix deadlock when switching between polling and event
    fw commands

Kamal Heib (2):
  net/mlx4_en: Fix wrong indentation
  net/mlx4_core: Fix to clean devlink resources

Leon Romanovsky (1):
  net/mlx4_core: Use RCU to perform radix tree lookup for SRQ

Tariq Toukan (1):
  net/mlx4_en: Add branch prediction hints in RX data-path

 drivers/net/ethernet/mellanox/mlx4/cmd.c   | 23 +++++++++++++++++------
 drivers/net/ethernet/mellanox/mlx4/en_rx.c | 28 +++++++++++++++-------------
 drivers/net/ethernet/mellanox/mlx4/main.c  |  3 +++
 drivers/net/ethernet/mellanox/mlx4/mlx4.h  |  2 ++
 drivers/net/ethernet/mellanox/mlx4/srq.c   | 14 +++++---------
 5 files changed, 42 insertions(+), 28 deletions(-)

-- 
1.8.3.1

From: Kamal Heib <redacted>

Use tabs instead of spaces before if statement, no functional change.

Fixes: e7c1c2c46201 ("mlx4_en: Added self diagnostics test implementation")
Signed-off-by: Kamal Heib <redacted>
Signed-off-by: Tariq Toukan <redacted>
---
 drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index bb7ccb109aa4..51fa0aa8a49c 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c

@@ -1022,7 +1022,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
 			goto next;
 		}
 
-                if (unlikely(priv->validate_loopback)) {
+		if (unlikely(priv->validate_loopback)) {
 			validate_loopback(priv, skb);
 			goto next;
 		}

-- 
1.8.3.1

Add likely/unlikely hints to improve branch predictions
in the RX data-path.

Signed-off-by: Tariq Toukan <redacted>
---
 drivers/net/ethernet/mellanox/mlx4/en_rx.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6758292311f4..bb7ccb109aa4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c

@@ -72,7 +72,7 @@ static int mlx4_alloc_pages(struct mlx4_en_priv *priv,
 	}
 	dma = dma_map_page(priv->ddev, page, 0, PAGE_SIZE << order,
 			   frag_info->dma_dir);
-	if (dma_mapping_error(priv->ddev, dma)) {
+	if (unlikely(dma_mapping_error(priv->ddev, dma))) {
 		put_page(page);
 		return -ENOMEM;
 	}

@@ -108,7 +108,8 @@ static int mlx4_en_alloc_frags(struct mlx4_en_priv *priv,
 		    ring_alloc[i].page_size)
 			continue;
 
-		if (mlx4_alloc_pages(priv, &page_alloc[i], frag_info, gfp))
+		if (unlikely(mlx4_alloc_pages(priv, &page_alloc[i],
+					      frag_info, gfp)))
 			goto out;
 	}
 

@@ -585,7 +586,7 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
 		frag_info = &priv->frag_info[nr];
 		if (length <= frag_info->frag_prefix_size)
 			break;
-		if (!frags[nr].page)
+		if (unlikely(!frags[nr].page))
 			goto fail;
 
 		dma = be64_to_cpu(rx_desc->data[nr].addr);

@@ -625,7 +626,7 @@ static struct sk_buff *mlx4_en_rx_skb(struct mlx4_en_priv *priv,
 	dma_addr_t dma;
 
 	skb = netdev_alloc_skb(priv->dev, SMALL_PACKET_SIZE + NET_IP_ALIGN);
-	if (!skb) {
+	if (unlikely(!skb)) {
 		en_dbg(RX_ERR, priv, "Failed allocating skb\n");
 		return NULL;
 	}

@@ -736,7 +737,8 @@ static int get_fixed_ipv6_csum(__wsum hw_checksum, struct sk_buff *skb,
 {
 	__wsum csum_pseudo_hdr = 0;
 
-	if (ipv6h->nexthdr == IPPROTO_FRAGMENT || ipv6h->nexthdr == IPPROTO_HOPOPTS)
+	if (unlikely(ipv6h->nexthdr == IPPROTO_FRAGMENT ||
+		     ipv6h->nexthdr == IPPROTO_HOPOPTS))
 		return -1;
 	hw_checksum = csum_add(hw_checksum, (__force __wsum)htons(ipv6h->nexthdr));
 

@@ -769,7 +771,7 @@ static int check_csum(struct mlx4_cqe *cqe, struct sk_buff *skb, void *va,
 		get_fixed_ipv4_csum(hw_checksum, skb, hdr);
 #if IS_ENABLED(CONFIG_IPV6)
 	else if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPV6))
-		if (get_fixed_ipv6_csum(hw_checksum, skb, hdr))
+		if (unlikely(get_fixed_ipv6_csum(hw_checksum, skb, hdr)))
 			return -1;
 #endif
 	return 0;

@@ -796,10 +798,10 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
 	u64 timestamp;
 	bool l2_tunnel;
 
-	if (!priv->port_up)
+	if (unlikely(!priv->port_up))
 		return 0;
 
-	if (budget <= 0)
+	if (unlikely(budget <= 0))
 		return polled;
 
 	/* Protect accesses to: ring->xdp_prog, priv->mac_hash list */

@@ -902,16 +904,16 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
 			case XDP_PASS:
 				break;
 			case XDP_TX:
-				if (!mlx4_en_xmit_frame(frags, dev,
+				if (likely(!mlx4_en_xmit_frame(frags, dev,
 							length, tx_index,
-							&doorbell_pending))
+							&doorbell_pending)))
 					goto consumed;
 				break;
 			default:
 				bpf_warn_invalid_xdp_action(act);
 			case XDP_ABORTED:
 			case XDP_DROP:
-				if (mlx4_en_rx_recycle(ring, frags))
+				if (likely(mlx4_en_rx_recycle(ring, frags)))
 					goto consumed;
 				goto next;
 			}

@@ -1015,7 +1017,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
 
 		/* GRO not possible, complete processing here */
 		skb = mlx4_en_rx_skb(priv, rx_desc, frags, length);
-		if (!skb) {
+		if (unlikely(!skb)) {
 			ring->dropped++;
 			goto next;
 		}

-- 
1.8.3.1

From: Leon Romanovsky <redacted>

Radix tree lookup can be performed without locking.

Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Suggested-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Leon Romanovsky <redacted>
Signed-off-by: Tariq Toukan <redacted>
---
 drivers/net/ethernet/mellanox/mlx4/srq.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/srq.c b/drivers/net/ethernet/mellanox/mlx4/srq.c
index 67146624eb58..f44d089e2ca6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/srq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/srq.c

@@ -45,15 +45,12 @@ void mlx4_srq_event(struct mlx4_dev *dev, u32 srqn, int event_type)
 	struct mlx4_srq_table *srq_table = &mlx4_priv(dev)->srq_table;
 	struct mlx4_srq *srq;
 
-	spin_lock(&srq_table->lock);
-
+	rcu_read_lock();
 	srq = radix_tree_lookup(&srq_table->tree, srqn & (dev->caps.num_srqs - 1));
+	rcu_read_unlock();
 	if (srq)
 		atomic_inc(&srq->refcount);
-
-	spin_unlock(&srq_table->lock);
-
-	if (!srq) {
+	else {
 		mlx4_warn(dev, "Async event for bogus SRQ %08x\n", srqn);
 		return;
 	}

@@ -301,12 +298,11 @@ struct mlx4_srq *mlx4_srq_lookup(struct mlx4_dev *dev, u32 srqn)
 {
 	struct mlx4_srq_table *srq_table = &mlx4_priv(dev)->srq_table;
 	struct mlx4_srq *srq;
-	unsigned long flags;
 
-	spin_lock_irqsave(&srq_table->lock, flags);
+	rcu_read_lock();
 	srq = radix_tree_lookup(&srq_table->tree,
 				srqn & (dev->caps.num_srqs - 1));
-	spin_unlock_irqrestore(&srq_table->lock, flags);
+	rcu_read_unlock();
 
 	return srq;
 }

-- 
1.8.3.1

From: Kamal Heib <redacted>

This patch cleans devlink resources by calling devlink_port_unregister()
to avoid the following issues:

- Kernel panic when triggering reset flow.
- Memory leak due to unfreed resources in mlx4_init_port_info().

Fixes: 09d4d087cd48 ("mlx4: Implement devlink interface")
Signed-off-by: Kamal Heib <redacted>
Signed-off-by: Tariq Toukan <redacted>
---
 drivers/net/ethernet/mellanox/mlx4/main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 75dd2e3d3059..7183ac4135d2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c

@@ -2970,6 +2970,7 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
 		mlx4_err(dev, "Failed to create mtu file for port %d\n", port);
 		device_remove_file(&info->dev->persist->pdev->dev,
 				   &info->port_attr);
+		devlink_port_unregister(&info->devlink_port);
 		info->port = -1;
 	}
 

@@ -2984,6 +2985,8 @@ static void mlx4_cleanup_port_info(struct mlx4_port_info *info)
 	device_remove_file(&info->dev->persist->pdev->dev, &info->port_attr);
 	device_remove_file(&info->dev->persist->pdev->dev,
 			   &info->port_mtu_attr);
+	devlink_port_unregister(&info->devlink_port);
+
 #ifdef CONFIG_RFS_ACCEL
 	free_irq_cpu_rmap(info->rmap);
 	info->rmap = NULL;

-- 
1.8.3.1

From: Jack Morgenstein <redacted>

When switching from polling-based fw commands to event-based fw
commands, there is a race condition which could cause a fw command
in another task to hang: that task will keep waiting for the polling
sempahore, but may never be able to acquire it. This is due to
mlx4_cmd_use_events, which "down"s the sempahore back to 0.

During driver initialization, this is not a problem, since no other
tasks which invoke FW commands are active.

However, there is a problem if the driver switches to polling mode
and then back to event mode during normal operation.

The "test_interrupts" feature does exactly that.
Running "ethtool -t <eth device> offline" causes the PF driver to
temporarily switch to polling mode, and then back to event mode.
(Note that for VF drivers, such switching is not performed).

Fix this by adding a read-write semaphore for protection when
switching between modes.

Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Signed-off-by: Matan Barak <redacted>
Signed-off-by: Jack Morgenstein <redacted>
Signed-off-by: Tariq Toukan <redacted>
---
 drivers/net/ethernet/mellanox/mlx4/cmd.c  | 23 +++++++++++++++++------
 drivers/net/ethernet/mellanox/mlx4/mlx4.h |  2 ++
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index f04a423ff79d..a58d96cf1ed1 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c

@@ -785,17 +785,23 @@ int __mlx4_cmd(struct mlx4_dev *dev, u64 in_param, u64 *out_param,
 		return mlx4_cmd_reset_flow(dev, op, op_modifier, -EIO);
 
 	if (!mlx4_is_mfunc(dev) || (native && mlx4_is_master(dev))) {
+		int ret;
+
 		if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)
 			return mlx4_internal_err_ret_value(dev, op,
 							  op_modifier);
+		down_read(&mlx4_priv(dev)->cmd.switch_sem);
 		if (mlx4_priv(dev)->cmd.use_events)
-			return mlx4_cmd_wait(dev, in_param, out_param,
-					     out_is_imm, in_modifier,
-					     op_modifier, op, timeout);
+			ret = mlx4_cmd_wait(dev, in_param, out_param,
+					    out_is_imm, in_modifier,
+					    op_modifier, op, timeout);
 		else
-			return mlx4_cmd_poll(dev, in_param, out_param,
-					     out_is_imm, in_modifier,
-					     op_modifier, op, timeout);
+			ret = mlx4_cmd_poll(dev, in_param, out_param,
+					    out_is_imm, in_modifier,
+					    op_modifier, op, timeout);
+
+		up_read(&mlx4_priv(dev)->cmd.switch_sem);
+		return ret;
 	}
 	return mlx4_slave_cmd(dev, in_param, out_param, out_is_imm,
 			      in_modifier, op_modifier, op, timeout);

@@ -2454,6 +2460,7 @@ int mlx4_cmd_init(struct mlx4_dev *dev)
 	int flags = 0;
 
 	if (!priv->cmd.initialized) {
+		init_rwsem(&priv->cmd.switch_sem);
 		mutex_init(&priv->cmd.slave_cmd_mutex);
 		sema_init(&priv->cmd.poll_sem, 1);
 		priv->cmd.use_events = 0;

@@ -2583,6 +2590,7 @@ int mlx4_cmd_use_events(struct mlx4_dev *dev)
 	if (!priv->cmd.context)
 		return -ENOMEM;
 
+	down_write(&priv->cmd.switch_sem);
 	for (i = 0; i < priv->cmd.max_cmds; ++i) {
 		priv->cmd.context[i].token = i;
 		priv->cmd.context[i].next  = i + 1;

@@ -2606,6 +2614,7 @@ int mlx4_cmd_use_events(struct mlx4_dev *dev)
 
 	down(&priv->cmd.poll_sem);
 	priv->cmd.use_events = 1;
+	up_write(&priv->cmd.switch_sem);
 
 	return err;
 }

@@ -2618,6 +2627,7 @@ void mlx4_cmd_use_polling(struct mlx4_dev *dev)
 	struct mlx4_priv *priv = mlx4_priv(dev);
 	int i;
 
+	down_write(&priv->cmd.switch_sem);
 	priv->cmd.use_events = 0;
 
 	for (i = 0; i < priv->cmd.max_cmds; ++i)

@@ -2626,6 +2636,7 @@ void mlx4_cmd_use_polling(struct mlx4_dev *dev)
 	kfree(priv->cmd.context);
 
 	up(&priv->cmd.poll_sem);
+	up_write(&priv->cmd.switch_sem);
 }
 
 struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev)

diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index c9d7fc5159f2..c128ba3ef014 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h

@@ -46,6 +46,7 @@
 #include <linux/interrupt.h>
 #include <linux/spinlock.h>
 #include <net/devlink.h>
+#include <linux/rwsem.h>
 
 #include <linux/mlx4/device.h>
 #include <linux/mlx4/driver.h>

@@ -627,6 +628,7 @@ struct mlx4_cmd {
 	struct mutex		slave_cmd_mutex;
 	struct semaphore	poll_sem;
 	struct semaphore	event_sem;
+	struct rw_semaphore	switch_sem;
 	int			max_cmds;
 	spinlock_t		context_lock;
 	int			free_head;

-- 
1.8.3.1

From: Tariq Toukan <redacted>
Date: Mon, 12 Sep 2016 16:20:11 +0300

This patchset contains some bug fixes, a cleanup, and small improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Again, coding style fixes and optimizations like branch prediction
hints are not bug fixes and therefore not appropriate for 'net'.

On Fri, Sep 16, 2016 at 2:21 AM, David Miller [off-list ref] wrote:

From: Tariq Toukan <redacted>
Date: Mon, 12 Sep 2016 16:20:11 +0300

quoted

This patchset contains some bug fixes, a cleanup, and small improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Again, coding style fixes and optimizations like branch prediction
hints are not bug fixes and therefore not appropriate for 'net'.

Hi Dave,

He sent it to net-next, not net... ok?

Or.

Hi Dave,

On 16/09/2016 2:21 AM, David Miller wrote:

From: Tariq Toukan <redacted>
Date: Mon, 12 Sep 2016 16:20:11 +0300

quoted

This patchset contains some bug fixes, a cleanup, and small improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Again, coding style fixes and optimizations like branch prediction
hints are not bug fixes and therefore not appropriate for 'net'.

Yes, I know. Please notice that it was submitted to net-next this time.

Regards,
Tariq

From: Tariq Toukan <redacted>
Date: Sun, 18 Sep 2016 10:27:23 +0300

Hi Dave,

On 16/09/2016 2:21 AM, David Miller wrote:

quoted

From: Tariq Toukan <redacted>
Date: Mon, 12 Sep 2016 16:20:11 +0300

quoted

This patchset contains some bug fixes, a cleanup, and small
improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Again, coding style fixes and optimizations like branch prediction
hints are not bug fixes and therefore not appropriate for 'net'.

Yes, I know. Please notice that it was submitted to net-next this
time.

This is completely incompatible with a request for one of the changes
to go into -stable.

If the change is not in 'net', it can't go to -stable.

On Mon, Sep 19, 2016 at 5:00 AM, David Miller [off-list ref] wrote:

From: Tariq Toukan <redacted>
Date: Sun, 18 Sep 2016 10:27:23 +0300

quoted

Hi Dave,

On 16/09/2016 2:21 AM, David Miller wrote:

quoted

From: Tariq Toukan <redacted>
Date: Mon, 12 Sep 2016 16:20:11 +0300

quoted

This patchset contains some bug fixes, a cleanup, and small
improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Again, coding style fixes and optimizations like branch prediction
hints are not bug fixes and therefore not appropriate for 'net'.

Yes, I know. Please notice that it was submitted to net-next this
time.

This is completely incompatible with a request for one of the changes
to go into -stable.

If the change is not in 'net', it can't go to -stable.

Dave,

So when we're pretty late in the 4.8-rc cycle, a fix for a problem
which was not introduced in 4.8-rc1 was targeted to net-next (4.9) and
not net.

This indeed creates a small mess when the fix needs to go to -stable as well.

I guess the correct thing to do next time, would be to either send to
net and ask you to take it to stable as part of picking the patch --
or send to net-next, and later send you a request to put it to stable
-- or, wait a bit and send it to net of the next kernel along with
stable request... we will pick one of these three way of doings next
(...) time.

So, at this point, I think it would be just correct to take the series
to net-next, and on a future point we'll issue a request to push the
patch into stable.

Or.

Or.

From: Tariq Toukan <redacted>
Date: Tue, 20 Sep 2016 11:50:17 +0300

quoted

So when we're pretty late in the 4.8-rc cycle, a fix for a problem
which was not introduced in 4.8-rc1 was targeted to net-next (4.9) and
not net.

This indeed creates a small mess when the fix needs to go to -stable
as well.

 ...

I see that the series status is 'Changes requested'.
I agree with Or. If possible, please take the series, and we will
issue a request to push into -stable in the future.
Anyway, I can also do a re-submission if you prefer. Just let me know.

Either the bug exists in pre-net trees and needs to go to -stable, or
it does not.

If it does, you submit the change targetting 'net'.

This whole mess occurred because you tried to combine changes
inappropriate for 'net' with the bug fix.

Instead of fixing the issue properly, by removing the cleanups
and inappropriate changes, you tried to target 'net-next' instead.

That's why this mess exists.

Please send the change properly, targetting 'net', and not
alongside changes which are inappropriate to 'net'.

There is no other acceptable way to resolve this problem.

Thank you.

On 19/09/2016 8:32 AM, Or Gerlitz wrote:

On Mon, Sep 19, 2016 at 5:00 AM, David Miller [off-list ref] wrote:

quoted

From: Tariq Toukan <redacted>
Date: Sun, 18 Sep 2016 10:27:23 +0300

quoted

Hi Dave,

On 16/09/2016 2:21 AM, David Miller wrote:

quoted

From: Tariq Toukan <redacted>
Date: Mon, 12 Sep 2016 16:20:11 +0300

quoted

This patchset contains some bug fixes, a cleanup, and small
improvements
from the team to the mlx4 Eth and core drivers.

Series generated against net-next commit:
02154927c115 "net: dsa: bcm_sf2: Get VLAN_PORT_MASK from b53_device"

Please push the following patch to -stable  >= 4.6 as well:
"net/mlx4_core: Fix to clean devlink resources"

Again, coding style fixes and optimizations like branch prediction
hints are not bug fixes and therefore not appropriate for 'net'.

Yes, I know. Please notice that it was submitted to net-next this
time.

This is completely incompatible with a request for one of the changes
to go into -stable.

If the change is not in 'net', it can't go to -stable.

Dave,

So when we're pretty late in the 4.8-rc cycle, a fix for a problem
which was not introduced in 4.8-rc1 was targeted to net-next (4.9) and
not net.

This indeed creates a small mess when the fix needs to go to -stable as well.

I guess the correct thing to do next time, would be to either send to
net and ask you to take it to stable as part of picking the patch --
or send to net-next, and later send you a request to put it to stable
-- or, wait a bit and send it to net of the next kernel along with
stable request... we will pick one of these three way of doings next
(...) time.

So, at this point, I think it would be just correct to take the series
to net-next, and on a future point we'll issue a request to push the
patch into stable.

Or.

Or.

Hi Dave,

I see that the series status is 'Changes requested'.
I agree with Or. If possible, please take the series, and we will issue a request to push into -stable in the future.
Anyway, I can also do a re-submission if you prefer. Just let me know.

Thanks,
Tariq