All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: [PATCH 01/32] cpumask: always use nr_cpu_ids in formatting and parsing functions
Date: Sat, 24 Jan 2015 09:03:07 -0500	[thread overview]
Message-ID: <1422108218-25398-2-git-send-email-tj@kernel.org> (raw)
In-Reply-To: <1422108218-25398-1-git-send-email-tj@kernel.org>

Currently, the formatting and parsing functions in cpumask.h use
nr_cpumask_bits like other cpumask functions; however, nr_cpumask_bits
is either NR_CPUS or nr_cpu_ids depending on CONFIG_CPUMASK_OFFSTACK.
This leads to inconsistent behaviors.

With CONFIG_NR_CPUS=512 and !CONFIG_CPUMASK_OFFSTACK

  # cat /sys/devices/virtual/net/lo/queues/rx-0/rps_cpus
  00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000
  # cat /proc/self/status | grep Cpus_allowed:
  Cpus_allowed:   f

With CONFIG_NR_CPUS=1024 and CONFIG_CPUMASK_OFFSTACK (fedora default)

  # cat /sys/devices/virtual/net/lo/queues/rx-0/rps_cpus
  0
  # cat /proc/self/status | grep Cpus_allowed:
  Cpus_allowed:   f

Note that /proc/self/status is always using nr_cpu_ids regardless of
config.  This is because seq cpumask formattings functions always use
nr_cpu_ids.

Given that the same output fields may switch between the two forms,
converging on nr_cpu_ids always isn't too likely to surprise userland.
This patch updates the formatting and parsing functions in cpumask.h
to always use nr_cpu_ids.  There's no point in dealing with CPUs which
aren't even possible on the machine.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
---
Hello,

Linus, this is the first of the three pre-requisite patches to convert
the users of the dedicated bitmap formatting functions over to
'%*pb[l]' formatting.

If this approach is agreed upon, I think it'd be best to route these
three patches through mainline soon so that subsystem conversion
patches can pull these in and apply per-subsystem conversion patches.

Thanks.

 include/linux/cpumask.h | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index b950e9d..98939d1 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -550,7 +550,7 @@ static inline void cpumask_copy(struct cpumask *dstp,
 static inline int cpumask_scnprintf(char *buf, int len,
 				    const struct cpumask *srcp)
 {
-	return bitmap_scnprintf(buf, len, cpumask_bits(srcp), nr_cpumask_bits);
+	return bitmap_scnprintf(buf, len, cpumask_bits(srcp), nr_cpu_ids);
 }
 
 /**
@@ -564,7 +564,7 @@ static inline int cpumask_scnprintf(char *buf, int len,
 static inline int cpumask_parse_user(const char __user *buf, int len,
 				     struct cpumask *dstp)
 {
-	return bitmap_parse_user(buf, len, cpumask_bits(dstp), nr_cpumask_bits);
+	return bitmap_parse_user(buf, len, cpumask_bits(dstp), nr_cpu_ids);
 }
 
 /**
@@ -579,7 +579,7 @@ static inline int cpumask_parselist_user(const char __user *buf, int len,
 				     struct cpumask *dstp)
 {
 	return bitmap_parselist_user(buf, len, cpumask_bits(dstp),
-							nr_cpumask_bits);
+				     nr_cpu_ids);
 }
 
 /**
@@ -595,7 +595,7 @@ static inline int cpulist_scnprintf(char *buf, int len,
 				    const struct cpumask *srcp)
 {
 	return bitmap_scnlistprintf(buf, len, cpumask_bits(srcp),
-				    nr_cpumask_bits);
+				    nr_cpu_ids);
 }
 
 /**
@@ -610,7 +610,7 @@ static inline int cpumask_parse(const char *buf, struct cpumask *dstp)
 	char *nl = strchr(buf, '\n');
 	unsigned int len = nl ? (unsigned int)(nl - buf) : strlen(buf);
 
-	return bitmap_parse(buf, len, cpumask_bits(dstp), nr_cpumask_bits);
+	return bitmap_parse(buf, len, cpumask_bits(dstp), nr_cpu_ids);
 }
 
 /**
@@ -622,7 +622,7 @@ static inline int cpumask_parse(const char *buf, struct cpumask *dstp)
  */
 static inline int cpulist_parse(const char *buf, struct cpumask *dstp)
 {
-	return bitmap_parselist(buf, cpumask_bits(dstp), nr_cpumask_bits);
+	return bitmap_parselist(buf, cpumask_bits(dstp), nr_cpu_ids);
 }
 
 /**
@@ -817,7 +817,7 @@ static inline ssize_t
 cpumap_print_to_pagebuf(bool list, char *buf, const struct cpumask *mask)
 {
 	return bitmap_print_to_pagebuf(list, buf, cpumask_bits(mask),
-				      nr_cpumask_bits);
+				      nr_cpu_ids);
 }
 
 /*
-- 
2.1.0


  reply	other threads:[~2015-01-24 14:03 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-24 14:03 [PATCHSET] bitmap, cpumask, nodemask: implement %*pb[l] to format bitmaps directly from printf family of functions Tejun Heo
2015-01-24 14:03 ` Tejun Heo [this message]
2015-01-26 23:42   ` [PATCH 01/32] cpumask: always use nr_cpu_ids in formatting and parsing functions Rusty Russell
2015-01-24 14:03 ` [PATCH 02/32] lib/vsprintf: implement bitmap printing through '%*pb[l]' Tejun Heo
2015-01-26 13:50   ` Peter Zijlstra
2015-01-24 14:03 ` [PATCH 03/32] cpumask, nodemask: implement cpumask/nodemask_pr_args() Tejun Heo
2015-01-24 14:03 ` [PATCH 04/32] bitmap: use %*pb[l] to print bitmaps including cpumasks and nodemasks Tejun Heo
2015-01-24 14:03 ` [PATCH 05/32] mips: " Tejun Heo
2015-01-24 14:03 ` [PATCH 06/32] powerpc: " Tejun Heo
2015-01-24 14:03 ` [PATCH 07/32] s390: " Tejun Heo
2015-01-26  9:17   ` Heiko Carstens
2015-01-24 14:03 ` [PATCH 08/32] tile: " Tejun Heo
2015-01-24 14:03 ` [PATCH 09/32] x86: " Tejun Heo
2015-01-24 14:03 ` [PATCH 10/32] ia64: " Tejun Heo
2015-01-24 14:03   ` Tejun Heo
2015-01-24 14:03 ` [PATCH 11/32] xtensa: " Tejun Heo
2015-01-24 14:03 ` [PATCH 12/32] arm: " Tejun Heo
2015-01-24 14:03   ` Tejun Heo
2015-01-24 14:03 ` [PATCH 13/32] cpuset: " Tejun Heo
2015-01-24 14:03 ` [PATCH 14/32] rcu: " Tejun Heo
2015-01-24 21:16   ` Paul E. McKenney
2015-01-24 14:03 ` [PATCH 15/32] sched: " Tejun Heo
2015-01-24 14:03 ` [PATCH 16/32] time: " Tejun Heo
2015-01-24 14:03 ` [PATCH 17/32] percpu: " Tejun Heo
2015-01-24 14:03 ` [PATCH 18/32] workqueue: use %*pb[l] to format " Tejun Heo
2015-01-24 14:03 ` [PATCH 19/32] tracing: use %*pb[l] to print " Tejun Heo
2015-01-24 14:03 ` [PATCH 20/32] net: " Tejun Heo
2015-01-27  8:07   ` David Miller
2015-01-24 14:03 ` [PATCH 21/32] wireless: " Tejun Heo
2015-03-02 15:14   ` Kalle Valo
2015-01-24 14:03 ` [PATCH 22/32] input: " Tejun Heo
2015-01-24 14:03 ` [PATCH 23/32] scsi: " Tejun Heo
2015-01-24 14:03 ` [PATCH 24/32] usb: " Tejun Heo
2015-01-25 12:45   ` Greg Kroah-Hartman
2015-01-24 14:03 ` [PATCH 25/32] drivers/base: " Tejun Heo
2015-01-25 13:22   ` Greg Kroah-Hartman
2015-01-24 14:03 ` [PATCH 26/32] slub: " Tejun Heo
2015-01-24 17:48   ` Christoph Lameter
2015-01-24 14:03 ` [PATCH 27/32] mm: " Tejun Heo
2015-01-24 14:03 ` [PATCH 28/32] padata: " Tejun Heo
2015-01-24 14:03 ` [PATCH 29/32] proc: " Tejun Heo
2015-01-24 14:03 ` [PATCH 30/32] irq: " Tejun Heo
2015-01-24 14:03 ` [PATCH 31/32] profile: " Tejun Heo
2015-01-24 14:03 ` [PATCH 32/32] bitmap, cpumask, nodemask: remove dedicated formatting functions Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1422108218-25398-2-git-send-email-tj@kernel.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.