NetBSD Problem Report #45148

From jruohone@gmail.com  Fri Jul 15 08:28:17 2011
Return-Path: <jruohone@gmail.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 5A84C63BEBD
	for <gnats-bugs@gnats.netbsd.org>; Fri, 15 Jul 2011 08:28:17 +0000 (UTC)
Message-Id: <20110715082811.7EFFD56C5@marx.bitnet>
Date: Fri, 15 Jul 2011 11:28:11 +0300 (EEST)
From: Jukka Ruohonen <jruohonen@iki.fi>
Sender: a b <jruohone@gmail.com>
Reply-To: jruohonen@iki.fi
To: gnats-bugs@gnats.NetBSD.org
Subject: dup2(3) and dup3(3) should support EINVAL
X-Send-Pr-Version: 3.95

>Number:         45148
>Category:       lib
>Synopsis:       dup2(3) and dup3(3) should support EINVAL
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 15 08:30:00 +0000 2011
>Closed-Date:    Sat Jul 16 14:30:20 +0000 2011
>Last-Modified:  Thu Jul 21 03:35:01 +0000 2011
>Originator:     Jukka Ruohonen
>Release:        NetBSD 5.1_STABLE
>Organization:
none
>Environment:
>Description:

In Linux the dup3(3) call fails with EINVAL (a) if the specified flags
contain an invalid value or (b) if "newfd" equals "oldfd". The case (b)
applies also to dup2(3).

>How-To-Repeat:

>Fix:

Make these fail with EINVAL.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Fri, 15 Jul 2011 10:40:09 +0200

 On Fri, Jul 15, 2011 at 08:30:00AM +0000, Jukka Ruohonen wrote:
 > In Linux the dup3(3) call fails with EINVAL (a) if the specified flags
 > contain an invalid value or (b) if "newfd" equals "oldfd". The case (b)
 > applies also to dup2(3).

 I don't think so:

 the open group base spec issue 7 says:

   If fildes2 is already a valid open file descriptor, it shall be closed
   first, unless fildes is equal to fildes2 in which case dup2() shall
   return fildes2 without closing it.

 Our dup2(3) man page has weaker words, but to the same effect.

 Martin

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: netbsd-bugs@NetBSD.org, Martin Husemann <martin@duskware.de>
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Fri, 15 Jul 2011 11:49:14 +0300

 On Fri, Jul 15, 2011 at 08:45:01AM +0000, Martin Husemann wrote:
 >  On Fri, Jul 15, 2011 at 08:30:00AM +0000, Jukka Ruohonen wrote:
 >  > In Linux the dup3(3) call fails with EINVAL (a) if the specified flags
 >  > contain an invalid value or (b) if "newfd" equals "oldfd". The case (b)
 >  > applies also to dup2(3).
 >  
 >  I don't think so:
 >  
 >  the open group base spec issue 7 says:
 >  
 >    If fildes2 is already a valid open file descriptor, it shall be closed
 >    first, unless fildes is equal to fildes2 in which case dup2() shall
 >    return fildes2 without closing it.
 >  
 >  Our dup2(3) man page has weaker words, but to the same effect.

 Yes, however dup3(2) is not standardized, AFAIR, leaving the behavior
 "undefined". And the case (a) should still apply.

 - Jukka.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Fri, 15 Jul 2011 10:50:44 +0200

 On Fri, Jul 15, 2011 at 11:49:14AM +0300, Jukka Ruohonen wrote:
 > Yes, however dup3(2) is not standardized, AFAIR, leaving the behavior
 > "undefined". And the case (a) should still apply.

 Yes, I was only meaning to disaprove on applying case (b) to dup2.

 Martin

From: Jukka Ruohonen <jruohonen@iki.fi>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Fri, 15 Jul 2011 11:56:58 +0300

 On Fri, Jul 15, 2011 at 10:50:44AM +0200, Martin Husemann wrote:
 > On Fri, Jul 15, 2011 at 11:49:14AM +0300, Jukka Ruohonen wrote:
 > > Yes, however dup3(2) is not standardized, AFAIR, leaving the behavior
 > > "undefined". And the case (a) should still apply.
 > 
 > Yes, I was only meaning to disaprove on applying case (b) to dup2.

 From a quick look, there is also a small defect in the manual page: how can
 dup2(2) or dup3(2) ever fail with EMFILE? (Also SUSv4 omits this for dup2(2).)

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
	Christos Zoulas <christos@NetBSD.org>
Cc: 
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sat, 16 Jul 2011 12:15:27 +0200

 On Sat, Jul 16, 2011 at 02:35:28AM +0300, Jukka Ruohonen wrote:
 > Can martin@ or christos@ comment about the avove? Surely it must be
 > impossible to fail with EMFAIL if these always close a descriptor...

 dup() can fail with EMFILE, obviously. I don't think dup2 or dup3 can
 fail this way, as we guarantee atomicity by keeping filedescriptors
 locked over the whole operation.

 Martin

From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45148 CVS commit: src/tests/lib/libc/sys
Date: Sat, 16 Jul 2011 14:29:16 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Sat Jul 16 14:29:15 UTC 2011

 Modified Files:
 	src/tests/lib/libc/sys: t_dup.c

 Log Message:
 PR lib/45148 was fixed; remove xfail.


 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.4 src/tests/lib/libc/sys/t_dup.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: jruoho@NetBSD.org
State-Changed-When: Sat, 16 Jul 2011 14:30:20 +0000
State-Changed-Why:

This was fixed, thanks.



From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45148 CVS commit: src/lib/libc/sys
Date: Sat, 16 Jul 2011 14:33:33 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Sat Jul 16 14:33:33 UTC 2011

 Modified Files:
 	src/lib/libc/sys: dup.2

 Log Message:
 Note that dup2(2) and dup3(2) may not fail with EMFILE; from PR lib/45148.


 To generate a diff of this commit:
 cvs rdiff -u -r1.25 -r1.26 src/lib/libc/sys/dup.2

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Jukka Ruohonen <jruohonen@iki.fi>
To: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org,
	netbsd-bugs@NetBSD.org
Cc: Christos Zoulas <christos@NetBSD.org>
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sat, 16 Jul 2011 02:35:28 +0300

 On Fri, Jul 15, 2011 at 11:56:58AM +0300, Jukka Ruohonen wrote:
 > From a quick look, there is also a small defect in the manual page: how can
 > dup2(2) or dup3(2) ever fail with EMFILE? (Also SUSv4 omits this for dup2(2).)

 Can martin@ or christos@ comment about the avove? Surely it must be
 impossible to fail with EMFAIL if these always close a descriptor...

 Otherwise this is fixed, thanks, and should be closed.

 ---

 (P.S. Not that it really matters here, but testing the corner cases have
 generally revealed few obvious, stupid panics.)

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, jruohonen@iki.fi
Cc: 
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sat, 16 Jul 2011 17:52:14 -0400

 On Jul 16,  8:45pm, jruohonen@iki.fi (Jukka Ruohonen) wrote:
 -- Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL

 | The following reply was made to PR lib/45148; it has been noted by GNATS.
 | 
 | From: Jukka Ruohonen <jruohonen@iki.fi>
 | To: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org,
 | 	netbsd-bugs@NetBSD.org
 | Cc: Christos Zoulas <christos@NetBSD.org>
 | Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
 | Date: Sat, 16 Jul 2011 02:35:28 +0300
 | 
 |  On Fri, Jul 15, 2011 at 11:56:58AM +0300, Jukka Ruohonen wrote:
 |  > From a quick look, there is also a small defect in the manual page: how can
 |  > dup2(2) or dup3(2) ever fail with EMFILE? (Also SUSv4 omits this for dup2(2).)
 |  
 |  Can martin@ or christos@ comment about the avove? Surely it must be
 |  impossible to fail with EMFAIL if these always close a descriptor...
 |  

 The only case the file descriptor code can return EMFILE is through the
 fd_alloc() path, and only dup() calls this; not dup2() or dup3().

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: jruohonen@iki.fi
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sun, 17 Jul 2011 03:24:14 +0000

 On Fri, Jul 15, 2011 at 08:50:04AM +0000, Jukka Ruohonen wrote:
  >  >  the open group base spec issue 7 says:
  >  >  
  >  >    If fildes2 is already a valid open file descriptor, it shall be closed
  >  >    first, unless fildes is equal to fildes2 in which case dup2() shall
  >  >    return fildes2 without closing it.
  >  >  
  >  >  Our dup2(3) man page has weaker words, but to the same effect.
  >  
  >  Yes, however dup3(2) is not standardized, AFAIR, leaving the behavior
  >  "undefined". And the case (a) should still apply.

 dup3 should be a superset of dup2, IOW, dup2(a, b) === dup3(a, b, 0).
 Anything else is insane and begging for bizarre problems in the future.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sun, 17 Jul 2011 09:48:40 +0100

 On Sun, Jul 17, 2011 at 03:25:02AM +0000, David Holland wrote:
 >  
 >  dup3 should be a superset of dup2, IOW, dup2(a, b) === dup3(a, b, 0).
 >  Anything else is insane and begging for bizarre problems in the future.

 Seems to me it should actually have the functionality of, dup(), dup2()
 and fcntl(F_DUPFD) - depending on the flags.

 So as well as O_CLOEXEC and O_NONBLOCK it needs a O_SCAN_FREE.

 Then:
   dup(nfd) == fcntl(nfd, F_DUPFD, 0)
   fcntl(nfd, F_DUPFD, ofd) == dup3(nfd, ofd, O_SCAN_FREE)
   dup2(nfd, ofd) == dup3(nfd, ofd, 0)

 Oh - and the man page really ought to include the fcntl() action.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: lib-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, jruohonen@iki.fi
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Sun, 17 Jul 2011 11:55:15 +0300

 On Sun, Jul 17, 2011 at 03:25:02AM +0000, David Holland wrote:
 >  dup3 should be a superset of dup2, IOW, dup2(a, b) === dup3(a, b, 0).
 >  Anything else is insane and begging for bizarre problems in the future.

 dup3() is Linux-specific function. I think it is important to do what Linux
 does. (If it was up to NetBSD, I doubt whether we would even have it.)

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/45148: dup2(3) and dup3(3) should support EINVAL
Date: Thu, 21 Jul 2011 03:30:48 +0000

 On Tue, Jul 19, 2011 at 03:30:09PM +0000, Jukka Ruohonen wrote:
  >>  dup3 should be a superset of dup2, IOW, dup2(a, b) === dup3(a, b, 0).
  >>  Anything else is insane and begging for bizarre problems in the future.
  >  
  >  dup3() is Linux-specific function. I think it is important to do what Linux
  >  does. (If it was up to NetBSD, I doubt whether we would even have it.)

 That's true, but if they do it stupidly, and we (and everyone else)
 goes along, it'll end up standardized stupidly and then it's wrong for
 everyone forever.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

Home	PR Database Search