From nobody Wed Apr 26 20:28:12 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q69Rh0cKtz47G75 for ; Wed, 26 Apr 2023 20:28:16 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q69Rg2zW8z4LZK for ; Wed, 26 Apr 2023 20:28:15 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=UaMYTZXw; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=paulf2718@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3f315712406so166485e9.0 for ; Wed, 26 Apr 2023 13:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682540893; x=1685132893; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=2G/TZuCAVhuh60WKjWMHBJ/WXgUxXjrHw7j/EYtWszc=; b=UaMYTZXwYIxVUPcR6pHn/bglKxCVpkZTLRydqESq+tHJwvd5QSdkDgcfa60aggfTyu HlFCzYXDrbKYwX6cLQeBZMHJgfvSjo5N2ZAYgRxu+7fU4knR7ULjZGcVmw53qpNyXY8t NlLeC9XynWmAgTkr8WdnJCCshoXluW9hmh56TWLGVWNVQCFQHAtFHtbkdwESLxcq5fAJ uDdROsfPS/8Z6gbXUxncLTOEIeFUO2jxz643nFfpxOonFRdNFWN6GRN5iy9SBLRkVFZA 0raxvrQh/Z7saNi21L4HG8SxwoCqxYcQNDsyVA1J2wbyw0nymo8T/Uh2R0W2dhQH29MB abiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682540893; x=1685132893; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2G/TZuCAVhuh60WKjWMHBJ/WXgUxXjrHw7j/EYtWszc=; b=Go9A1VS4QI8//7pxfK46DqLsb9VD3QKS9JGDU0EtRfqJqmOYSbCQz0qrBU7Z2dSeIB uc2rhm5STSdUtwLQGisr9Ag2MxMrii+y6myK3+0YDTdyKn7KrEyMJMDHTFsZ+cxlgL1Y EWseMW2TmpUbI8tM+xeF1IJGsLwecMkgJjpRmFE9Wsiru/YjFhfaP8Spdq/79RAQ9kiN fue4LS0VDw2RZv7pOEz9cGLTq+SPkHCzpC+8Qz8Gcokce+n3C2wzL81q8k0qFBDdpvJ3 NLHYG2c/SI1RDFZ/NYxJzWIQwEYTBtiA/CjP1/KJk6pCxi4RtxbphoFnkdPMC4pY57J9 ttoA== X-Gm-Message-State: AC+VfDwrkTis3O9OOeMsfwH6YrwW/cvdD6hgyzR4JZH9NjHiBcbi1nMb 4zHxcNwFTQN5wVt7uMwO5prUw/lfBMm91w== X-Google-Smtp-Source: ACHHUZ4X8AJ01LBYhB/HqojFCB8uR51wEVK0cmwGmKQhGRyIKbecSravEQzHnUNiOu+5iwZ6bisUjQ== X-Received: by 2002:a5d:4887:0:b0:2ff:801b:dec6 with SMTP id g7-20020a5d4887000000b002ff801bdec6mr2592106wrq.20.1682540892996; Wed, 26 Apr 2023 13:28:12 -0700 (PDT) Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115]) by smtp.gmail.com with ESMTPSA id p10-20020a5d48ca000000b003047dc162f7sm7375710wrs.67.2023.04.26.13.28.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Apr 2023 13:28:12 -0700 (PDT) Message-ID: Date: Wed, 26 Apr 2023 22:28:12 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: Thread safety of getaddrinfo()/getnameinfo() To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4Q69Rg2zW8z4LZK X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 26-04-23 19:57, Felix Palmen wrote: > So, is there a thread-safety issue with these functions, or a bug in > valgrind, or maybe just some false positive? A false positive is a bug. No errors with asan. DRD also generates errors. I believe that getaddrinfo should be MT safe. I just pushed a fix to the Valgrind repo. If you like you can use it by building Valgrind from source (see https://valgrind.org/downloads/repository.html and then see README.freesd). Otherwise Valgrind 3.21 is due for release this Friday, 28th April. I'll be bumping up the devel/valgrind version based on that shortly after, so it should be available in a week or two. Here are further details. Using a debug build of libc I get (still on FreeBSD 13.1 amd64): ==7225== Possible data race during read of size 1 at 0x4A4F0D0 by thread #4 ==7225== Locks held: none ==7225== at 0x4974680: __sfp (lib/libc/stdio/findfp.c:135) ==7225== by 0x4974D0B: fopen (lib/libc/stdio/fopen.c:62) ==7225== by 0x4939363: _sethtent (lib/libc/net/getaddrinfo.c:2381) ==7225== by 0x4939363: ??? (lib/libc/net/getaddrinfo.c:2502) ==7225== by 0x494A14C: nsdispatch (lib/libc/net/nsdispatch.c:727) ==7225== by 0x4937A68: explore_fqdn (lib/libc/net/getaddrinfo.c:1945) ==7225== by 0x4937A68: getaddrinfo (lib/libc/net/getaddrinfo.c:576) ==7225== by 0x201A2E: resolve (hak.c:23) ==7225== by 0x485B756: mythread_wrapper (hg_intercepts.c:406) ==7225== by 0x4C7F839: ??? (in /lib/libthr.so.3) ==7225== ==7225== This conflicts with a previous write of size 1 by thread #2 ==7225== Locks held: none ==7225== at 0x4974714: __sfp (lib/libc/stdio/findfp.c:146) ==7225== by 0x4974D0B: fopen (lib/libc/stdio/fopen.c:62) ==7225== by 0x4939363: _sethtent (lib/libc/net/getaddrinfo.c:2381) ==7225== by 0x4939363: ??? (lib/libc/net/getaddrinfo.c:2502) ==7225== by 0x494A14C: nsdispatch (lib/libc/net/nsdispatch.c:727) ==7225== by 0x4937A68: explore_fqdn (lib/libc/net/getaddrinfo.c:1945) ==7225== by 0x4937A68: getaddrinfo (lib/libc/net/getaddrinfo.c:576) ==7225== by 0x201A2E: resolve (hak.c:23) ==7225== by 0x485B756: mythread_wrapper (hg_intercepts.c:406) ==7225== by 0x4C7F839: ??? (in /lib/libthr.so.3) ==7225== Address 0x4a4f0d0 is in the BSS segment of /usr/home/paulf/build/src/obj/usr/home/paulf/build/src/amd64.amd64/lib/libc/libc.so.7.full The code in question is STDIO_THREAD_LOCK(); for (g = &__sglue; g != NULL; g = g->next) { for (fp = g->iobs, n = g->niobs; --n >= 0; fp++) HERE=> if (fp->_flags == 0) goto found; } STDIO_THREAD_UNLOCK(); /* don't hold lock while malloc()ing. */ and STDIO_THREAD_LOCK(); /* reacquire the lock */ SET_GLUE_PTR(lastglue->next, g); /* atomically append glue to list */ lastglue = g; /* not atomic; only accessed when locked */ fp = g->iobs; found: HERE=> fp->_flags = 1; /* reserve this slot; caller sets real flags */ STDIO_THREAD_UNLOCK(); These lock macros use spinlocks. The problem is that Valgrind (both Helgrind and DRD) doesn't recognize any locking mechanisms other than pthreads and Qt threads. That means that the Valgrind tools fall back on the suppression mechanism for all libthr and libc internal locks like this. A+ Paul