lkml.org 
[lkml]   [1998]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SCHED_IDLE patch is a source of DoS
On Tue, 10 Nov 1998, David Woodhouse wrote:
> andrea@e-mind.com said:
>
> > As you can see with sched_idle pidC (in SCHED_OTHER) can cause pidA
> > (in sched_idle policy) to not run anymore and so also pidB is locked
> > because it' s sleeping on the semaphore hold by pidA.
>
> So surely the fix is to have the SCHED_IDLE process temporarily lose
> its SCHED_IDLE status when it obtains any form of lock.

Aka. priority inheritance, but then in a cheap, effective
and simplified form. I guess even Victor could be satisfied
with a situation like this...

> You could do this by keeping a counter of the number of locks held,
> and a field for the 'intended' scheduling policy. When you increase
> said counter, set the actual scheduling policy to SCHED_OTHER. When
> you decrease the counter to zero, copy the 'intended' policy to the
> actual policy.
>
> This _is_ basically the 'classic' fix mentioned - the process
> holding the lock(s) attains the higher priority for the duration.

Promoting a SCHED_IDLE process to SCHED_OTHER when it
enters the kernel or holds a lock would be a good
solution. It involves removing the special run queue
for SCHED_OTHER processes (sorry Richard), a small
adjustment to goodness() and a check for SCHED_OTHER
in the priority recalculation code.

The goodness() piece will look approximately
like this:

if (p->policy == SCHED_OTHER) {
if (p->lock_depth >= 0)
return 1;
else
return -1;
}

But before doing the Wrong Thing(tm) and ending up
with a defective kernel I'll ask you guys first :)

cheers,

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.749 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site