This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] Add renameat2 function [BZ #17662]

From: Paul Eggert <eggert at cs dot ucla dot edu>
To: Joseph Myers <joseph at codesourcery dot com>
Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org, Gnulib bugs <bug-gnulib at gnu dot org>
Date: Mon, 2 Jul 2018 12:58:33 -0700
Subject: Re: [PATCH] Add renameat2 function [BZ #17662]
References: <20180630121447.E4C8643994575@oldenburg.str.redhat.com> <4a9cb334-48f4-139f-d917-457ce8ece57a@cs.ucla.edu> <alpine.DEB.2.20.1807021939100.3430@digraph.polyomino.org.uk>

Joseph Myers wrote:

We've had complaints in glibc about fallbacks that introduce races (e.g.
<https://sourceware.org/bugzilla/show_bug.cgi?id=9813> for pselect).  Do
you have reason to believe that this race is somehow different and
introducing it will never cause problems for users?

"Never" is a pretty strong word, and I don't know that it's true here. I do knowthat the uses of Gnulib renameat2 don't have any problems with races that theywouldn't have with their own fallbacks, and I haven't yet run into a potentialcase that would differ from this.

If the requirement is "never", then let's go with another flag(RENAME_NONATOMIC, say), that can be ORed in to allow renameat2 to behavenon-atomically. This flag would not be passed to the Linux kernel syscall; itwould affect only the user-mode fallback code.

References:
- Re: [PATCH] Add renameat2 function [BZ #17662]
  - From: Paul Eggert
- Re: [PATCH] Add renameat2 function [BZ #17662]
  - From: Joseph Myers

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]