public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: cbe-oss-dev@ozlabs.org, michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [Cbe-oss-dev] [PATCH 14/22] spufs: use SPU master control to	prevent wild	SPU execution
Date: Mon, 5 Mar 2007 02:02:59 +0100	[thread overview]
Message-ID: <200703050202.59596.arnd@arndb.de> (raw)
In-Reply-To: <1172830438.16533.6.camel@concordia.ozlabs.ibm.com>

On Friday 02 March 2007, Michael Ellerman wrote:
> There's also the error case for spu_run_init() which skips the master
> stop. I guess that's ok because we've only set the master control in the
> backing store, and the only way that will ever get propagated to an
> actual spu is by coming back thorough spufs_run_spu().

Hmm, the correct way would be to switch off the master control in there,
afaics. Fixing it only in spu_run_init would mean that we also handle
the case of spu_reacquire_runnable along with it.

> What originally caught my eye on this was the output from xmon. When we
> drop into xmon with no spu programs running and stop the spus, it
> reports that they _all_ have the master run enabled,

That looks right, there is no problem to have master control enabled,
as long as user space can't access the spu through a context that is
bound to it.

> and some of them 
> have the runcntl enabled (those that have had spu programs run on them
> since boot it seems).

While this sounds wrong. Maybe the runcntl is active on those that have
_not_ run since boot, which would make more sense. We should investigate
this.

> It looks like the save/restore code sets the master bit in several
> places, but never sets/clears the runcntl, which seems bogus to me.
> 
> So when we leave spufs_spu_run we do the master stop call:
> 
> spu_mfc_sr1_set: spu: c00000007ffdfc80 (15) sr1: 0x1b runcntl: 0x1
> Call Trace:
> [C00000000196BAA0] [C00000000000F920] .show_stack+0x68/0x1b0 (unreliable)
> [C00000000196BB40] [D0000000001475C0] .spu_hw_master_stop+0xa8/0x170 [spufs]
> [C00000000196BBE0] [D000000000148598] .spufs_run_spu+0x5ec/0x770 [spufs]
> [C00000000196BCC0] [D000000000144BA0] .do_spu_run+0xb4/0x180 [spufs]
> [C00000000196BD80] [C00000000003905C] .sys_spu_run+0xb0/0x108
> [C00000000196BE30] [C000000000008634] syscall_exit+0x0/0x40
> 
> 
> But then the save/restore code sets it back on?

Right, the context save code needs to enable master control in order to
run on the spu. However, that should be after all mappings to user space
have been discarded.

	Arnd <><

  reply	other threads:[~2007-03-05  1:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-20 17:44 [PATCH 00/22] Cell patches for 2.6.20 Arnd Bergmann
2006-11-20 17:44 ` [PATCH 01/22] powerpc: convert idle_loop to use hard_irq_disable() Arnd Bergmann
2006-11-20 21:59   ` Paul Mackerras
2006-11-21  0:53   ` Benjamin Herrenschmidt
2006-11-21 10:14     ` Arnd Bergmann
2006-11-21 16:58       ` Olof Johansson
2006-11-20 17:44 ` [PATCH 02/22] powerpc: change ppc_rtas declaration to weak Arnd Bergmann
2006-11-20 17:44 ` [PATCH 03/22] spufs: Change %llx to 0x%llx Arnd Bergmann
2006-11-20 17:44 ` [PATCH 04/22] spufs: add /lslr, /dma_info and /proxydma files Arnd Bergmann
2006-11-20 17:44 ` [PATCH 05/22] spufs: Remove /spu_tag_mask file Arnd Bergmann
2006-11-20 17:45 ` [PATCH 06/22] spufs: implement /mbox_info, /ibox_info, and /wbox_info Arnd Bergmann
2006-11-20 17:45 ` [PATCH 07/22] spufs: read from signal files only if data is there Arnd Bergmann
2006-11-20 17:45 ` [PATCH 08/22] spufs: replace spu.nid with spu.node Arnd Bergmann
2006-11-20 17:45 ` [PATCH 09/22] spufs: return correct event for data storage interrupt Arnd Bergmann
2006-11-20 17:45 ` [PATCH 10/22] spufs: fix missing stop-and-signal Arnd Bergmann
2006-11-20 17:45 ` [PATCH 11/22] spufs: avoid user-triggered oops in ptrace Arnd Bergmann
2006-11-20 17:45 ` [PATCH 12/22] spufs: always map local store non-guarded Arnd Bergmann
2006-11-20 17:45 ` [PATCH 13/22] spufs: fix return value of spufs_mfc_write Arnd Bergmann
2006-11-20 17:45 ` [PATCH 14/22] spufs: use SPU master control to prevent wild SPU execution Arnd Bergmann
2007-03-01  6:18   ` Michael Ellerman
2007-03-01 13:50     ` [Cbe-oss-dev] " Arnd Bergmann
2007-03-02 10:13       ` Michael Ellerman
2007-03-05  1:02         ` Arnd Bergmann [this message]
2007-03-07  8:58           ` Michael Ellerman
2006-11-20 17:45 ` [PATCH 15/22] spufs: Add runcntrl read accessors Arnd Bergmann
2006-11-20 17:45 ` [PATCH 16/22] spufs: load isolation kernel from spu_run Arnd Bergmann
2006-11-20 17:45 ` [PATCH 17/22] coredump: Add SPU elf notes to coredump Arnd Bergmann
2006-11-21  5:38   ` Michael Ellerman
2006-11-20 17:45 ` [PATCH 18/22] cell: add symbol exports for oprofile Arnd Bergmann
2006-11-20 17:45 ` [PATCH 19/22] cell: PMU register macros Arnd Bergmann
2006-11-20 17:45 ` [PATCH 20/22] cell: Move PMU-related stuff to include/asm-powerpc/cell-pmu.h Arnd Bergmann
2006-11-20 17:45 ` [PATCH 21/22] cell: add routines for managing PMU interrupts Arnd Bergmann
2006-11-20 17:45 ` [PATCH 22/22] cell: add oprofile support Arnd Bergmann

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=200703050202.59596.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox