From: Chris Wright <chrisw@osdl.org>
To: Matt Mackall <mpm@selenic.com>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>,
mingo@elte.hu, linux-kernel@vger.kernel.org,
michael.kerrisk@gmx.net, akpm@osdl.org, chrisw@osdl.org
Subject: Re: Broke nice range for RLIMIT NICE
Date: Fri, 29 Jul 2005 13:18:36 -0700 [thread overview]
Message-ID: <20050729201836.GH19052@shell0.pdx.osdl.net> (raw)
In-Reply-To: <20050729061318.GD7425@waste.org>
* Matt Mackall (mpm@selenic.com) wrote:
> On Thu, Jul 28, 2005 at 05:04:24PM +0200, Michael Kerrisk wrote:
> > In other words, there is an off-by-one mismatch between
> > these two interfaces: RLIMIT_NICE is expecting to deal
> > with values in the range 39..0, while [gs]etpriority()
> > works with the range 40..1.
> >
> > I suppose that glibc could paper over the cracks here in
> > a wrapper for getrlimit(), but it seems more sensible
> > to make RLIMIT_NICE consistent with [gs]etpriority() --
> > i.e., change the RLIMIT_NICE interface in 2.6.13 before it
> > sees wide use in userland. What do you think?
>
> Well, it's easy enough to do, but some thought has to be given to the
> corner cases. Specifically, does this do the right thing when the
> rlimit is set to zero? I think it does, as the nice range is nicely
> bound here:
Agreed, it should be fine. The default rlimit of zero is just as
effective with the adjust by one semantics.
> nice = PRIO_TO_NICE(current->static_prio) + increment;
> if (nice < -20)
> nice = -20;
> if (nice > 19)
> nice = 19;
>
> if (increment < 0 && !can_nice(current, nice))
> return -EPERM;
>
> And we allow task to do negative increment. Chris?
Yes, if the rlimit is permissive enough. So, for example with default,
there's no chance for any negative increment. With rlimit of 1 (or 2
with adjust-by-one) you could nice down to 19, then nice back up to a
max of 18.
> The other downside is, this obviously changes any existing configs
> actually using this by one nice level..
Yes, this requires updated pam patch. Otherwise,
ACK
thanks,
-chris
> Index: l/kernel/sched.c
> ===================================================================
> --- l.orig/kernel/sched.c 2005-06-22 17:55:14.000000000 -0700
> +++ l/kernel/sched.c 2005-07-28 22:55:54.000000000 -0700
> @@ -3231,8 +3231,8 @@ EXPORT_SYMBOL(set_user_nice);
> */
> int can_nice(const task_t *p, const int nice)
> {
> - /* convert nice value [19,-20] to rlimit style value [0,39] */
> - int nice_rlim = 19 - nice;
> + /* convert nice value [19,-20] to rlimit style value [1,40] */
> + int nice_rlim = 20 - nice;
> return (nice_rlim <= p->signal->rlim[RLIMIT_NICE].rlim_cur ||
> capable(CAP_SYS_NICE));
> }
next prev parent reply other threads:[~2005-07-29 20:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-28 15:04 Broke nice range for RLIMIT NICE Michael Kerrisk
2005-07-28 17:43 ` Andrew Morton
2005-07-29 11:29 ` [PATCH] MAINTAINERS record -- MAN-PAGES Michael Kerrisk
2005-07-29 6:13 ` Broke nice range for RLIMIT NICE Matt Mackall
2005-07-29 8:38 ` Ingo Molnar
2005-07-29 10:42 ` Michael Kerrisk
2005-07-29 14:50 ` Nix
2005-07-29 15:14 ` Michael Kerrisk
2005-07-29 20:57 ` Nix
2005-07-29 10:40 ` Michael Kerrisk
2005-07-29 20:18 ` Chris Wright [this message]
2005-07-29 20:51 ` Chris Wright
2005-07-29 21:02 ` Lee Revell
2005-07-29 21:07 ` Chris Wright
2005-08-15 20:13 ` [PATCH] Fix " Matt Mackall
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=20050729201836.GH19052@shell0.pdx.osdl.net \
--to=chrisw@osdl.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.kerrisk@gmx.net \
--cc=mingo@elte.hu \
--cc=mpm@selenic.com \
--cc=mtk-manpages@gmx.net \
/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