>- failure prone: the SCHED_IDLE patch just exposed an existing bug
Wrong. And now that I have some time to think about the theorical issue
also the theory exposed by Paul is completly bogus. I don' t care if it' s
been written in all CS books btw.
The point is that everything depends on the locker() and scheduler()
implementations. You can' t generalize the theory if you don' t specify
the real world implementation.
Paul said:
It may be that the deadlock in question will never arise for other
reasons, or that when it does, you don't care. But you *CANNOT* do
what you show above and not have a potential deadlock.
and here I' ll show that it can' t cause a deadlock or/and starvation.
In linux you are perfectly allowed to do something like this:
struct semaphore s = MUTEX;
down(&s);
CRITICAL section
schedule();
CRITICAL section
up(&s);
This will cause only one process to run the critical section. This can' t
generate a deadlock nor starvation:
pid A pid B
------- --------
schedule()
down(s)
CS
schedule()
down(s)
woow it' s locked so schedule() until unlocked
CS
up(s)
got the lock
CS
...
I repeat, this is safe and can' t cause deadlock and/or starvation.
_Only_ if you use the sched_idle instead you can get starvation (and the
starvation can be considered a deadlock for the root that try to recover
from an hacker/cracker malicious action), here I' ll try to show the
sched_idle scenario:
pid A SCHED_IDLE pid B pid C
------- -------- ---------
schedule()
schedule()
down(s)
CS
schedule()
down(s)
woow it' s locked so
schedule() until
unlocked.
loop(;;);
schedule();
schedule();
loop(;;);
schedule();
schedule();
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.
NOTE: This scenario can happen only with the SCHED_IDLE in the kernel.
The RT pid case is safe too (I don' t go into the RT details here because
I have a little time now).
So Paul I suggest you to think a bit more instead of learn at memory
and trust as truth pure theory (as I should do to have a chance to take
the degree).
Andrea Arcangeli
-
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/