Implement THREAD_PRIORITY_TIME_CRITICAL

[Segin]

Jan Zerebecki wrote:

>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
>
>
>
>
>  
>
oh-la-la, very nice! This is a great idea, and we should work on it. And 
hopefully the SCHED_ISO patch get into the main kernel tree soon, cause 
the hourly openssl, or vmware, or running 7 simultaneous compiles that 
literally give the system the slashdot effect really get on my nerves....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-devel/attachments/20060402/946e14dd/attachment-0001.htm