All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>, David Miller <davem@davemloft.net>,
	Paul Mackerras <paulus@samba.org>,
	Martin Schwidefsky <schwidefsky@googlemail.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Tony Luck <tony.luck@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-next@vger.kernel.org
Subject: Re: [PATCH 1/1] cpumask: force nr_cpumask_bit to NR_CPUS for CPUMASK_OFFSTACK=n
Date: Sat, 13 Dec 2008 20:25:05 +1030	[thread overview]
Message-ID: <200812132025.06514.rusty@rustcorp.com.au> (raw)
In-Reply-To: <49417B99.7090004@sgi.com>

On Friday 12 December 2008 07:14:09 Mike Travis wrote:
> Re: cpumask conversions, or not?
> 
> Rusty Russell wrote:
> > On Tuesday 09 December 2008 21:26:36 Mike Travis wrote:
> >> Rusty Russell wrote:
> >>> Hi all,
> >>>
> >>>    The new cpumask conversions are going well, but unfortunately Stephen
> >>> uncovered a nasty bug via linux-next: the new cpumask operators only go to
> >>> nr_cpumask_bits which can be less than NR_CPUS if NR_CPUS > BITS_PER_LONG.
> >>> The undefined bits confuse the old cpumask operators.  We fixed one case,
> >>> but I am concerned that we will break archs as we convert more core code.
> >> Hi Rusty,
> >>
> >> I think we can avoid this problem if we make cpumask_bits == NR_CPUS iff
> >> CONFIG_CPUMASK_OFFSTACK=n.  This complies with the current cpumask_t
> >> approach and should cause all cpumask operators to always operate on
> >> all cpumask bits.
> > 
> > A very good point.  And it's no worse than the old method.
> > 
> > OK, forget about this for now, no urgent conversions needed :)
> > Rusty.
> 
> This probably should be submitted through linux-next for wider test coverage?

Identical patch already in series.

Thanks,
Rusty.

      parent reply	other threads:[~2008-12-13  9:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200812082136.33212.rusty@rustcorp.com.au>
     [not found] ` <493E4EE4.6010609@sgi.com>
     [not found]   ` <200812101019.42908.rusty@rustcorp.com.au>
2008-12-11 20:44     ` [PATCH 1/1] cpumask: force nr_cpumask_bit to NR_CPUS for CPUMASK_OFFSTACK=n Mike Travis
2008-12-11 23:10       ` Mike Travis
2008-12-13  9:55       ` Rusty Russell [this message]

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=200812132025.06514.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=ralf@linux-mips.org \
    --cc=schwidefsky@googlemail.com \
    --cc=sfr@canb.auug.org.au \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=travis@sgi.com \
    /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.