Bug#44039: nice is not implemented correctly

[Marcus Brinkmann]

Hi,

the implementation of setpriority is broken, as it doesn't allow the super
user to lower the priority of the task *and all threads it contains* below
the current minimal priority of the threads/processor set (I am liberally
mixing POSIX priorities with Mach concepts here).  Also, it reports the
tasks priority, but this is not the acutal or enforced priority (for
example, a normal user can lower the priority of a task to -10, but willg et
an error, and indeed the threads won't have the desired priority).

This needs more work. Of course, we only need to give a consistent view in
the POSIX world if the user doesn't use Mach calls directly.  I suggest that
if task_priority fails, it is called again with the old priority to make
the getpriority report the correct value.

If the user is the superuser, he can request the processor set ports and use
that to set the threads max (for POSIX: min) priority.

All this ignores the max priority of processor sets, this is something I
haven't checked yet.  It seems to me we should set the processor sets max
priority to the highest value by default.

Actually, I haven't really spent too much thought on this, maybe someone can
investigate the remaining details and develop patches for glibc (and maybe
proc, which would set the processor sets priorities, I think).

If the Mach picture is not good enough, we might save the priority of a
task/thread in proc.  From a first glance, I don't think that it is needed.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de