lkml.org 
[lkml]   [1998]   [Nov]   [11]   [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, Rik van Riel wrote:

> > This _is_ basically the 'classic' fix mentioned - the process
> > holding the lock(s) attains the higher priority for the duration.

the problem is that there is no easy central way to determine wether a
process 'holds some valuable resource'.

> The goodness() piece will look approximately
> like this:
>
> if (p->policy == SCHED_OTHER) {
> if (p->lock_depth >= 0)
> return 1;
> else
> return -1;
> }

lock_depth is something very different ... It's not even a lock.
(lock_depth >= 0 has little or no meaning at all to any other process if
this process is not running) There are many different kinds of locks
within Linux, and there are many informal (nonexplicit) ways of locking
too. (set a static local flag if not set yet, reschedule if already set)

if we want to do this, it's a major overhaul, definitely a 2.3 item. (just
think read-write semaphores ... we do not have them currently, but it
would be very hard and ineffective to make them priority-aware)

-- mingo


-
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.323 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site