[PATCH 0/4] net: drop netif_attrmask_next*()

[PATCH 0/4] net: drop netif_attrmask_next*()

[Yury Norov]

netif_attrmask_next_and() generates warnings if CONFIG_DEBUG_PER_CPU_MAPS
is enabled. It is used in a single place. netif_attrmask_next() is not
used at all. With some rework of __netif_set_xps_queue(), we can drop
both functions, switch the code to well-tested bitmap API and fix the
warning.

Yury Norov (4):
  net: move setup code out of mutex in __netif_set_xps_queue()
  net: merge XPS_CPU_DEV_MAPS_SIZE and XPS_RXQ_DEV_MAPS_SIZE macros
  net: initialize online_mask unconditionally in __netif_set_xps_queue()
  net: fix opencoded for_each_and_bit() in __netif_set_xps_queue()

 include/linux/netdevice.h | 53 ++-------------------------------------
 net/core/dev.c            | 34 +++++++++++++------------
 2 files changed, 20 insertions(+), 67 deletions(-)

-- 
2.34.1

[PATCH 1/4] net: move setup code out of mutex in __netif_set_xps_queue()

[Yury Norov]

maps_sz, nr_ids and online_mask may be set out of the mutex.

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 net/core/dev.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 56c8b0921c9f..b848a75026c4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2563,9 +2563,6 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 			return -EINVAL;
 	}
 
-	mutex_lock(&xps_map_mutex);
-
-	dev_maps = xmap_dereference(dev->xps_maps[type]);
 	if (type == XPS_RXQS) {
 		maps_sz = XPS_RXQ_DEV_MAPS_SIZE(num_tc, dev->num_rx_queues);
 		nr_ids = dev->num_rx_queues;
@@ -2579,6 +2576,10 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 	if (maps_sz < L1_CACHE_BYTES)
 		maps_sz = L1_CACHE_BYTES;
 
+	mutex_lock(&xps_map_mutex);
+
+	dev_maps = xmap_dereference(dev->xps_maps[type]);
+
 	/* The old dev_maps could be larger or smaller than the one we're
 	 * setting up now, as dev->num_tc or nr_ids could have been updated in
 	 * between. We could try to be smart, but let's be safe instead and only
-- 
2.34.1

[PATCH 2/4] net: merge XPS_CPU_DEV_MAPS_SIZE and XPS_RXQ_DEV_MAPS_SIZE macros

[Yury Norov]

The macros are used in a single place, and merging them
would simplify the code.

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 include/linux/netdevice.h | 7 ++-----
 net/core/dev.c            | 3 +--
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4d6d5a2dd82e..6f8cdd5c7908 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -819,11 +819,8 @@ struct xps_dev_maps {
 	struct xps_map __rcu *attr_map[]; /* Either CPUs map or RXQs map */
 };
 
-#define XPS_CPU_DEV_MAPS_SIZE(_tcs) (sizeof(struct xps_dev_maps) +	\
-	(nr_cpu_ids * (_tcs) * sizeof(struct xps_map *)))
-
-#define XPS_RXQ_DEV_MAPS_SIZE(_tcs, _rxqs) (sizeof(struct xps_dev_maps) +\
-	(_rxqs * (_tcs) * sizeof(struct xps_map *)))
+#define XPS_DEV_MAPS_SIZE(_tcs, nr) (sizeof(struct xps_dev_maps) +\
+	((nr) * (_tcs) * sizeof(struct xps_map *)))
 
 #endif /* CONFIG_XPS */
 
diff --git a/net/core/dev.c b/net/core/dev.c
index b848a75026c4..39a4cc7b3a06 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2564,15 +2564,14 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 	}
 
 	if (type == XPS_RXQS) {
-		maps_sz = XPS_RXQ_DEV_MAPS_SIZE(num_tc, dev->num_rx_queues);
 		nr_ids = dev->num_rx_queues;
 	} else {
-		maps_sz = XPS_CPU_DEV_MAPS_SIZE(num_tc);
 		if (num_possible_cpus() > 1)
 			online_mask = cpumask_bits(cpu_online_mask);
 		nr_ids = nr_cpu_ids;
 	}
 
+	maps_sz = XPS_DEV_MAPS_SIZE(num_tc, nr_ids);
 	if (maps_sz < L1_CACHE_BYTES)
 		maps_sz = L1_CACHE_BYTES;
 
-- 
2.34.1

[PATCH 3/4] net: initialize online_mask unconditionally in __netif_set_xps_queue()

[Yury Norov]

If the mask is initialized unconditionally, it's possible to use bitmap
API to traverse it, which is done in the following patch.

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 net/core/dev.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 39a4cc7b3a06..266378ad1cf1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2542,7 +2542,7 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 			  u16 index, enum xps_map_type type)
 {
 	struct xps_dev_maps *dev_maps, *new_dev_maps = NULL, *old_dev_maps = NULL;
-	const unsigned long *online_mask = NULL;
+	const unsigned long *online_mask;
 	bool active = false, copy = false;
 	int i, j, tci, numa_node_id = -2;
 	int maps_sz, num_tc = 1, tc = 0;
@@ -2565,9 +2565,11 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 
 	if (type == XPS_RXQS) {
 		nr_ids = dev->num_rx_queues;
+		online_mask = bitmap_alloc(nr_ids, GFP_KERNEL);
+		if (!online_mask)
+			return -ENOMEM;
 	} else {
-		if (num_possible_cpus() > 1)
-			online_mask = cpumask_bits(cpu_online_mask);
+		online_mask = cpumask_bits(cpu_online_mask);
 		nr_ids = nr_cpu_ids;
 	}
 
@@ -2593,10 +2595,8 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 	     j < nr_ids;) {
 		if (!new_dev_maps) {
 			new_dev_maps = kzalloc(maps_sz, GFP_KERNEL);
-			if (!new_dev_maps) {
-				mutex_unlock(&xps_map_mutex);
-				return -ENOMEM;
-			}
+			if (!new_dev_maps)
+				goto err_out;
 
 			new_dev_maps->nr_ids = nr_ids;
 			new_dev_maps->num_tc = num_tc;
@@ -2718,7 +2718,8 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 
 out_no_maps:
 	mutex_unlock(&xps_map_mutex);
-
+	if (type == XPS_RXQS)
+		bitmap_free(online_mask);
 	return 0;
 error:
 	/* remove any maps that we added */
@@ -2733,8 +2734,10 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 		}
 	}
 
+err_out:
 	mutex_unlock(&xps_map_mutex);
-
+	if (type == XPS_RXQS)
+		bitmap_free(online_mask);
 	kfree(new_dev_maps);
 	return -ENOMEM;
 }
-- 
2.34.1

Re: [PATCH 3/4] net: initialize online_mask unconditionally in __netif_set_xps_queue()

[Yury Norov]

On Sun, Oct 02, 2022 at 08:17:01AM -0700, Yury Norov wrote:
> If the mask is initialized unconditionally, it's possible to use bitmap
> API to traverse it, which is done in the following patch.
> 
> Signed-off-by: Yury Norov <yury.norov@gmail.com>
> ---
>  net/core/dev.c | 21 ++++++++++++---------
>  1 file changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 39a4cc7b3a06..266378ad1cf1 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2542,7 +2542,7 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  			  u16 index, enum xps_map_type type)
>  {
>  	struct xps_dev_maps *dev_maps, *new_dev_maps = NULL, *old_dev_maps = NULL;
> -	const unsigned long *online_mask = NULL;
> +	const unsigned long *online_mask;
>  	bool active = false, copy = false;
>  	int i, j, tci, numa_node_id = -2;
>  	int maps_sz, num_tc = 1, tc = 0;
> @@ -2565,9 +2565,11 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  
>  	if (type == XPS_RXQS) {
>  		nr_ids = dev->num_rx_queues;
> +		online_mask = bitmap_alloc(nr_ids, GFP_KERNEL);
> +		if (!online_mask)
> +			return -ENOMEM;

Oh god, I missed a line here while preparing the patch. It should be:

 +		online_mask = bitmap_alloc(nr_ids, GFP_KERNEL);
 +		if (!online_mask)
 +			return -ENOMEM;
 +              bitmap_fill(online_mask, nr_ids);

I'll send v2 after collecting the comments.

>  	} else {
> -		if (num_possible_cpus() > 1)
> -			online_mask = cpumask_bits(cpu_online_mask);
> +		online_mask = cpumask_bits(cpu_online_mask);
>  		nr_ids = nr_cpu_ids;
>  	}
>  
> @@ -2593,10 +2595,8 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  	     j < nr_ids;) {
>  		if (!new_dev_maps) {
>  			new_dev_maps = kzalloc(maps_sz, GFP_KERNEL);
> -			if (!new_dev_maps) {
> -				mutex_unlock(&xps_map_mutex);
> -				return -ENOMEM;
> -			}
> +			if (!new_dev_maps)
> +				goto err_out;
>  
>  			new_dev_maps->nr_ids = nr_ids;
>  			new_dev_maps->num_tc = num_tc;
> @@ -2718,7 +2718,8 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  
>  out_no_maps:
>  	mutex_unlock(&xps_map_mutex);
> -
> +	if (type == XPS_RXQS)
> +		bitmap_free(online_mask);
>  	return 0;
>  error:
>  	/* remove any maps that we added */
> @@ -2733,8 +2734,10 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
>  		}
>  	}
>  
> +err_out:
>  	mutex_unlock(&xps_map_mutex);
> -
> +	if (type == XPS_RXQS)
> +		bitmap_free(online_mask);
>  	kfree(new_dev_maps);
>  	return -ENOMEM;
>  }
> -- 
> 2.34.1

[PATCH 4/4] net: fix opencoded for_each_and_bit() in __netif_set_xps_queue()

[Yury Norov]

Replace opencoded bitmap traversing and drop unused
netif_attrmask_next*() functions

Signed-off-by: Yury Norov <yury.norov@gmail.com>
---
 include/linux/netdevice.h | 46 ---------------------------------------
 net/core/dev.c            |  3 +--
 2 files changed, 1 insertion(+), 48 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 6f8cdd5c7908..41c94e5854e8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3628,52 +3628,6 @@ static inline bool netif_attr_test_online(unsigned long j,
 
 	return (j < nr_bits);
 }
-
-/**
- *	netif_attrmask_next - get the next CPU/Rx queue in a cpu/Rx queues mask
- *	@n: CPU/Rx queue index
- *	@srcp: the cpumask/Rx queue mask pointer
- *	@nr_bits: number of bits in the bitmask
- *
- * Returns >= nr_bits if no further CPUs/Rx queues set.
- */
-static inline unsigned int netif_attrmask_next(int n, const unsigned long *srcp,
-					       unsigned int nr_bits)
-{
-	/* n is a prior cpu */
-	cpu_max_bits_warn(n + 1, nr_bits);
-
-	if (srcp)
-		return find_next_bit(srcp, nr_bits, n + 1);
-
-	return n + 1;
-}
-
-/**
- *	netif_attrmask_next_and - get the next CPU/Rx queue in \*src1p & \*src2p
- *	@n: CPU/Rx queue index
- *	@src1p: the first CPUs/Rx queues mask pointer
- *	@src2p: the second CPUs/Rx queues mask pointer
- *	@nr_bits: number of bits in the bitmask
- *
- * Returns >= nr_bits if no further CPUs/Rx queues set in both.
- */
-static inline int netif_attrmask_next_and(int n, const unsigned long *src1p,
-					  const unsigned long *src2p,
-					  unsigned int nr_bits)
-{
-	/* n is a prior cpu */
-	cpu_max_bits_warn(n + 1, nr_bits);
-
-	if (src1p && src2p)
-		return find_next_and_bit(src1p, src2p, nr_bits, n + 1);
-	else if (src1p)
-		return find_next_bit(src1p, nr_bits, n + 1);
-	else if (src2p)
-		return find_next_bit(src2p, nr_bits, n + 1);
-
-	return n + 1;
-}
 #else
 static inline int netif_set_xps_queue(struct net_device *dev,
 				      const struct cpumask *mask,
diff --git a/net/core/dev.c b/net/core/dev.c
index 266378ad1cf1..e3da6cb1e7ee 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2591,8 +2591,7 @@ int __netif_set_xps_queue(struct net_device *dev, const unsigned long *mask,
 		copy = true;
 
 	/* allocate memory for queue storage */
-	for (j = -1; j = netif_attrmask_next_and(j, online_mask, mask, nr_ids),
-	     j < nr_ids;) {
+	for_each_and_bit(j, online_mask, mask ? : online_mask, nr_ids) {
 		if (!new_dev_maps) {
 			new_dev_maps = kzalloc(maps_sz, GFP_KERNEL);
 			if (!new_dev_maps)
-- 
2.34.1

Re: [PATCH 0/4] net: drop netif_attrmask_next*()

[Jakub Kicinski]

On Sun,  2 Oct 2022 08:16:58 -0700 Yury Norov wrote:
> netif_attrmask_next_and() generates warnings if CONFIG_DEBUG_PER_CPU_MAPS
> is enabled.

Could you describe the nature of the warning? Is it a false positive 
or a legit warning?

If the former perhaps we should defer until after the next merge window.

> It is used in a single place. netif_attrmask_next() is not
> used at all. With some rework of __netif_set_xps_queue(), we can drop
> both functions, switch the code to well-tested bitmap API and fix the
> warning.

Re: [PATCH 0/4] net: drop netif_attrmask_next*()

[Yury Norov]

On Mon, Oct 03, 2022 at 09:50:48AM -0700, Jakub Kicinski wrote:
> On Sun,  2 Oct 2022 08:16:58 -0700 Yury Norov wrote:
> > netif_attrmask_next_and() generates warnings if CONFIG_DEBUG_PER_CPU_MAPS
> > is enabled.
> 
> Could you describe the nature of the warning? Is it a false positive 
> or a legit warning?
> 
> If the former perhaps we should defer until after the next merge window.

The problem is that netif_attrmask_next_and() is called with
n == nr_cpu_ids-1, which triggers cpu_max_bits_warn() after this:

https://lore.kernel.org/netdev/20220926103437.322f3c6c@kernel.org/

Underlying bitmap layer handles this correctly, so this wouldn't make
problems for people. But this is not a false-positive.

Thanks,
Yury

Re: [PATCH 0/4] net: drop netif_attrmask_next*()

[Jakub Kicinski]

On Mon, 3 Oct 2022 11:11:05 -0700 Yury Norov wrote:
> On Mon, Oct 03, 2022 at 09:50:48AM -0700, Jakub Kicinski wrote:
> > On Sun,  2 Oct 2022 08:16:58 -0700 Yury Norov wrote:  
> > > netif_attrmask_next_and() generates warnings if CONFIG_DEBUG_PER_CPU_MAPS
> > > is enabled.  
> > 
> > Could you describe the nature of the warning? Is it a false positive 
> > or a legit warning?
> > 
> > If the former perhaps we should defer until after the next merge window.  
> 
> The problem is that netif_attrmask_next_and() is called with
> n == nr_cpu_ids-1, which triggers cpu_max_bits_warn() after this:
> 
> https://lore.kernel.org/netdev/20220926103437.322f3c6c@kernel.org/

I see. Is that patch merged and on it's way? Perhaps we can just revert
it and try again after the merge window?

> Underlying bitmap layer handles this correctly, so this wouldn't make
> problems for people. But this is not a false-positive.

Re: [PATCH 0/4] net: drop netif_attrmask_next*()

[Yury Norov]

On Mon, Oct 03, 2022 at 04:25:56PM -0700, Jakub Kicinski wrote:
> On Mon, 3 Oct 2022 11:11:05 -0700 Yury Norov wrote:
> > On Mon, Oct 03, 2022 at 09:50:48AM -0700, Jakub Kicinski wrote:
> > > On Sun,  2 Oct 2022 08:16:58 -0700 Yury Norov wrote:  
> > > > netif_attrmask_next_and() generates warnings if CONFIG_DEBUG_PER_CPU_MAPS
> > > > is enabled.  
> > > 
> > > Could you describe the nature of the warning? Is it a false positive 
> > > or a legit warning?
> > > 
> > > If the former perhaps we should defer until after the next merge window.  
> > 
> > The problem is that netif_attrmask_next_and() is called with
> > n == nr_cpu_ids-1, which triggers cpu_max_bits_warn() after this:
> > 
> > https://lore.kernel.org/netdev/20220926103437.322f3c6c@kernel.org/
> 
> I see. Is that patch merged and on it's way?

This patch is already in pull request.

> Perhaps we can just revert it and try again after the merge window?

I don't understand this. To me it looks fairly normal - the check has
been fixed and merged (likely) in -rc1. After that we have 2 month to
spot, fix and test all issues discovered with correct cpumask_check().

I'm not insisting in moving this series in -rc1. Let's give it review
and careful testing, and merge in -rc2, 3 or whatever is appropriate.

Regarding cpumask_check() patch - I'd like to have it in -rc1 because
it will give people enough time to test their code...

Would it work?

Thanks,
Yury

Re: [PATCH 0/4] net: drop netif_attrmask_next*()

[Jakub Kicinski]

On Mon, 3 Oct 2022 17:07:31 -0700 Yury Norov wrote:
> > I see. Is that patch merged and on it's way?  
> 
> This patch is already in pull request.
> 
> > Perhaps we can just revert it and try again after the merge window?  
> 
> I don't understand this. To me it looks fairly normal - the check has
> been fixed and merged (likely) in -rc1. After that we have 2 month to
> spot, fix and test all issues discovered with correct cpumask_check().
> 
> I'm not insisting in moving this series in -rc1. Let's give it review
> and careful testing, and merge in -rc2, 3 or whatever is appropriate.
> 
> Regarding cpumask_check() patch - I'd like to have it in -rc1 because
> it will give people enough time to test their code...

AFAIU you can keep the cpumask_check() patch, we just need to revert
the netdev patch from your earlier series?

If so I strongly prefer that we revert the broken cleanup rather than
try to pile on more re-factoring. The trees are not going anywhere, we 
can queue the patches for 6.2.

Re: [PATCH 0/4] net: drop netif_attrmask_next*()

[Yury Norov]

On Mon, Oct 3, 2022 at 5:29 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 3 Oct 2022 17:07:31 -0700 Yury Norov wrote:
> > > I see. Is that patch merged and on it's way?
> >
> > This patch is already in pull request.
> >
> > > Perhaps we can just revert it and try again after the merge window?
> >
> > I don't understand this. To me it looks fairly normal - the check has
> > been fixed and merged (likely) in -rc1. After that we have 2 month to
> > spot, fix and test all issues discovered with correct cpumask_check().
> >
> > I'm not insisting in moving this series in -rc1. Let's give it review
> > and careful testing, and merge in -rc2, 3 or whatever is appropriate.
> >
> > Regarding cpumask_check() patch - I'd like to have it in -rc1 because
> > it will give people enough time to test their code...
>
> AFAIU you can keep the cpumask_check() patch, we just need to revert
> the netdev patch from your earlier series?

Yeah, I meant the "net: fix cpu_max_bits_warn() usage in
netif_attrmask_next{,_and}".

> If so I strongly prefer that we revert the broken cleanup rather than
> try to pile on more re-factoring.

What do you mean by broken cleanup? Netdev patch is acked by you,
and this series didn't receive negative feedback so far.

> The trees are not going anywhere, we can queue the patches for 6.2.

Sure, 6.2 is OK as well, but I think any 6.1-rc would be more appropriate.