Re: [PATCH] limits on SCHED_FIFO tasks

[Andrew Morton]

george anzinger <[e-mail]> wrote:
>
> If the issue is regaining control after some RT task goes into a loop, 
> the way this is usually done is to keep a session around with a higher 
> priority.  Using this concept, one might provide tools that, from 
> userland, insure that such a session exists prior to launching the 
> "suspect" code.  I fail to see the need for this sort of code in the 
> kernel.

That works, until your shell calls ext3_mark_inode_dirty(), which blocks on
kjournald activity.  kjournald is SCHED_OTHER, and never runs...