Re: SCHED_IDLE patch is a source of DoS

David Woodhouse (David.Woodhouse@mvhi.com)
Tue, 10 Nov 1998 11:24:21 +0000

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.

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.

---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.

-
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/