|
From: | Paul Eggert |
Subject: | Re: [PATCH] Add renameat2 function [BZ #17662] |
Date: | Mon, 2 Jul 2018 12:58:33 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
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 know that the uses of Gnulib renameat2 don't have any problems with races that they wouldn't have with their own fallbacks, and I haven't yet run into a potential case 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 behave non-atomically. This flag would not be passed to the Linux kernel syscall; it would affect only the user-mode fallback code.
[Prev in Thread] | Current Thread | [Next in Thread] |