[Top][All Lists]

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

Re: Another test-dup3 assertion with the new kernel

From: Eric Blake
Subject: Re: Another test-dup3 assertion with the new kernel
Date: Wed, 10 Oct 2012 11:05:54 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

On 10/10/2012 07:23 AM, Richard W.M. Jones wrote:
> Fixing the other two kernel bugs, leaves me with two further
> assertions.  This time I'm not so sure that this is a kernel bug.
>       /* The destination must be valid.  */
>       errno = 0;
>       ASSERT (dup3 (fd, -2, o_flags) == -1);
>       ASSERT (errno == EBADF);                  <--- here

This one sounds wrong in the kernel.

>       errno = 0;
>       ASSERT (dup3 (fd, 10000000, o_flags) == -1);
>       ASSERT (errno == EBADF);                  <--- and here

And for this one, EMFILE makes sense only IF the kernel can support
OPEN_MAX of 10000000 (but it doesn't).

> In fact the new implementation of dup3 returns EMFILE (Too many open
> files) because of the following test:
>       if (newfd >= rlimit(RLIMIT_NOFILE))
>               return -EMFILE;
> combined with the fact that newfd is declared inside the kernel as an
> unsigned int (both fd params have been declared as unsigned int at
> least as far back as 2008 when the dup3 call was first added).

fds have always been signed in userland.  Treating an fd as unsigned
gives the wrong error in this case, because userland cannot request an
fd that large.  The POSIX wording for dup3 says that it should be
identical to dup2 in most cases, and the wording for dup2 is explicit:

[EBADF] The fildes argument is not a valid open file descriptor or the
argument fildes2 is negative or greater than or equal to {OPEN_MAX}.

No room for EMFILE when fildes2 treated as unsigned is huge, or even
when fildes2 is 10000000 but the kernel does not support an OPEN_MAX
that large.

> The change from EBADF to EMFILE seems to be intentional (kernel commit
> 4e1e018ecc6f7bfd10fc75b3ff9715cc8164e0a2).

Maybe intentional, but sounds wrong to me.

> I have no opinion on whether the kernel or gnulib is wrong here.

I'm arguing that it a kernel bug; how does dup2 behave on the same test?

Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]