Re: SCHED_IDLE patch is a source of DoS

Richard Gooch (rgooch@atnf.csiro.au)
Sun, 8 Nov 1998 18:12:49 +1100

Andrea Arcangeli writes:
> It' s trivial to deadlock the filesystem using the sched_idle patch. A
> process in sched_idle policy can be blocked trivially by another CPU eater
> process that runs in SCHED_OTHER. You only need to implement a SCHED_IDLE
> process that play a lot with a hot piece of filesystem, and run at the
> same time the SCHED_OTHER CPU eater process. The buffers used by the
> SCHED_IDLE process will remains locked and no other process will be able
> to access such part of the FS (nor root of course). Tried it here and
> worked (I used `find` as sched_idle process and `primes` as SCHED_OTHER
> process).

I don't think this "deadlock" is actually a real problem. Unless there
is some bug in the FS/VFS, a process should not call schedule() while
it holds some lock. Instead, if it has to wait, it should release the
lock, call schedule() and then re-aquire the lock. That's the friendly
way. The alternative is that we implement priority inversion. Either
way, the problem is not with the SCHED_IDLE patch.

Consider the following scenario:
- SCHED_OTHER process bangs on the FS
- low-priority RT process computes primes or whatever
- high-priority RT process occasionally wakes up, reads a device and
uses the FS.

Just as in your example, the important RT process gets locked out of
the FS if schedule() is called with locks held. So, the problem isn't
with SCHED_IDLE, it's elsewhere.

Regards,

Richard....

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