Re: [PATCH] HPPA/IA64 : Don't use broken DL_AUTO_FUNCTION_ADDRESS()

["Carlos O'Donell" <carlos at redhat dot com>]

On 10/19/2013 02:06 AM, Mike Frysinger wrote:
> On Friday 18 October 2013 08:04:18 Guy Martin wrote:
>> On 2013-10-18 12:30, Andreas Schwab wrote:
>>> Guy Martin <gmsoft@tuxicoman.be> writes:
>>>> To prevent this, we use instead the existing macro
>>>> DL_STATIC_FUNCTION_ADDRESS() which is identical to
>>>> DL_AUTO_FUNCTION_ADDRESS() but declares fptr as static.
>>>
>>> Can the callers ever be reentered?
>>
>> AFAICS, it can't. The macro using DL_STATIC_FUNCTION_ADDRESS() are
>> DL_DT_INIT_ADDRESS() which is only used in dl-init.c and
>> DL_DT_FINI_ADDRESS() used in dl-fini.c and dl-close.c.
>> The only case where this might possibly be reentered would be parallel
>> calls of dlopen()/dlclose(). I'm not even sure those calls are supposed
>> to be thread safe.
> 
> they aren't supposed to be, but we try to make them so

Are you certain?

I thought POSIX says (indirectly) that dlopen and dlclose
must be thread safe.

e.g. They are not on the list of functions allowed to be
thread unsafe, therefore they must be thread safe.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01

So it's entirely possible we have concurrent calls to dlopen
in progress, but the dl_load_lock should serialize the loading
of the object.

As long as the uses of DL_STATIC_FUNCTION_ADDRESS() fall within
the critical regions protected by dl_load_lock then they should
be safe.

Andreas makes a good comment that they should really be rewritten
to avoid needing to create the function pointer, instead the code
should create and call it as required (that way the created fptr
need never leave scope). However doing so might be more work than
you have time for.

Therefore if you can show DL_STATIC_FUNCTION_ADDRESS uses are
serialized by dl_load_lock, then I think the patch is OK.

Cheers,
Carlos.

Cheers,
Carlos.