Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jul 2015 23:51:53 +0200
From: Jens Gustedt <>
Subject: Re: [PATCH] fix atexit when it is called from an atexit

Am Donnerstag, den 23.07.2015, 15:58 -0400 schrieb Rich Felker:
> On Thu, Jul 23, 2015 at 09:19:13AM +0200, Jens Gustedt wrote:
> > Am Donnerstag, den 23.07.2015, 07:54 +0200 schrieb Jens Gustedt:
> > > I'd think this could be done even simpler by running the handlers in
> > > batches. ...
> > 
> > I checked, the strict ordering constraints for the handlers don't
> > allow for such a strategy, so forget it.
> Indeed, this is not possible.
> > Looking at the code, I am a bit uncomfortable with the idea of a
> > potentially unlimited number of calloc calls during exit. I think it
> Is there a specific reason? This will only happen in pathological code
> that keeps registering atexit handlers, and eventually the allocations
> will fail and therefore atexit will fail, which it's allowed to do.
> The only thing pathological that happens is that memory usage keeps
> increasing even if you've balanced the running and registering of
> atexit handlers so that the total number registered always stays
> bounded, but we're still talking about extreme abuse of the atexit
> API, and I think optimizing this case without an argument that it's
> worthwhile would probably be premature optimization.

It is probably not worth for optimization, I agree. It is more a
question of safety. Have code fail early that is trapped in an
infinite loop of adding atexit handlers during exit.

> > would be good if we could restrict the maximal number of successful
> > calls to atexit during exit to 32. A calloc-free strategy could be to
> > save head to a tmp a the beginning of processing and to provide a
> > `struct fl` table on the stack of __funcs_on_exit.
> I'm not sure how this would be better. It would be more predictable,
> but could also probably break some excessive but "valid" use (like
> a huge chain of ctors getting called from an atexit handler and all
> registering dtors).

I think this is really excessive and probably very poor design. atexit
should not be abused to make an entry into the list on a per-object

No application should expect to be able to submit more than 32
handlers. After that atexit is allowed to fail, so everything more
than that is not portable. I don't advocate to keep strictly on the 32
bound (as we do for at_quick_exit), but once the process has entered
the exit procedure, there should be pressure to get things terminated.

> > > A similar improvement could be done for at_quick_exit. There I think
> > > it makes not much sense accepting new handlers during processing. So
> > > the strategy could just be
> > > 
> > >   (i) Take the lock and save count in a tmp
> > >   (ii) set count to 32
> > >   (iii) unlock
> > >   (iv) do the processing
> > > 
> > > But looking at it, I think that one can even be more improved. We
> > > could just use count as atomic, and so we wouldn't need a lock.
> > > I can prepare a patch for that, if you like.
> > 
> > Since this is fairly simple, I just did it. Please find a new version
> > attached. (too much changes, a patch makes no sense.)  This compiles,
> > but I have no code to test this.
> The current program in musl is not to treat replacements of locks by
> an atomics as an improvement, but rather the opposite.

Ok, I wasn't aware of it.

For the code in question, I am not sure that it is more complicated
than the LOCK/UNLOCK/re-LOCK scheme of the current implementation.

Generally, it is perhaps worth thinking to omit the LOCK/UNLOCK in
the __funcs_... loops altogether. This is a context that is guaranteed
to be single threaded, I think.


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.