Message-ID: <3D2CB668.8CC739B6@tv-sign.ru>
Date: Thu, 11 Jul 2002 02:34:16 +0400
From: Oleg Nesterov <oleg@tv-sign.ru>
MIME-Version: 1.0
To: linux-kernel@vger.kernel.org
CC: mingo@elte.hu
Subject: Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1665
Lines: 50

Hello.

> > > > And users of __KERNEL_SYSCALLS__ and kernel_thread() should not
> > > > have policy == SCHED_BATCH.
> >
> > well, there's one security consequence here - module loading
> > (request_module()), which spawns a kernel thread must not run as
> > SCHED_BATCH. I think the right solution for that path is to set the
> > policy to SCHED_OTHER upon entry, and restore it to the previous one
> > afterwards - this way the helper thread has SCHED_OTHER priority.
>
> i've solved this problem by making kernel_thread() spawned threads drop
> back to SCHED_NORMAL:

Note that request_module() also does waitpid(). So it's better to change
policy upon entry, as You suggested.

> I believe this is the secure way of doing it - independently of
> SCHED_BATCH - a RT task should not spawn a RT kernel thread 'unwillingly'.

Yes, but this semantic change should be ported to all archs
independently of
low level microoptimizations, for consistency. Rename all definitions to
arch_kernel_thread() ?

Btw, how about this tiny bit of cleanup:

asmlinkage void schedule_userspace(void)
{
    /*
     * Only handle batch tasks that are runnable.
     */
    if (current->policy == SCHED_BATCH &&
        current->state == TASK_RUNNING) {
        runqueue_t *rq = this_rq_lock();
        deactivate_batch_task(current, rq);

        // we can keep irqs disabled:
        spin_unlock(&rq->lock);
    }

    schedule();
}

Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/