public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Ulrich Drepper <drepper@redhat.com>
Subject: Re: [PATCH] make setpriority POSIX compliant; introduce PRIO_THREAD extension
Date: Mon, 01 Sep 2008 17:08:57 +0200	[thread overview]
Message-ID: <1220281737.8426.67.camel@twins> (raw)
In-Reply-To: <1220280138.3866.31.camel@localhost.localdomain>

On Mon, 2008-09-01 at 16:42 +0200, Denys Vlasenko wrote:
> On Mon, 2008-09-01 at 16:12 +0200, Denys Vlasenko wrote:
> > Patch is run tested. I will post test program etc as a reply.
> 
> Looks like Evolution word-wrapped the patch. Let me try again.

Patch looks simple enough, although a few comments below.
Also, I guess the glibc people (Ulrich added to CC) might have an
opinion.

> Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
> --
> vda
> 
> 
> diff --git a/include/linux/resource.h b/include/linux/resource.h
> index aaa423a..f292690 100644
> --- a/include/linux/resource.h
> +++ b/include/linux/resource.h
> @@ -51,6 +51,7 @@ struct rlimit {
>  #define	PRIO_PROCESS	0
>  #define	PRIO_PGRP	1
>  #define	PRIO_USER	2
> +#define	PRIO_THREAD	3
>  
>  /*
>   * Limit the stack by to some sane default: root can always
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 038a7bc..d339c1a 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -142,9 +142,9 @@ asmlinkage long sys_setpriority(int which, int who, int niceval)
>  	struct task_struct *g, *p;
>  	struct user_struct *user;
>  	int error = -EINVAL;
> -	struct pid *pgrp;
> +	struct pid *pgrp, *pid;
>  
> -	if (which > PRIO_USER || which < PRIO_PROCESS)
> +	if (which > PRIO_THREAD || which < PRIO_PROCESS)
>  		goto out;
>  
>  	/* normalize: avoid signed division (rounding problems) */
> @@ -156,7 +156,7 @@ asmlinkage long sys_setpriority(int which, int who, int niceval)
>  
>  	read_lock(&tasklist_lock);
>  	switch (which) {
> -		case PRIO_PROCESS:
> +		case PRIO_THREAD:
>  			if (who)
>  				p = find_task_by_vpid(who);
>  			else
> @@ -164,6 +164,19 @@ asmlinkage long sys_setpriority(int which, int who, int niceval)
>  			if (p)
>  				error = set_one_prio(p, niceval, error);
>  			break;
> +		case PRIO_PROCESS:
> +			if (who)
> +				pid = find_vpid(who);
> +			else {
> +				pid = task_pid(current);
> +				who = current->pid;
> +			}
> +			do_each_pid_thread(pid, PIDTYPE_PID, p) {
> +				if (who == p->pid || who == p->tgid) {
> +					error = set_one_prio(p, niceval, error);
> +				}
> +			} while_each_pid_thread(pid, PIDTYPE_PID, p);

I worry about destroying the return value here, support one thread
fails, but the next succeeds, should we still report failure?

> +			break;
>  		case PRIO_PGRP:
>  			if (who)
>  				pgrp = find_vpid(who);
> @@ -206,14 +219,14 @@ asmlinkage long sys_getpriority(int which, int who)
>  	struct task_struct *g, *p;
>  	struct user_struct *user;
>  	long niceval, retval = -ESRCH;
> -	struct pid *pgrp;
> +	struct pid *pgrp, *pid;
>  
> -	if (which > PRIO_USER || which < PRIO_PROCESS)
> +	if (which > PRIO_THREAD || which < PRIO_PROCESS)
>  		return -EINVAL;
>  
>  	read_lock(&tasklist_lock);
>  	switch (which) {
> -		case PRIO_PROCESS:
> +		case PRIO_THREAD:
>  			if (who)
>  				p = find_task_by_vpid(who);
>  			else
> @@ -224,6 +237,21 @@ asmlinkage long sys_getpriority(int which, int who)
>  					retval = niceval;
>  			}
>  			break;
> +		case PRIO_PROCESS:
> +			if (who)
> +				pid = find_vpid(who);
> +			else {
> +				pid = task_pid(current);
> +				who = current->pid;
> +			}
> +			do_each_pid_thread(pid, PIDTYPE_PID, p) {
> +				if (who == p->pid || who == p->tgid) {
> +					niceval = 20 - task_nice(p);
> +					if (niceval > retval)
> +						retval = niceval;
> +				}
> +			} while_each_pid_thread(pid, PIDTYPE_PID, p);

So we basically return the highest prio amongst the threads?

> +			break;
>  		case PRIO_PGRP:
>  			if (who)
>  				pgrp = find_vpid(who);
> 
> 
> --
> 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/


  reply	other threads:[~2008-09-01 15:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-01 14:12 [PATCH] make setpriority POSIX compliant; introduce PRIO_THREAD extension Denys Vlasenko
2008-09-01 14:17 ` Denys Vlasenko
2008-09-01 14:42 ` Denys Vlasenko
2008-09-01 15:08   ` Peter Zijlstra [this message]
2008-09-01 15:19     ` Peter Zijlstra
2008-09-01 15:20     ` Denys Vlasenko
2008-09-01 17:58     ` Ulrich Drepper
2008-09-09 15:45 ` Michael Kerrisk
2008-09-09 16:42   ` Chris Friesen
2008-09-09 18:45     ` Michael Kerrisk
2008-09-10  9:28   ` Denys Vlasenko
2008-09-10 11:57     ` Michael Kerrisk
2008-09-10 12:08 ` Christoph Hellwig

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=1220281737.8426.67.camel@twins \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=drepper@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=linux-kernel@vger.kernel.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