Re: Understanding why getaddrinfo_a and __gai_enqueue_request use recursive locks

[Will Hawkins <whh8b at virginia dot edu>]

On Mon, Sep 25, 2017 at 12:13 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/23/2017 08:44 AM, Will Hawkins wrote:
>> This is what confused me -- thank you for the confirmation that I was
>> not going crazy! After an hour of trying to figure out how the code
>> did not deadlock every time, I finally looked at the
>> initialization/definition of the mutex and saw that it was recursive.
>
> We call this a belt-and-suspenders approach, particularly if there were
> multiple callers in the past that might or might no have taken the lock.
>
> In this case it looks like there is just one caller so the appropriate
> patch would have to be:
>
> * Remove locking from helper function.
> * Add comments to helper function explaining that lock X must be held
>   before calling.
> * Add comments in caller stating that lock must be taken before calling
>   helper function.
> * Look to see if have a reasonable test that exercises this code path,
>   and if not add one (I think there are tests already that cover this
>   area of code).
>

There appears to be a related test in the file ga_test.c in resolv/.
However, I can't figure out how the check/tests target is building
this file. In fact, I can't get the file to build.

The target that seems to control building this file is guarded by two
conditionals build-shared and have-thread-library. I have verified
that those flags are both set in my build environment. With that
control passed, it looks like it is supposed to only then use the
ga_test as the only test target. This appears to be confimed by the
comments in the Changelog (Changelog.old/Changelog.12:5501 and commit
log (e10546cb67fe0b5366fede3661b6c15363e4f54f) for when that file/test
was incorporated into the repository.

The target, then, looks like this:

$(objpfx)ga_test: $(objpfx)libanl.so $(shared-thread-library)

which, in turn, ensures that libanl.so is built.

However, that target has no other actions. I would presume that
somewhere there is a pattern matching target that will build this, but
I'm too stupid to find it.

If anyone can help me track this down, I'd really appreciate it. Thank
you so much!

Will


> That's just a rough sketch of the details. This fix doesn't need a
> public bug since it's not a user visible feature, just an optimization.
>
> --
> Cheers,
> Carlos.