All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
To: Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>,
	Peter Zijlstra
	<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] Allow cpusets to be configured/built on non-SMP systems
Date: Tue, 03 Mar 2009 16:42:18 +0800	[thread overview]
Message-ID: <49ACED6A.9060002@cn.fujitsu.com> (raw)
In-Reply-To: <6599ad830903030026w2081a72dhf3cac90346b1d806-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Paul Menage wrote:
> On Mon, Mar 2, 2009 at 10:01 PM, Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> On Mon, Mar 2, 2009 at 7:17 PM, Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:
>>>> +static int generate_sched_domains(struct cpumask **domains,
>>>> +                     struct sched_domain_attr **attributes)
>>>> +{
>>> Except here should "return 0;", otherwise emit a compile warining.
>>>
>> Good catch - the weird thing is that (in my UML build) it doesn't
>> actually generate that warning. Mysterious.
>>
>> I'll resend with the extra return.
> 
> After looking at the sched domains code it's not clear to me that
> returning 0 is necessarily the right thing to do -
> partition_sched_domains() says that 0 is a special case used for
> destroying existing domains? Would returning 1 and setting up a single
> dummy domain be better?
> 

Yes, return 1 seems more reasonable. And if we do this, should we also set
*domains to NULL like this?

static int generate_sched_domains(struct cpumask **domains,
                     struct sched_domain_attr **attributes)
{
	*domains = NULL;
	return 1;
}

because otherwise partition_sched_domains() will access invalid memory:

void partition_sched_domains(int ndoms_new, struct cpumask *doms_new,
			     struct sched_domain_attr *dattr_new)
{
	...
	n = doms_new ? ndoms_new : 0;

	for (i = 0; i < ndoms_cur; i++) {
		for (j = 0; j < n && !new_topology; j++) {
			// *****here*****/
			if (cpumask_equal(&doms_cur[i], &doms_new[j])
			    && dattrs_equal(dattr_cur, i, dattr_new, j))
				goto match1;
		}
	...
	}

> Given that this return code only matters when CONFIG_HOTPLUG_CPU &&
> !CONFIG_SMP it's unlikely to ever be used

That's why I didn't comment on this.

> but I guess it's better to get it right.
> 

But I agree with you. :)

WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizf@cn.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH] Allow cpusets to be configured/built on non-SMP systems
Date: Tue, 03 Mar 2009 16:42:18 +0800	[thread overview]
Message-ID: <49ACED6A.9060002@cn.fujitsu.com> (raw)
In-Reply-To: <6599ad830903030026w2081a72dhf3cac90346b1d806@mail.gmail.com>

Paul Menage wrote:
> On Mon, Mar 2, 2009 at 10:01 PM, Paul Menage <menage@google.com> wrote:
>> On Mon, Mar 2, 2009 at 7:17 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>> +static int generate_sched_domains(struct cpumask **domains,
>>>> +                     struct sched_domain_attr **attributes)
>>>> +{
>>> Except here should "return 0;", otherwise emit a compile warining.
>>>
>> Good catch - the weird thing is that (in my UML build) it doesn't
>> actually generate that warning. Mysterious.
>>
>> I'll resend with the extra return.
> 
> After looking at the sched domains code it's not clear to me that
> returning 0 is necessarily the right thing to do -
> partition_sched_domains() says that 0 is a special case used for
> destroying existing domains? Would returning 1 and setting up a single
> dummy domain be better?
> 

Yes, return 1 seems more reasonable. And if we do this, should we also set
*domains to NULL like this?

static int generate_sched_domains(struct cpumask **domains,
                     struct sched_domain_attr **attributes)
{
	*domains = NULL;
	return 1;
}

because otherwise partition_sched_domains() will access invalid memory:

void partition_sched_domains(int ndoms_new, struct cpumask *doms_new,
			     struct sched_domain_attr *dattr_new)
{
	...
	n = doms_new ? ndoms_new : 0;

	for (i = 0; i < ndoms_cur; i++) {
		for (j = 0; j < n && !new_topology; j++) {
			// *****here*****/
			if (cpumask_equal(&doms_cur[i], &doms_new[j])
			    && dattrs_equal(dattr_cur, i, dattr_new, j))
				goto match1;
		}
	...
	}

> Given that this return code only matters when CONFIG_HOTPLUG_CPU &&
> !CONFIG_SMP it's unlikely to ever be used

That's why I didn't comment on this.

> but I guess it's better to get it right.
> 

But I agree with you. :)

  parent reply	other threads:[~2009-03-03  8:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-03  1:36 [PATCH] Allow cpusets to be configured/built on non-SMP systems Paul Menage
     [not found] ` <20090303013432.11211.18662.stgit-B63HFAS8fGlSzHKm+aFRNNkmqwFzkYv6@public.gmane.org>
2009-03-03  2:01   ` Li Zefan
2009-03-03  3:17   ` Li Zefan
2009-03-03  8:07   ` Ingo Molnar
2009-03-03  2:01 ` Li Zefan
2009-03-03  3:17 ` Li Zefan
     [not found]   ` <49ACA13B.5050106-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-03-03  6:01     ` Paul Menage
2009-03-03  6:01   ` Paul Menage
2009-03-03  6:41     ` Paul Menage
     [not found]     ` <6599ad830903022201s4d2296c7u225e84a77f9f7167-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-03  6:41       ` Paul Menage
2009-03-03  8:26       ` Paul Menage
2009-03-03  8:26     ` Paul Menage
     [not found]       ` <6599ad830903030026w2081a72dhf3cac90346b1d806-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-03  8:42         ` Li Zefan [this message]
2009-03-03  8:42           ` Li Zefan
     [not found]           ` <49ACED6A.9060002-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2009-03-03  8:54             ` Li Zefan
2009-03-03  8:54           ` Li Zefan
2009-03-03  8:07 ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2009-03-03  1:36 Paul Menage
2009-03-03 23:52 Paul Menage
2009-03-03 23:52 Paul Menage

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=49ACED6A.9060002@cn.fujitsu.com \
    --to=lizf-bthxqxjhjhxqfuhtdcdx3a@public.gmane.org \
    --cc=a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
    --cc=mingo-X9Un+BFzKDI@public.gmane.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.