git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] async_die_is_recursing: fix use of pthread_getspecific for Fedora

From
Jeff King <peff@peff.net>
Date
Nov 4, 2021, 02:37 UTC
Message-ID
<YYNHb0qq2n5OWC+R@coredump.intra.peff.net>
In-Reply-To
<CAPUEspjw4zypiywCBRc=y9uC4G5CKTE35GLVf_wDY436oO0C5w@mail.gmail.com>
On Wed, Nov 03, 2021 at 07:23:23PM -0700, Carlo Arenas wrote:
Show 18 quoted lines
> > diff --git a/run-command.c b/run-command.c
> > index 7ef5cc712a9..a82cf69e7d3 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -1099,7 +1099,7 @@ static NORETURN void die_async(const char *err, va_list params)
> >  static int async_die_is_recursing(void)
> >  {
> >         void *ret = pthread_getspecific(async_die_counter);
> > -       pthread_setspecific(async_die_counter, (void *)1);
> > +       pthread_setspecific(async_die_counter, &ret); /* set to any non-NULL valid pointer */
> 
> I guess this would work, since the pointer is never dereferenced, but
> the use of (void *)1 was hacky, and this warning seems like the right
> time to make it less so.
> 
> Would a dynamically allocated pthread_local variable be a better
> option,  or even a static global, since we don't care about its value
> so no need to worry about any races?

Yeah, I had the same thought. I think what's in the patch above is OK in practice, but it sure _feels_ wrong to store the address of an auto variable that goes out of scope.

I'm OK with it as a minimal fix, though, to get things unstuck. The commit message nicely explains what's going on, and the original (which it looks like blames to me ;) ) is pretty gross, too.

Keeping an actual counter variable would be the least-confusing thing, IMHO, but that implies allocating per-thread storage (which means having to clean it up). And we really only care about counting up to "1", so the boolean "do we have a pointer" is fine. The static variable you suggest might be a good middle ground there, and we could even use it for the comparison to make things more clear. Something like:

  static int async_die_is_recursing(void)
  {
	  static int async_recursing_flag;
          void *ret = pthread_getspecific(async_die_counter);
	  pthread_setspecific(async_die_counter, &async_recursing_flag);
	  return ret == &async_recursing_flag;
  }
But I don't feel that strongly either way.
-Peff
Previous: Carlo ArenasNext: Carlo Arenas
Message 3 of 15 in “async_die_is_recursing: fix use of pthread_getspecific for Fedora”
  1. async_die_is_recursing: fix use of pthread_getspecific for FedoraVictoria Dye via GitGitGadget, Nov 4, 2021
  2. Carlo ArenasNov 4, 2021
  3. Jeff KingNov 4, 2021
  4. Carlo ArenasNov 4, 2021
  5. Jeff KingNov 4, 2021
  6. async_die_is_recursing: work around GCC v11.x issue on FedoraVictoria Dye via GitGitGadget, Nov 4, 2021
  7. Jeff KingNov 4, 2021
  8. Junio C HamanoNov 4, 2021
  9. Ævar Arnfjörð BjarmasonNov 4, 2021
  10. Derrick StoleeNov 4, 2021
  11. Junio C HamanoNov 4, 2021
  12. Junio C HamanoNov 5, 2021
  13. Johannes SchindelinNov 4, 2021
  14. Carlo ArenasNov 4, 2021
  15. Johannes SchindelinNov 4, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.