linux-kernel - Re: [BUG] 2.6.18-rc6: hda is allready "IN USE" when booting / pi futex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060912215510.GA14878@elte.hu>
Date:	Tue, 12 Sep 2006 23:55:10 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Christian Leber <christian@...er.de>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: Re: [BUG] 2.6.18-rc6: hda is allready "IN USE" when booting / pi futex


* Christian Leber <christian@...er.de> wrote:

> > The b29739f902ee76a05493fb7d2303490fc75364f4 patch is quite large, so i 
> > have created a finegrained, functional splitup of it:
> > 
> >   sched-cleanups.patch
> >   sched-add-task-rq-lock-ops.patch
> >   sched-add-rt-mutex-setprio.patch
> >   sched-pi-lock.patch
> >   sched-add-new-macros.patch
> >   sched-add-normal-prio.patch
> >   sched-use-has-rt-policy.patch
> 
> until here everthing seems to be ok (20 boots)
> 
> >   sched-set-user-nice-fix.patch
> 
> here we go, that one triggers the problem

ok, great. Could you try the patch below ontop of 2.6.18-rc6, does it 
'fix' your bootup too?

the original patch (which this patch reverses) is harmless: it changes 
the priority calculation of reniced tasks from:

	p->prio = NICE_TO_PRIO(nice);

to:

	p->prio = effective_prio(p);

which is a correct change, because NICE_TO_PRIO() gives a 'static' value 
that is not modified by interactivity bonuses/penalties, while 
effective_prio() is the kind of prio every task should get. I.e. 
sys_nice(1) used to (incorrectly) discard the interactive bias of a 
task, until the end of the timeslice.

so i'm afraid you managed to trigger a race in the IDE driver that used 
to be dormant until now... To debug such races the best method is to 
create a 'trace' by printk-ing key points of the port/disk detection 
mechanism. [another option would be to use the latency tracer to do a 
_really_ finegrained trace of the incident - assuming that the bug does 
not go away due to tracing overhead.]

	Ingo

--------------->
Subject: [patch] revert set_user_nice() change
From: Ingo Molnar <mingo@...e.hu>

revert an otherwise correct fix.

this disturbs dynamic priorities (of user and kernel threads),
so it could have an impact on timing-sensitive races.

NOT-Signed-off-by: Ingo Molnar <mingo@...e.hu>

---
 kernel/sched.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -3864,8 +3864,8 @@ void rt_mutex_setprio(struct task_struct
 
 void set_user_nice(struct task_struct *p, long nice)
 {
+	int old_prio, new_prio, delta;
 	struct prio_array *array;
-	int old_prio, delta;
 	unsigned long flags;
 	struct rq *rq;
 
@@ -3892,11 +3892,12 @@ void set_user_nice(struct task_struct *p
 		dec_raw_weighted_load(rq, p);
 	}
 
+	old_prio = p->prio;
+	new_prio = NICE_TO_PRIO(nice);
+	delta = new_prio - old_prio;
 	p->static_prio = NICE_TO_PRIO(nice);
 	set_load_weight(p);
-	old_prio = p->prio;
-	p->prio = effective_prio(p);
-	delta = p->prio - old_prio;
+	p->prio += delta;
 
 	if (array) {
 		enqueue_task(p, array);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/