From: Lennart Poettering <mzxreary@0pointer.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] scheduler: introduce SCHED_RESET_ON_FORK scheduling policy flag, Second try
Date: Fri, 29 May 2009 12:39:25 +0200 [thread overview]
Message-ID: <20090529103924.GA32303@tango.0pointer.de> (raw)
In-Reply-To: <1243589315.23657.210.camel@twins>
On Fri, 29.05.09 11:28, Peter Zijlstra (peterz@infradead.org) wrote:
> > This patch introduces a new flag SCHED_RESET_ON_FORK which can be passed
> > to the kernel via sched_setscheduler(), ORed in the policy parameter. If
> > set this will make sure that when the process forks a) the scheduling
> > priority is reset to DEFAULT_PRIO if it was higher and b) the scheduling
> > policy is reset to SCHED_NORMAL if it was either SCHED_FIFO or SCHED_RR.
>
> Maybe SCHED_OTHER_ON_FORK, or SCHED_DEFAULT_ON_FORK?
Hmm, I think this would be misleading, since it does more than just
reset to SCHED_OTHER. It also resets the nice level.
> > + if (current->sched_reset_on_fork &&
> > + (p->policy == SCHED_FIFO || p->policy == SCHED_RR))
> > + p->policy = SCHED_NORMAL;
> > +
> > + if (current->sched_reset_on_fork &&
> > + (current->normal_prio < DEFAULT_PRIO))
> > + p->prio = DEFAULT_PRIO;
> > + else
> > + p->prio = current->normal_prio;
>
> This bit hurt my brain, what's wrong with:
>
> p->prio = current->normal_prio; /* don't leak boosted prio */
> if (current->sched_reset_on_fork) {
> p->policy = SCHED_NORMAL;
> p->prio = p->normal_prio = p->static_prio = DEFAULT_PRIO;
> }
This would do something very different. i.e. with this suggested code
of yours SCHED_IDLE/SCHED_BATCH would be upgraded to SCHED_OTHER on
fork and a process with a positive nice level would be upgraded to to
nice level 0. My original patch would only downgrade, never upgrade.
It is of course a question what makes more sense here: a logic that
makes sure that only "elevated" scheduling gets reset to normal
scheduling, or one that would reset both 'higher' and 'lower'
scheduling settings to normal.
Given that this is supposed to be a security feature it makes more
sense to me to only 'decrease' scheduling settings, not 'increase'
them. Dunno, what do you think?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
next prev parent reply other threads:[~2009-05-29 10:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 8:38 [PATCH] scheduler: introduce SCHED_RESET_ON_FORK scheduling policy flag, Second try Lennart Poettering
2009-05-29 9:28 ` Peter Zijlstra
2009-05-29 10:39 ` Lennart Poettering [this message]
2009-06-03 14:07 ` Lennart Poettering
2009-06-05 11:54 ` Ingo Molnar
2009-06-05 14:55 ` Lennart Poettering
2009-06-07 10:11 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2009-07-03 12:33 Raz
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=20090529103924.GA32303@tango.0pointer.de \
--to=mzxreary@0pointer.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/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