[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#286825: glibc: nice() should set errno=EPERM not EACCES on error



On Fri, Dec 24, 2004 at 04:51:30PM +0900, GOTO Masanori wrote:
> At Wed, 22 Dec 2004 14:12:04 +0000,
> Gerrit Pape wrote:
> > Hi, according to the man page and
> > http://www.opengroup.org/onlinepubs/009695399/functions/nice.html
> > nice() should set errno=EPERM in case the incr argument is negative and
> > the calling process does not have appropriate privileges.

> It's like old BSD vs SysV question.  This behavior written in SUS is
> SysV derived.  However, BSD returns EACCES like glibc.  Look at info
> libc, it describes as follows:
> 
>  - Function: int nice (int INCREMENT)
>      Increment the nice value of the calling process by INCREMENT.  The
>      return value is the new nice value on success, and `-1' on
>      failure.  In the case of failure, `errno' will be set to the same
>      values as for `setpriority'.

I stumbled across this because the diet libc and also the uclibc use the
Linux kernel's implementation (on most archs) which sets errno=EPERM

./kernel/sched.c:
asmlinkage long sys_nice(int increment)
{
        int retval;
        long nice;

        /*
         *      Setpriority might change our priority at the same
         *      moment.
         *      We don't have to worry. Conceptually one call occurs
         *      first
         *      and we have a single winner.
         */
        if (increment < 0) {
                if (!capable(CAP_SYS_NICE))
                        return -EPERM;
                if (increment < -40)
                        increment = -40;
        }
[...]

The dietlibc showed different behavior on ia64 where __NR_nice is not
defined; I fixed this for consistency

#ifndef __NR_nice
int nice(int i) {
  if (setpriority(PRIO_PROCESS,0,getpriority(PRIO_PROCESS,0)+i) == -1) {
    errno=EPERM;
    return -1;
  }
  return getpriority(PRIO_PROCESS,0);
}
#endif

It bothered me that glibc's implementation and the Linux kernel's
disagree.

> I'll close this report unless you have other opinion.

Fine with me, it would be nice to have consistent behavior of the kernel
and the different libcs in Debian though.

Regards, Gerrit.



Reply to: