Skip to content

Commit 77a42b3

Browse files
peffgitster
authored andcommitted
tempfile: drop active flag
Our tempfile struct contains an "active" flag. Long ago, this flag was important: tempfile structs were always allocated for the lifetime of the program and added to a global linked list, and the active flag was what told us whether a struct's tempfile needed to be cleaned up on exit. But since 422a21c (tempfile: remove deactivated list entries, 2017-09-05) and 076aa2c (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we actually remove items from the list, and the active flag is generally always set to true for any allocated struct. We set it to true in all of the creation functions, and in the normal code flow it becomes false only in deactivate_tempfile(), which then immediately frees the struct. So the flag isn't performing that role anymore, and in fact makes things more confusing. Dscho noted that delete_tempfile() is a noop for an inactive struct. Since 076aa2c taught it to free the struct when deactivating, we'd leak any struct whose active flag is unset. But in practice it's not a leak, because again, we'll free when we unset the flag, and never see the allocated-but-inactive state. Can we just get rid of the flag? The answer is yes, but it requires looking at a few other spots: 1. I said above that the flag only becomes false before we deallocate, but there's one exception: when we call remove_tempfiles() from a signal or atexit handler, we unset the active flag as we remove each file. This isn't important for delete_tempfile(), as nobody would call it anymore, since we're exiting. It does in theory provide us some protection against racily double-removing a tempfile. If we receive a second signal while we are already in the cleanup routines, we'll start the cleanup loop again, and may visit the same tempfile. But this race already exists, because calling unlink() and unsetting the active flag aren't atomic! And it's OK in practice, because unlink() is idempotent (barring the unlikely event that some other process chooses our exact temp filename in that instant). So dropping the active flag widens the race a bit, but it was already there, and is fairly harmless in practice. If we really care about addressing it, the right thing is probably to block further signals while we're doing our cleanup (which we could actually do atomically). 2. The active flag is declared as "volatile sig_atomic_t". The idea is that it's the final bit that gets set to tell the cleanup routines that the tempfile is ready to be used (or not used), and it's safe to receive a signal racing with regular code which adds or removes a tempfile from the list. In practice, I don't think this is buying us anything. The presence on the linked list is really what tells the cleanup routines to look at the struct. That is already marked as "volatile". It's not a sig_atomic_t, so it's possible that we could see a sheared write there as an entry is added or removed. But that is true of the current code, too! Before we can even look at the "active" flag, we'd have to follow a link to the struct itself. If we see a sheared write in the pointer to the struct, then we'll look at garbage memory anyway, and there's not much we can do. This patch removes the active flag entirely, using presence on the global linked list as an indicator that a tempfile ought to be cleaned up. We are already careful to add to the list as the final step in activating. On deactivation, we'll make sure to remove from the list as the first step, before freeing any fields. The use of the volatile keyword should mean that those things happen in the expected order. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent 78861eb commit 77a42b3

File tree

2 files changed

+2
-11
lines changed

2 files changed

+2
-11
lines changed

tempfile.c

Lines changed: 1 addition & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -86,8 +86,6 @@ static void remove_tempfiles(int in_signal_handler)
8686
else
8787
unlink_or_warn(p->filename.buf);
8888
remove_template_directory(p, in_signal_handler);
89-
90-
p->active = 0;
9189
}
9290
}
9391

@@ -108,7 +106,6 @@ static struct tempfile *new_tempfile(void)
108106
struct tempfile *tempfile = xmalloc(sizeof(*tempfile));
109107
tempfile->fd = -1;
110108
tempfile->fp = NULL;
111-
tempfile->active = 0;
112109
tempfile->owner = 0;
113110
INIT_LIST_HEAD(&tempfile->list);
114111
strbuf_init(&tempfile->filename, 0);
@@ -120,9 +117,6 @@ static void activate_tempfile(struct tempfile *tempfile)
120117
{
121118
static int initialized;
122119

123-
if (is_tempfile_active(tempfile))
124-
BUG("activate_tempfile called for active object");
125-
126120
if (!initialized) {
127121
sigchain_push_common(remove_tempfiles_on_signal);
128122
atexit(remove_tempfiles_on_exit);
@@ -131,15 +125,13 @@ static void activate_tempfile(struct tempfile *tempfile)
131125

132126
volatile_list_add(&tempfile->list, &tempfile_list);
133127
tempfile->owner = getpid();
134-
tempfile->active = 1;
135128
}
136129

137130
static void deactivate_tempfile(struct tempfile *tempfile)
138131
{
139-
tempfile->active = 0;
132+
volatile_list_del(&tempfile->list);
140133
strbuf_release(&tempfile->filename);
141134
free(tempfile->directory);
142-
volatile_list_del(&tempfile->list);
143135
free(tempfile);
144136
}
145137

tempfile.h

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -77,7 +77,6 @@
7777

7878
struct tempfile {
7979
volatile struct volatile_list_head list;
80-
volatile sig_atomic_t active;
8180
volatile int fd;
8281
FILE *volatile fp;
8382
volatile pid_t owner;
@@ -221,7 +220,7 @@ FILE *fdopen_tempfile(struct tempfile *tempfile, const char *mode);
221220

222221
static inline int is_tempfile_active(struct tempfile *tempfile)
223222
{
224-
return tempfile && tempfile->active;
223+
return !!tempfile;
225224
}
226225

227226
/*

0 commit comments

Comments
 (0)