From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jim Meyering <jim@meyering.net>,
bug-gnulib@gnu.org, "Richard W.M. Jones" <rjones@redhat.com>,
linux-fsdevel@vger.kernel.org
Subject: [regression] F_DUPFD_CLOEXEC breakage fix
Date: Mon, 8 Oct 2012 23:21:58 +0100 [thread overview]
Message-ID: <20121008222158.GQ2616@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20121008215325.GC15039@rhmail.home.annexia.org>
On Mon, Oct 08, 2012 at 10:53:25PM +0100, Richard W.M. Jones wrote:
> On Mon, Oct 08, 2012 at 10:50:30PM +0100, Richard W.M. Jones wrote:
> [.. discussion on gnulib test-cloexec test snipped ..]
> > I'm suspicious this is a kernel bug:
> >
> > creat("test-cloexec.tmp", 0600) = 3
> > fcntl(3, F_GETFD) = 0
> > fcntl(3, F_GETFD) = 0
> > fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> > fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> > fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
> > fcntl(3, F_SETFD, 0) = 0
> > fcntl(3, F_GETFD) = 0
> > fcntl(3, F_DUPFD_CLOEXEC, 0) = 4
> > fcntl(4, F_GETFD) = 0
> > write(2, "test-cloexec.c:97: assertion failed\n", 36) = 36
> >
> > It seems to me from the description in the man page that
> > F_DUPFD_CLOEXEC ought to be setting the FD_CLOEXEC flag on file
> > descriptor 4, so either it's not or else F_GETFD isn't reading the
> > flag for some reason.
Interesting... Oh, crap. OK, that's easily fixed: in fs/fcntl.c
err = f_dupfd(arg, filp, FD_CLOEXEC);
should get s/FD_/O_/. Linus, could you apply the following?
Fix a braino in F_DUPFD_CLOEXEC; f_dupfd() expects flags for
alloc_fd()/get_unused_fd()/etc. and there clone-on-exec if
O_CLOEXEC, not FD_CLOEXEC.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 8f70429..71a600a 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -258,7 +258,7 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned long arg,
err = f_dupfd(arg, filp, 0);
break;
case F_DUPFD_CLOEXEC:
- err = f_dupfd(arg, filp, FD_CLOEXEC);
+ err = f_dupfd(arg, filp, O_CLOEXEC);
break;
case F_GETFD:
err = get_close_on_exec(fd) ? FD_CLOEXEC : 0;
next prev parent reply other threads:[~2012-10-08 22:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20121008171517.GA15039@rhmail.home.annexia.org>
[not found] ` <20121008172103.GB15039@rhmail.home.annexia.org>
[not found] ` <87a9vwrgtl.fsf@rho.meyering.net>
[not found] ` <20121008215030.GI24071@rhmail.home.annexia.org>
[not found] ` <20121008215325.GC15039@rhmail.home.annexia.org>
2012-10-08 22:05 ` F_DUPFD_CLOEXEC broken in 3.7.0 Richard W.M. Jones
2012-10-09 14:07 ` Cong Wang
2012-10-09 14:10 ` Richard W.M. Jones
2012-10-08 22:21 ` Al Viro [this message]
2012-10-09 8:53 ` [regression] F_DUPFD_CLOEXEC breakage fix Richard W.M. Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121008222158.GQ2616@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=bug-gnulib@gnu.org \
--cc=jim@meyering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rjones@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.