[Cbe-oss-dev] Context switch question

Luke Browning lukebr at linux.vnet.ibm.com
Wed Sep 12 00:52:42 EST 2007


See questions below after //

Thx,
Luke

int spu_process_callback(struct spu_context *ctx)
{
        struct spu_syscall_block s;
        u32 ls_pointer, npc;
        void __iomem *ls;
        long spu_ret;
        int ret;

        /* get syscall block from local store */
        npc = ctx->ops->npc_read(ctx) & ~3;
        ls = (void __iomem *)ctx->ops->get_ls(ctx);
        ls_pointer = in_be32(ls + npc);
        if (ls_pointer > (LS_SIZE - sizeof(s)))
                return -EFAULT;
        memcpy_fromio(&s, ls + ls_pointer, sizeof(s));

// is this a potential deadlock during context switch since 
// problem state mappings are removed and context lock is 
// held by caller?  We would fault holding the lock and
// the lock needs to be taken to resolve the fault. 

        /* do actual syscall without pinning the spu */
        ret = 0;
        spu_ret = -ENOSYS;
        npc += 4;

        if (s.nr_ret < __NR_syscalls) {
                spu_release(ctx);
                /* do actual system call from here */
                spu_ret = spu_sys_callback(&s);
                if (spu_ret <= -ERESTARTSYS) {
                        ret = spu_handle_restartsys(ctx, &spu_ret, &npc);
                }
                spu_acquire(ctx);
                if (ret == -ERESTARTSYS)
                        return ret;
        }

        /* write result, jump over indirect pointer */
        memcpy_toio(ls + ls_pointer, &spu_ret, sizeof(spu_ret));
// same here?

        ctx->ops->npc_write(ctx, npc);
        ctx->ops->runcntl_write(ctx, SPU_RUNCNTL_RUNNABLE);

// I think the npc_write and runcntl_write are OK, because the lock is held
// meaning we are not in spu_save() or spu_restore().  However, we may be 
// modifying the saved state of a context. 

        return ret;
}





More information about the cbe-oss-dev mailing list