All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rakib Mullick <rakib.mullick@gmail.com>
To: mingo@kernel.org
Cc: peterz@infradead.org, mka@chromium.org, longman@redhat.com,
	adobriyan@gmail.com, tglx@linutronix.de,
	akpm@linux-foundation.org, tj@kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH]  Fix isocpus's param handling when CPUMASK_OFFSTACK=n.
Date: Mon, 23 Oct 2017 19:01:54 +0600	[thread overview]
Message-ID: <20171023130154.9050-1-rakib.mullick@gmail.com> (raw)
In-Reply-To: <20171023115050.twyx4kn7ttvon2ch@gmail.com>


> On Mon, Oct 23, 2017 at 5:50 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
>> * Rakib Mullick <rakib.mullick@gmail.com> wrote:
>> +/**
>> + * cpumask_last - get the last cpu in a cpumask
>
> Please capitalize 'CPU' properly in documentation.
>
OK.
>> +     int ret, lastcpu;
>>
>>       alloc_bootmem_cpumask_var(&cpu_isolated_map);
>>       ret = cpulist_parse(str, cpu_isolated_map);
>> -     if (ret) {
>> -             pr_err("sched: Error, all isolcpus= values must be between 0 and %u\n", nr_cpu_ids);
>> +     lastcpu = cpumask_last(cpu_isolated_map);
>> +     if (ret || lastcpu >= nr_cpu_ids) {
>
> Any reason why 'lastcpu' has to be introduced - why not just use cpumask_last()
> directly in the condition? It looks obvious enough of a pattern.
Thought it reflects what we're doing here, but yes, actually it's redundant.

>> +             pr_err("sched: Error, all isolcpus= values must be between 0 and %u\n",
>> +                             nr_cpu_ids-1);
>
> Please don't break the line mindlessly just due to checkpatch complaining - it
> makes the code less readable.
>
Yes, right, mindlessly followed what checkpatch was complaining.

Please see the following patch, with changes made based on your review and
patched up against -rc6.

Thanks,
Rakib
---

[PATCH](v1) Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

 cpulist_parse() uses nr_cpumask_bits as limit to parse the
passed buffer from kernel commandline. What nr_cpumask_bits
represents varies depends upon CONFIG_CPUMASK_OFFSTACK option.
If CONFIG_CPUMASK_OFFSTACK=n, then nr_cpumask_bits is same as
NR_CPUS, which might not represent the # of cpus really exist
(default 64). So, there's a chance of gap between nr_cpu_ids
and NR_CPUS, which ultimately lead towards invalid cpulist_parse()
operation. For example, if isolcpus=9 is passed on a 8 cpu
system (CONFIG_CPUMASK_OFFSTACK=n) it doesn't show the error
that it suppose to.

This patch fixes this issue by effectively find out the last
cpu of the passed isolcpus list and checking it with nr_cpu_ids.
Also, fixes the error message where the nr_cpu_ids should be
nr_cpu_ids-1, since the cpu numbering starts from 0.

Changes since v0 (Ingo):
	* use cpumask_last() directly into the condition.
	* use CPU rather cpu in documentation
	* undo line break

Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
---
 include/linux/cpumask.h | 16 ++++++++++++++++
 kernel/sched/topology.c |  4 ++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index cd415b7..63661de 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -130,6 +130,11 @@ static inline unsigned int cpumask_first(const struct cpumask *srcp)
 	return 0;
 }
 
+static inline unsigned int cpumask_last(const struct cpumask *srcp)
+{
+	return 0;
+}
+
 /* Valid inputs for n are -1 and 0. */
 static inline unsigned int cpumask_next(int n, const struct cpumask *srcp)
 {
@@ -178,6 +183,17 @@ static inline unsigned int cpumask_first(const struct cpumask *srcp)
 	return find_first_bit(cpumask_bits(srcp), nr_cpumask_bits);
 }
 
+/**
+ * cpumask_last - get the last CPU in a cpumask
+ * @srcp:	- the cpumask pointer
+ *
+ * Returns	>= nr_cpumask_bits if no CPUs set.
+ */
+static inline unsigned int cpumask_last(const struct cpumask *srcp)
+{
+	return find_last_bit(cpumask_bits(srcp), nr_cpumask_bits);
+}
+
 unsigned int cpumask_next(int n, const struct cpumask *srcp);
 
 /**
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index f1cf4f3..060cee5 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -470,8 +470,8 @@ static int __init isolated_cpu_setup(char *str)
 
 	alloc_bootmem_cpumask_var(&cpu_isolated_map);
 	ret = cpulist_parse(str, cpu_isolated_map);
-	if (ret) {
-		pr_err("sched: Error, all isolcpus= values must be between 0 and %u\n", nr_cpu_ids);
+	if (ret || cpumask_last(cpu_isolated_map) >= nr_cpu_ids) {
+		pr_err("sched: Error, all isolcpus= values must be between 0 and %u\n", nr_cpu_ids-1);
 		return 0;
 	}
 	return 1;
-- 
2.9.3

  reply	other threads:[~2017-10-23 13:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-15 13:18 [PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n Rakib Mullick
2017-10-20  8:49 ` Ingo Molnar
2017-10-21  7:10   ` Rakib Mullick
2017-10-23 11:50     ` Ingo Molnar
2017-10-23 13:01       ` Rakib Mullick [this message]
2017-10-24 10:17         ` [tip:sched/core] sched/isolcpus: Fix "isolcpus=" boot parameter handling when !CONFIG_CPUMASK_OFFSTACK tip-bot for Rakib Mullick

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=20171023130154.9050-1-rakib.mullick@gmail.com \
    --to=rakib.mullick@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@kernel.org \
    --cc=mka@chromium.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.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.