Implement THREAD_PRIORITY_TIME_CRITICAL

[Jan Zerebecki]

On Sun, Apr 02, 2006 at 08:57:28PM +0200, Alexandre Julliard wrote:
> Mike Hearn <mike at plan99.net> writes:
> 
> > I'm not sure it counts as easy. At least Fedora and SUSE already have an
> > LSM module loaded, for SELinux and AppArmor respectively. Some solution
> > based on making wineserver suid root might work but I didn't get anywhere
> > when I played with that.
> 
> You're missing the point. The problem is not "how can we bypass system
> protections?", the problem is "how can we achieve what we want without
> having to bypass anything?". These things are restricted to root
> precisely because they can screw up the system, and that's not a power
> we want to give to random Win32 apps. What we need is a mechanism that
> is safe enough to be enabled by default on all systems, without
> requiring suid root or similar hacks.

It does work without any special privileges on a kernel with the
SCHED_ISO patch (included in -ck), because it can transparently
exchanges SCHED_FIFO/RT with SCHED_ISO. A thread with SCHED_ISO
can not outstarve the system because when using over 80%
(default) cpu it's priority handling is revoked.

It also works fine on any system on that wine got the permission
for SCHED_FIFO/RT, because when an App. behaves wrong (it's
thread outstarves the rest of the system) a user can hit the
magic-sysrq key combo for "disable SCHED_FIFO/RT for running
processes". (I'm not sure if that magic-sysrq-key is available in
mainline yet or only in -ck. Also note that on windows a base
priority this high is able to outstarve the the system.)

About the "SCHED_FIFO/RT needs root"-problem: It does not. I
think since Linux kernel 2.6.12 there is a new resource limit for
realtime (think: ulimit). There are various ways to give wine an
increased limit. Among them a suid helper called set_rlimits and
using a up to date version of pam (newer version can set this
limit). This is perhaps less critical than the process limit,
which is I think per default on a Debian unlimited (think: fork
bomb). This also seems to be _the_ solution for this problem in
the (audio-)linux community.

So trying to use SCHED_FIFO and if it fails trying to use
SCHED_ISO is safe for every system. (Not sure if that is the best
order. A more complete patch would probably also take care of
most of the other base priorities windows has by using
SCHED_IDLE... SCHED_WINE anyone?) If the user chose to permit
SCHED_FIFO/RT he is probably willing to risk needing to hit that
magic-sysrq-key to disable it again. If he does not want to risk
that he can use a kernel with SCHED_ISO.

Does this fit your requirement?



Jan