bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: bug-gnulib@gnu.org
Subject: Re: use O_CLOEXEC in more places
Date: Thu, 28 May 2020 21:51:29 +0200	[thread overview]
Message-ID: <144612242.mPdaZgKOgk@omega> (raw)
In-Reply-To: <3fb846cc-a709-b6bb-5615-20482bb98950@cs.ucla.edu>

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Paul Eggert wrote:
> > How about module 'fts'? Should the directory fds that it allocates also be
> > made O_CLOEXEC?
> 
> Yes, I'd say so; I see little reason for a child process to continue an fts scan.

Done through this patch. In fact, you had already done most of the work
on 2017-08-12.

Bruno

[-- Attachment #2: 0001-fts-Make-more-robust-in-multithreaded-applications.patch --]
[-- Type: text/x-patch, Size: 1743 bytes --]

From 708c76165712d6cbad59379b7e039870f81ca63c Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Thu, 28 May 2020 21:48:13 +0200
Subject: [PATCH] fts: Make more robust in multithreaded applications.

* lib/fts.c (fts_open): Pass an O_CLOEXEC flag to open().
* modules/fts (Depends-on): Add 'open'.
---
 ChangeLog   | 6 ++++++
 lib/fts.c   | 2 +-
 modules/fts | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index e637b57..4145796 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2020-05-28  Bruno Haible  <bruno@clisp.org>
 
+	fts: Make more robust in multithreaded applications.
+	* lib/fts.c (fts_open): Pass an O_CLOEXEC flag to open().
+	* modules/fts (Depends-on): Add 'open'.
+
+2020-05-28  Bruno Haible  <bruno@clisp.org>
+
 	relocatable-prog: Make more robust in multithreaded applications.
 	* lib/progreloc.c (O_CLOEXEC): Define fallback to 0 when use from module
 	relocatable-prog-wrapper.
diff --git a/lib/fts.c b/lib/fts.c
index 3b2f693..5e357be 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -402,7 +402,7 @@ fts_open (char * const *argv,
                early, doing it here saves us the trouble of ensuring
                later (where it'd be messier) that "." can in fact
                be opened.  If not, revert to FTS_NOCHDIR mode.  */
-            int fd = open (".", O_SEARCH);
+            int fd = open (".", O_SEARCH | O_CLOEXEC);
             if (fd < 0)
               {
                 /* Even if "." is unreadable, don't revert to FTS_NOCHDIR mode
diff --git a/modules/fts b/modules/fts
index 480700b..b06d5b8 100644
--- a/modules/fts
+++ b/modules/fts
@@ -22,6 +22,7 @@ hash
 i-ring
 lstat
 memmove
+open
 openat-h
 opendir
 opendirat
-- 
2.7.4


      reply	other threads:[~2020-05-28 19:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 18:43 use O_CLOEXEC in more places Bruno Haible
2020-05-27 21:55 ` Bernhard Voelker
2020-05-27 22:21 ` Jim Meyering
2020-05-27 23:33 ` Paul Eggert
2020-05-28 19:51   ` Bruno Haible [this message]

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=144612242.mPdaZgKOgk@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).