Understanding why getaddrinfo_a and __gai_enqueue_request use recursive locks

[Will Hawkins]

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).
>
> 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.

Mr. O'Donnell,

This is a great plan of attack and I'll follow it. Once I've made the
necessary changes I will go back and read the information about
submitting patches and then go from there.

Thanks for your mentorship with this trivial patch.

Will

>
> --
> Cheers,
> Carlos.