From: Michael Ellerman <michael@ellerman.id.au>
To: Carl Love <cel@us.ibm.com>
Cc: linuxppc-dev@ozlabs.org, cel@linux.vnet.ibm.com,
cbe-oss-dev@ozlabs.org, oprofile-list@lists.sourceforge.net,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Cbe-oss-dev] [PATCH] Cell OProfile: Incorrect local array size in activate spu profiling function
Date: Sat, 25 Oct 2008 15:39:55 +1100 [thread overview]
Message-ID: <1224909595.16090.5.camel@localhost> (raw)
In-Reply-To: <1224874049.20229.5.camel@carll-linux-desktop>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Fri, 2008-10-24 at 11:47 -0700, Carl Love wrote:
> The size of the pm_signal_local array should be equal to the
> number of SPUs being configured in the call. Currently, the
> array is of size 4 (NR_PHYS_CTRS) but being indexed by a for
> loop from 0 to 7 (NUM_SPUS_PER_NODE).
While you're at it you should change to using ARRAY_SIZE() in the for
loop, and use sizeof in the rtas call - that way you'll only have the
size in one place.
I notice pm_rtas_activate_signals() also allocates a pm_signal_local on
the stack and iterates over it. I take it something guarantees that
count in that routine will not exceed NR_PHYS_CTRS ?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Carl Love <cel@us.ibm.com>
Cc: oprofile-list@lists.sourceforge.net, linuxppc-dev@ozlabs.org,
cel@linux.vnet.ibm.com, cbe-oss-dev@ozlabs.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Cbe-oss-dev] [PATCH] Cell OProfile: Incorrect local array size in activate spu profiling function
Date: Sat, 25 Oct 2008 15:39:55 +1100 [thread overview]
Message-ID: <1224909595.16090.5.camel@localhost> (raw)
In-Reply-To: <1224874049.20229.5.camel@carll-linux-desktop>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Fri, 2008-10-24 at 11:47 -0700, Carl Love wrote:
> The size of the pm_signal_local array should be equal to the
> number of SPUs being configured in the call. Currently, the
> array is of size 4 (NR_PHYS_CTRS) but being indexed by a for
> loop from 0 to 7 (NUM_SPUS_PER_NODE).
While you're at it you should change to using ARRAY_SIZE() in the for
loop, and use sizeof in the rtas call - that way you'll only have the
size in one place.
I notice pm_rtas_activate_signals() also allocates a pm_signal_local on
the stack and iterates over it. I take it something guarantees that
count in that routine will not exceed NR_PHYS_CTRS ?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-10-25 4:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 18:47 [Cbe-oss-dev] [PATCH] Cell OProfile: Incorrect local array size in activate spu profiling function Carl Love
2008-10-25 4:39 ` Michael Ellerman [this message]
2008-10-25 4:39 ` Michael Ellerman
2008-10-28 15:17 ` [UDATED PATCH] " Carl Love
2008-10-28 15:17 ` Carl Love
2008-10-29 0:51 ` Michael Ellerman
2008-10-29 0:51 ` Michael Ellerman
2008-10-29 15:06 ` [UPDATED PATCH VER2] " Carl Love
2008-10-29 15:06 ` Carl Love
2008-10-31 15:14 ` Robert Richter
2008-10-31 15:14 ` Robert Richter
2008-10-27 18:26 ` [Cbe-oss-dev] [PATCH] " Robert Richter
2008-10-27 18:26 ` Robert Richter
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=1224909595.16090.5.camel@localhost \
--to=michael@ellerman.id.au \
--cc=cbe-oss-dev@ozlabs.org \
--cc=cel@linux.vnet.ibm.com \
--cc=cel@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=oprofile-list@lists.sourceforge.net \
/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.