From: Phillip Wood <phillip.wood123@gmail.com>
To: Taylor Blau <me@ttaylorr.com>, Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, iwiedler@gitlab.com
Subject: Re: [PATCH 1/1] fetch: fix deadlock when cleaning up lockfiles in async signals
Date: Sat, 8 Jan 2022 10:54:35 +0000 [thread overview]
Message-ID: <2d8c1619-74ab-62b3-3a30-8e500a16649e@gmail.com> (raw)
In-Reply-To: <YdjBkZsnYd+zYne1@nand.local>
Hi Taylor
On 07/01/2022 22:41, Taylor Blau wrote:
> On Fri, Jan 07, 2022 at 11:55:47AM +0100, Patrick Steinhardt wrote:
>> diff --git a/transport.c b/transport.c
>> index 92ab9a3fa6..2a3e324154 100644
>> --- a/transport.c
>> +++ b/transport.c
>> @@ -1456,13 +1456,18 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs)
>> return rc;
>> }
>>
>> -void transport_unlock_pack(struct transport *transport)
>> +void transport_unlock_pack(struct transport *transport, unsigned int flags)
>> {
>> + int in_signal_handler = !!(flags & TRANSPORT_UNLOCK_PACK_IN_SIGNAL_HANDLER);
>> int i;
>>
>> for (i = 0; i < transport->pack_lockfiles.nr; i++)
>> - unlink_or_warn(transport->pack_lockfiles.items[i].string);
>> - string_list_clear(&transport->pack_lockfiles, 0);
>> + if (in_signal_handler)
>> + unlink(transport->pack_lockfiles.items[i].string);
>> + else
>> + unlink_or_warn(transport->pack_lockfiles.items[i].string);
>
> This puzzled me when I first read it. But unlink_or_warn() isn't
> reentrant because it performs buffered IO on stderr, so if we reached
> this signal handler while executing another function call modifying
> those same buffers, the call within the signal handler would have
> undefined behavior.
>
> So that makes sense: freeing (with string_list_clear() below) and
> performing buffered IO (with unlink_or_warn() here as just described)
> are certainly off the table.
>
> But is unlink() safe as-is? I'm not so sure. Reading signal-safety(7),
> it's clearly on the list of functions that are OK to call. But reading
> the errno section:
>
> errno
> Fetching and setting the value of errno is async-signal-safe
> provided that the signal handler saves errno on entry and restores
> its value before returning.
>
> We certainly not doing that, though that's nothing new, and so I wonder
> why it doesn't seem to be an issue in practice.
Because in this case we re-raise the signal and exit it does not matter
if unlink() clobbers errno. If instead the program were to continue
after handling the signal then we would have to save and restore errno
to avoid interfering with the code that was running when the signal
handler was called.
Best Wishes
Phillip
> Thanks,
> Taylor
next prev parent reply other threads:[~2022-01-08 10:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 10:53 [PATCH 0/1] Async-signal safety in signal handlers Patrick Steinhardt
2022-01-07 10:55 ` [PATCH 1/1] fetch: fix deadlock when cleaning up lockfiles in async signals Patrick Steinhardt
2022-01-07 11:14 ` brian m. carlson
2022-01-07 22:41 ` Taylor Blau
2022-01-08 10:54 ` Phillip Wood [this message]
2022-01-11 2:11 ` Taylor Blau
[not found] <cover.1641551066.git.ps@pks.im>
2022-01-07 10:53 ` Patrick Steinhardt
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=2d8c1619-74ab-62b3-3a30-8e500a16649e@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=iwiedler@gitlab.com \
--cc=me@ttaylorr.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/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 NNTP newsgroup(s).