From nobody Sat May 14 16:21:39 2022 X-Original-To: freebsd-threads@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 8F8DC1ADB31B for ; Sat, 14 May 2022 16:21:48 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 4L0rPR56SXz3Hr5 for ; Sat, 14 May 2022 16:21:47 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42b.google.com with SMTP id j25so14030450wrc.9 for ; Sat, 14 May 2022 09:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=kcbfq8CuPwA6PMm6DL8vXBqmTZCItLbtfbIFcaQCK44=; b=XoW3ZrvjEOb9E4Q63lXQeV/2tLm0CnREcNHxMaehPi7oxNOCS91vGhTtazFJn1AL2T EQcDn91XUbpdOIUWcnvUodh1SbmqdZDvHQA5tea2fSi+c9pqqJwPiuYA9Dp3cJXB4zEj PpnEr5+Q3HCjJtaiWHR8OcV1tB80GHl49U7O1aAIPq3BGw+lfyYpsRB9/anxbiccAd4i qfJVoCZ0EDZYTkzbwjoGopdsm2dRJYJFSYUMyAlQb3h0rpMtQy/R6iVHxx4mYxfSp2Ew F/KbaCijJXqAynIXPgPc5Kvt0ubx44onYuF8K6CMVh0k8rW7u+69ie78To2H8b7iQsa9 Q1Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=kcbfq8CuPwA6PMm6DL8vXBqmTZCItLbtfbIFcaQCK44=; b=svjXkAeIKFDB0AC+IHtkE+DKfhZxMWU3zmh//mCLDYUAO+QJKK3g4k6quAnfZgZiv9 prs+Xao4oQxQtXVbnhv0hLtX6YoRyp4zrSH4p49YDAXlWm0oyQA60TR6sC8fMrarC4Gs eXbkOKQ685Z1L+gaqdq6xXGGwJHsA4DIH9XrsEa3x8VnGQ5XGJqviP219grbiqXweYkq RrBq/t29noRyq1mEmnHuHZeKjsWjTmkIDGxSUyCGvG2ER01Qoi2BwzS+RmPUtLXC8v/4 g6F5CaZG+JLcLKvIpakzKfhtsaDZysU11qiUZNqxLhoIf/30QuucidbeuorrK11msXJ5 xMVg== X-Gm-Message-State: AOAM5333hl4LIUho1+IKtNJxn28faiSZJfkga17hX3EyuxbX7ux9Ch2d N6z0zrvgvvEqOueGXUuy0pOS0aSqOwmkdw== X-Google-Smtp-Source: ABdhPJy0ieK8Z6KyWwvELSSeKi6M7FVYHomnLC675TCOd0H4AOFSFOd9nfHk4k3hZ2JgwCoQTv/cJA== X-Received: by 2002:a5d:554d:0:b0:20d:44a:ba38 with SMTP id g13-20020a5d554d000000b0020d044aba38mr201519wrw.515.1652545301366; Sat, 14 May 2022 09:21:41 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id l20-20020a1c7914000000b00394538d039esm8515260wme.6.2022.05.14.09.21.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 May 2022 09:21:40 -0700 (PDT) Message-ID: <75f350fa-4fb5-f1e7-2a45-bb825a6620d3@gmail.com> Date: Sat, 14 May 2022 18:21:39 +0200 List-Id: Threading List-Archive: https://lists.freebsd.org/archives/freebsd-threads List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: freebsd-threads@FreeBSD.org Content-Language: en-US From: Paul Floyd Subject: LDT/GDT and TCB use by threads Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L0rPR56SXz3Hr5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=XoW3Zrvj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.65 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-threads@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.35)[0.350]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from]; MLMMJ_DEST(0.00)[freebsd-threads]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi I'm trying to understand and fix a problem that I have with Valgrind (which I maintain on FreeBSD). The full gory details are here https://github.com/paulfloyd/freebsd_valgrind/issues/85 In short, on i386 Valgrind allocates a block of 8k slots for the LDT/GDT when the first thread gets created. For each subsequent thread it uses up one slot, until when the 8192 slots have all been used and libthr fails because of a dirty thread exit. On Linux x86, from what I've seen, main() allocates a thread area (Valgrind intercepts a syscall sys_set_thread_area). Then syscall sys_clone (which is used for both pthread_create and fork, with different flags) allocates a new GDT every time. Thread exits deletes the thread area. And after a fork, some Valgrind child code deletes  the GDTs other than for the running tid. My understanding is that FreeBSD has a lighter weight pthread implementation. I think that I should be doing something similar in the case of fork - delete all GDTs other than for the running tid. I'm not sure what I can do in the case of thread creation and exit. If I delete the GDT like on Linux I get a crash since it seems on FreeBSD the GDT still gets used after thr_exit() (in particular, I see calls to get_currthread() in ld-elf32.so which access a lock in the TCB/GDT). I have a few questions (and may have more as I continue to debug). What exactly causes an application to switch to using threaded versions of libc functions (I'm thinking specifically of fork())? Is it just by linking with libthr? Or does the application need to create a thread first before switching? Maybe a bit harder to say, but what is the usage of the GDT/ TCB in terms of thread lifetime? And the same question for an ordinary process and for a process created in a threaded application. A+ Paul