[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH

    > > > > 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:


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.027 / U:101.488 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site