Messages in this thread | | | Date | Thu, 11 Jul 2002 02:34:16 +0400 | From | Oleg Nesterov <> | Subject | Re: [patch] sched-2.5.24-D3, batch/idle priority scheduling, SCHED_BATCH |
| |
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/
| |