Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 7 Nov 2019 14:48:50 +0100
From:   Olaf Hering <olaf@aepfle.de>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>
Cc:     "K. Y. Srinivasan" <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Sasha Levin <sashal@kernel.org>,
        "open list\:Hyper-V CORE AND DRIVERS" <linux-hyperv@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] tools/hv: async name resolution in kvp_daemon
Message-ID: <20191107144850.37587edb.olaf@aepfle.de>
In-Reply-To: <874kzfbybk.fsf@vitty.brq.redhat.com>
References: <20191024144943.26199-1-olaf@aepfle.de>
        <874kzfbybk.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/TfRDKLn+ytyQpDe=3EHiVfq"; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--Sig_/TfRDKLn+ytyQpDe=3EHiVfq
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Am Thu, 07 Nov 2019 14:39:11 +0100
schrieb Vitaly Kuznetsov <vkuznets@redhat.com>:

> Olaf Hering <olaf@aepfle.de> writes:

> Is it only EAI_AGAIN or do you see any other return values which justify
> the retry? I'm afraid that in case of a e.g. non-existing hostname we'll
> be infinitely looping with EAI_FAIL.

I currently do not have a setup that reproduces the failure.
I think if this thread loops forever, so be it.

The report I have shows "getaddrinfo failed: 0xfffffffe Name or service not=
 known" on the host side.
And that went away within the VM once "networking was fixed", whatever this=
 means.
But hv_kvp_daemon would report the error string forever.

> > +	pthread_detach(t); =20
> I think this should be complemented with pthread_cancel/pthread_join
> before exiting main().

If the thread is detached, it is exactly that: detached. Why do you think t=
he main thread should wait for the detached thread?

Olaf

--Sig_/TfRDKLn+ytyQpDe=3EHiVfq
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl3EIMIACgkQ86SN7mm1
DoDUzxAAoj3rIvo4UnuYA6gdsJXo/4gzx1ef87gMMUDuTYvUerULqG3HqC0PbzWg
T7nX3L8MqHDqTJ3NhZyIuicIqGub5HfwnzQDnTMS/1PIW/t0tkiVbFbnXyYaRx9B
wC8aJLxpaR6NT4XCqq1HMv1zF2fr329phf3kFOPRONGwRoh1ACgk8N9cVnK6Wakl
SCXWvXxaUtpt5I3A9UQUmQUSDDtv2+DrHiJctWfVZR2ZW2EVSeCNqMVJS4ZyF6Fo
WMPCnb/5zLlLYo204jlsdEB9ny/FgKrLhjQeuEO2Mt+qBXK//Rz79jRQLhKB1EpV
NrIpSgZ2PJAmnKRXVoKhqDo6CkPHmCbZFlWHGbmaRg9b5tQpY2cTiZI/4UgM8IIm
ogFuGEFAM7uWC+iPKgf/apAofMmNoL/8YHwThlgCptHZZotaZu/FdFHnUT1mYSY/
BsfFqhjjNKFkiy4J0GubudeCyKCyiIQ+aQ3inXDCJF3Mh2EbV4MMGIkzy9BqjCG3
pnmv5kcSXiuUv4r/KGBS0L+JD9D9cAQcF2arbs/YR4U20WbMQb+WHQmZgfKmjW9u
hLvAPIQSvkt6SJOVhqxUtC+YpuNp8gn+muX2SeTVFhIzYUhDwRUKdwGA/vcYeD+O
NT2FTV4m6T68jhRCWT1EcvAYztABDp8g9mhn2KJYvssbbstKIpk=
=A5vV
-----END PGP SIGNATURE-----

--Sig_/TfRDKLn+ytyQpDe=3EHiVfq--