Messages in this thread | | | Date | Tue, 10 Nov 1998 19:39:42 +0100 (CET) | From | Rik van Riel <> | Subject | Re: 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/
| |