All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: linuxppc-dev@ozlabs.org, pj@sgi.com, ntl@pobox.com, ak@suse.com,
	linux-kernel@vger.kernel.org
Subject: Re: Fw: 2.6.16 crashes when running numastat on p575
Date: Mon, 3 Apr 2006 14:18:34 -0700	[thread overview]
Message-ID: <20060403141834.31cd9dea.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0604031104110.20903@schroedinger.engr.sgi.com>

Christoph Lameter <clameter@sgi.com> wrote:
>
> On Mon, 3 Apr 2006, Nathan Lynch wrote:
> 
> > > There are many other for_each_*_cpu loops in the kernel that do not have 
> > > any of the instrumentation you suggest. I suggest you come up with a 
> > > general solution and then go through all of them and fix this. Please be 
> > > aware that many of these loops are performance critical.
> > 
> > But this one isn't, right?
> 
> Right. One could use more expensive processing here.

Hopefully none of the for_each_foo() loops are performance-critical - those
things are expensive.

> > And I'm afraid there's a misunderstanding here -- only
> > for_each_online_cpu (or accessing the cpu online map in general) has
> > such restrictions -- for_each_possible_cpu doesn't require any locking
> > or preempt tricks since cpu_possible_map must not change after boot.

for_each_present_cpu() presumably has the same problems.

> Correct. We may want to audit the kernel and check that each 
> for_each_possible_cpu or for_each_cpu is really correct.

A fair bit of that has been happening in recent weeks.

But yes, we should be protecting these things with rcu_read_lock() if
possible, lock_cpu_hotplug() otherwise.

(rcu_read_lock() might not be the appropriate name for this operation -
maybe it should be an open-coded preempt_disable().  Or some other suitably
named alias; dunno).

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: ntl@pobox.com, pj@sgi.com, linuxppc-dev@ozlabs.org, ak@suse.com,
	linux-kernel@vger.kernel.org
Subject: Re: Fw: 2.6.16 crashes when running numastat on p575
Date: Mon, 3 Apr 2006 14:18:34 -0700	[thread overview]
Message-ID: <20060403141834.31cd9dea.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0604031104110.20903@schroedinger.engr.sgi.com>

Christoph Lameter <clameter@sgi.com> wrote:
>
> On Mon, 3 Apr 2006, Nathan Lynch wrote:
> 
> > > There are many other for_each_*_cpu loops in the kernel that do not have 
> > > any of the instrumentation you suggest. I suggest you come up with a 
> > > general solution and then go through all of them and fix this. Please be 
> > > aware that many of these loops are performance critical.
> > 
> > But this one isn't, right?
> 
> Right. One could use more expensive processing here.

Hopefully none of the for_each_foo() loops are performance-critical - those
things are expensive.

> > And I'm afraid there's a misunderstanding here -- only
> > for_each_online_cpu (or accessing the cpu online map in general) has
> > such restrictions -- for_each_possible_cpu doesn't require any locking
> > or preempt tricks since cpu_possible_map must not change after boot.

for_each_present_cpu() presumably has the same problems.

> Correct. We may want to audit the kernel and check that each 
> for_each_possible_cpu or for_each_cpu is really correct.

A fair bit of that has been happening in recent weeks.

But yes, we should be protecting these things with rcu_read_lock() if
possible, lock_cpu_hotplug() otherwise.

(rcu_read_lock() might not be the appropriate name for this operation -
maybe it should be an open-coded preempt_disable().  Or some other suitably
named alias; dunno).


  reply	other threads:[~2006-04-03 21:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060402213216.2e61b74e.akpm@osdl.org>
2006-04-03  5:12 ` Fw: 2.6.16 crashes when running numastat on p575 Christoph Lameter
2006-04-03  5:12   ` Christoph Lameter
2006-04-03  5:15   ` Paul Jackson
2006-04-03  5:15     ` Paul Jackson
2006-04-03  5:25     ` Christoph Lameter
2006-04-03  5:25       ` Christoph Lameter
2006-04-03  6:43       ` Paul Jackson
2006-04-03  6:43         ` Paul Jackson
2006-04-03 14:10       ` Nathan Lynch
2006-04-03 14:10         ` Nathan Lynch
2006-04-03 17:42         ` Christoph Lameter
2006-04-03 17:42           ` Christoph Lameter
2006-04-03 18:01           ` Nathan Lynch
2006-04-03 18:01             ` Nathan Lynch
2006-04-03 18:08             ` Christoph Lameter
2006-04-03 18:08               ` Christoph Lameter
2006-04-03 21:18               ` Andrew Morton [this message]
2006-04-03 21:18                 ` Andrew Morton
2006-04-04  0:25               ` Paul Jackson
2006-04-04  0:25                 ` Paul Jackson
2006-04-03 11:49     ` Andi Kleen
2006-04-03 11:49       ` Andi Kleen
2006-04-03 14:18       ` Nathan Lynch
2006-04-03 14:18         ` Nathan Lynch
2006-04-03  8:09   ` Sonny Rao
2006-04-03  8:09     ` Sonny Rao

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=20060403141834.31cd9dea.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ak@suse.com \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=ntl@pobox.com \
    --cc=pj@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.