Re: Coreutils nice sanity check failure

[Soeren D. Schulze]

> At Sun, 17 Apr 2005 00:05:53 +0200,
> Soeren D. Schulze wrote:
> > after running the test script myself and thinking I a bit, I found the
> > reason why it fails:
> > 
> > Coreutils nice expects a priority range from 0 to 39 (mapped to -20..19
> > for the user) but Mach only provides 0..31.
> 
> I think you mean: the coreutils test suite assumes that if you
> successfully set a process's nice value then the value you get back
> from calling getpriority will be the value you set.  Reading POSIX,
> this is a fairly reasonable expectation which we don't meet.
> 
> Given this problem, what should we do if anything at all?  If the only
> program which relies on this behavior is the core utils' test suite
> then we could ignore it.  I doubt other programs do as calling nice
> and then getpriority is not atomic.  As such, between the two calls an
> external process could have reniced the process.
> 
> > My proposal is to change the mapping policy and map 0..39 to 0..31
> > discarding the 8 lowest possible priorites.  Priorities below the
> > default priority (0 to the user) do not work properly anyway right now.
> > Once they work, it will not hurt too badly if the range is only partly
> > accessible.
> 
> What a nice value means is implementation defined.  Thus any POSIX
> program (without knowledge of the Hurd) cannot rely on it to have any
> particular meaning.  As such, we can change the meaning whenever we
> want without affecting POSIX programs (i.e. it would affect only those
> that rely on the Hurd's implementation of POSIX).
> 
> But your proposal only fixes a corner case: you still have the problem
> that for some priority values, getpriority will return a difference
> nice value than which was supplied to nice.

It will not.  It will return an error where an error is returned right
now.  It will require some deeper improvements in the Hurd permission
handling to fix this:  The respective server has to own the master port
and apply it respectively when the renice application comes from root.

> > On IRC, Neal had come up with another proposal for a change in the libc
> > POSIX layer that uses a kind of caching, but I had not really
> > understood.
> > Neal, could you state your idea here to everyone?
> 
> My suggestion was to save the nice value and the corresponding Mach
> priority when nice or setpriority is called.  Then when getpriority is
> called if the current Mach priority is the same as the saved Mach
> priority, return the saved nice value.

This would work as long as you only work in a single process.  As you
stated, there will be a problem if other processes renice the process
meanwhile and our code does not know about it.  Moreover, the testsuite
does it like this:

nice -n 11 nice
=> 11 (expected)

As we have several processes, it will not work to cache the value in
libc code.

> Frankly, I don't know if any fix is generally useful as the problem
> seems negligible.

Well, Marcus had asked me to fix it, so I assume that it caused trouble
somewhere.  At FOSDEM, Michael moreover explained that something was
preventing coreutils from building properly under the Hurd and I think
that was this.


However, I have a dpatch (forgive me) here that works:

--- snip ---
#! /bin/sh -e

# All lines beginning with `# DP:' are a description of the patch.
# DP: Map nice values proportionally to Mach priorities.

if [ $# -ne 2 ]; then
    echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
    exit 1
fi
case "$1" in
    -patch) patch -d "$2" -f --no-backup-if-mismatch -p2 < $0;;
    -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p2 < $0;;
    *)
        echo >&2 "`basename $0`: script expects -patch|-unpatch as
argument"
        exit 1
esac
exit 0

diff -Naur build-tree/glibc-2.3.2/hurd/hurd/resource.h
build-tree.orig/glibc-2.3.2/hurd/hurd/resource.h
--- build-tree/glibc-2.3.2/hurd/hurd/resource.h 2005-04-23
20:29:08.525077368 +0200
+++ build-tree.orig/glibc-2.3.2/hurd/hurd/resource.h    2001-07-07
21:20:57.000000000 +0200
@@ -43,8 +43,8 @@

 /* Convert between Mach priority values and the priority
    values used by getpriority, setpriority, and nice.  */
+#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 12)
+#define NICE_TO_MACH_PRIORITY(nice) (12 + (nice))
-#define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12))
-#define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2))



--- snap ---

If you like, I can also upload binaries.
Compiling took 13 hours for me. :-)

Sören