copy_process: cosmetic ->ioprio tweak

PATCH In review Oleg Nesterov 2 participants 3 messages Aug 20, 2006 – Aug 22, 2006

Subsystems (3)

MM core Scheduler exec and binfmt

lore

Share & tools

lore

Oleg Nesterov

author

2006-08-20 10:29 UTC #0 lore raw

PATCH 1/1 copy_process: cosmetic ->ioprio tweak

copy_process:
// holds tasklist_lock + ->siglock

       /*
        * inherit ioprio
        */
       p->ioprio = current->ioprio;

Why? ->ioprio was already copied in dup_task_struct(). I guess this is needed to ensure that the child can't escape sys_ioprio_set(IOPRIO_WHO_{PGRP,USER}), yes?

In that case we don't need ->siglock held, and the comment should be updated.

Signed-off-by Oleg Nesterov <[email protected]>

kernel/fork.c renamed from kernel/fork.c~1_fork +3 -6

@@ -1138,7 +1138,6 @@ static struct task_struct *copy_process(
 
 	/* Our parent execution domain becomes current domain
 	   These must match for thread signalling to apply */
-	   
 	p->parent_exec_id = p->self_exec_id;
 
 	/* ok, now we should be set up.. */

@@ -1161,6 +1160,9 @@ static struct task_struct *copy_process(
 	/* Need tasklist lock for parent etc handling! */
 	write_lock_irq(&tasklist_lock);
 
+	/* for sys_ioprio_set(IOPRIO_WHO_PGRP) */
+	p->ioprio = current->ioprio;
+
 	/*
 	 * The task hasn't been attached yet, so its cpus_allowed mask will
 	 * not be changed, nor will its assigned CPU.

@@ -1220,11 +1222,6 @@ static struct task_struct *copy_process(
 		}
 	}
 
-	/*
-	 * inherit ioprio
-	 */
-	p->ioprio = current->ioprio;
-
 	if (likely(p->pid)) {
 		add_parent(p);
 		if (unlikely(p->ptrace & PT_PTRACED))

Andrew Morton

2006-08-21 21:32 UTC #1 lore raw

Quoted 8 lines · On Sun, 20 Aug 2006 18:53:21 +0400 Oleg Nesterov <[email protected]> wrote:

copy_process:
// holds tasklist_lock + ->siglock
       /*
        * inherit ioprio
        */
       p->ioprio = current->ioprio;
Why? ->ioprio was already copied in dup_task_struct().

It might just be a thinko.

Quoted 3 lines

I guess this is needed
to ensure that the child can't escape sys_ioprio_set(IOPRIO_WHO_{PGRP,USER}), yes?

How could the child escape that if this assignment was not present?

Quoted 1 line

In that case we don't need ->siglock held, and the comment should be updated.

Surely.

Oleg Nesterov

author

2006-08-22 14:03 UTC #2 lore raw

Quoted 13 lines · Andrew Morton

Quoted 8 lines · On Sun, 20 Aug 2006 18:53:21 +0400 Oleg Nesterov <[email protected]> wrote:
copy_process:
// holds tasklist_lock + ->siglock
       /*
        * inherit ioprio
        */
       p->ioprio = current->ioprio;
Why? ->ioprio was already copied in dup_task_struct().

Quoted 7 lines

It might just be a thinko.
Quoted 3 lines
I guess this is needed
to ensure that the child can't escape sys_ioprio_set(IOPRIO_WHO_{PGRP,USER}), yes?
How could the child escape that if this assignment was not present?

It is possible that sys_ioprio_set(IOPRIO_WHO_PGRP) was called after copy_process() already did dup_task_struct(), but before it takes tasklist_lock. Documentation/block/ioprio.txt doesn't say should ioprio_set() be "atomic" or not. If not, we can kill this line, and (more importantly) drop tasklist_lock in fs/ioprio.c

Oleg.