From nobody Mon Jan 29 19:01:59 2024 X-Original-To: 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 4TNyMq55N6z59DBZ for ; Mon, 29 Jan 2024 19:01:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNyMq3yFbz3yF2 for ; Mon, 29 Jan 2024 19:01:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706554919; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=832xBFL64W0Ki3zSGoKBnOec8WLv3KdJ0XdZSz5r7VU=; b=bxTgXsO+aG1F330blJenQIkVBOwYV+mphzGmvVxzokE+MBZgKR0dGyghqAztw/n3qlgloj BVSqot4OBsKq4Ytc5YGyIm0XkXl5RQBiJ3Ofnw6+qc+dTqZtLazvAfGBY40in5b1CVgVzW jagqq51IzTQPe2A6BRYsCU7lZD3Kv7R9s+NPej9PORkdD1gIc8zfMfekN4fWnE5ODRKoav aLMr+f2WbUZi63whS30R1alyNScOsroHD26sA1CRfg8ztw00a418YB+hIznHRZXhvZ7XdK MXiI9i+0OekkxQBzWipoQRRBc23DXBsWTUXQBec+cZIUbD2ajL8X0vB1WrRQ2w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706554919; a=rsa-sha256; cv=none; b=t8gZo9sXfprNa6C0PstMgwu75DcUwFPK+sWnsCBsI4ooxcy2c6JUiajNaINUuSvFAI0GKm mL2+acSexV6skmGp62N1kKDvTiLlMOQPxy77LotfQG+TU7L9oYrJZ7lbAjYgtyp0FEW8HD eEjy7QixNXEHc5uhZIozmej79boGdqqecnEUT74HDNVT+1FmHHj3j+48wqQjMpls2z7oXB hkbS48X0jOwYknfkUQoyad1Ul13ud95wYo79BldWHPLijXddJV6Z5KF3lXqjTzSwxSK798 PCVLnCUfe2KCOJugRAHR3isNAA2bzeuJyTl8itSPZ2Zm3HntoP9BJpBjekZnmQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TNyMq32fDz13Dm for ; Mon, 29 Jan 2024 19:01:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40TJ1x5w014922 for ; Mon, 29 Jan 2024 19:01:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40TJ1xHh014921 for threads@FreeBSD.org; Mon, 29 Jan 2024 19:01:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 212332] panic with Sleeping thread owns a non-sleepable lock from uipc_send Date: Mon, 29 Jan 2024 19:01:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212332 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |markj@FreeBSD.org Resolution|--- |Overcome By Events --- Comment #1 from Mark Johnston --- I'm sorry that this didn't get any attention when it was reported. The unix domain socket code has changed quite a lot since then and there haven't been any reports of similar panics on newer FreeBSD versions. Please re-open the bug if this panic still occurs on supported releases, i.e., 13.x or 14.x. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jan 29 19:06:10 2024 X-Original-To: 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 4TNySf3XGsz59F0x for ; Mon, 29 Jan 2024 19:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNySf1h19z44SX for ; Mon, 29 Jan 2024 19:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706555170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3bzCD+4P39RBVsrzpmUTrM1iFOftYyD6XbOkvOFhHt8=; b=dOS6wuKXRmFdKD+Dpgpf2pU0B4PhMYclDLxGPxGl7TEDkJSCpHfPSOnmt0Dx0gd1cD6zBC dC9k+hRqyC21WPwh73gEGFvHu9CPjUpSRY8Zd1lFDgcAhSUF/o5xyjng7avUJy/A83mAim YUu7wcqvzsyfW1uPYIjsITE4374OG/t71CRfVfTOsHu8AunHB3mOaVSUjJsNTKwmecCIQ0 2yMPyW90BOMYBi4OR5BWcKh080vJd0QYIMN+72S28eup8pkdFkH0gDxkwZI3jCwDpFFgnN rFkxR6evL4PrtbyjuKjifUKzt1pBvicjFosckeiaP/Ln4ns4RKTMzQv3c7Z9CA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706555170; a=rsa-sha256; cv=none; b=hzh0KJ3zCiwGrdlzzO9NkuVdblC9xGDWshmHN9TPe2sseUIftfhSnA59RBBhEZl6E+eS6a yM1XC1T8lu6WsQ8W0/vLvdJmrJB7Y69LmohQEw2PuGw/pigqyPwIUqEkm6fS+Jtrp2cjqZ vRAlqPGRzZ3V7y7cFOjgIC6OTbv1DnXPAVzFkiJxczohDriUr6f2qh9dq+STNhf0taEygg VxnbPSU/6Y4IVjlBqp5dI9NEDPOChrBWjlMzYquTghv7Ol6uTrd92GeQUxkE9L+AMfRUuU xRm55eZN3Wm5rhdIU3nZMjZrZ7nw9YLieOtJ53W4/gvhvKdUKVg9cbIESd6Fzg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TNySf0c2Bz13FF for ; Mon, 29 Jan 2024 19:06:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40TJ6978033935 for ; Mon, 29 Jan 2024 19:06:09 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40TJ69RC033934 for threads@FreeBSD.org; Mon, 29 Jan 2024 19:06:09 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 233396] In FreeBSD 11.x thread creation time is too much on Xeon Gold 5115 CPU Date: Mon, 29 Jan 2024 19:06:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233396 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events CC| |markj@FreeBSD.org --- Comment #1 from Mark Johnston --- This appears to be fixed on supported versions of FreeBSD. Please re-open = if you find otherwise. Using the demo benchmark program, I see less than 100us thread creation times across several machines running development builds. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jan 29 19:07:54 2024 X-Original-To: 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 4TNyVh3vdCz59DvB for ; Mon, 29 Jan 2024 19:07:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TNyVh2k3xz44TL for ; Mon, 29 Jan 2024 19:07:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1706555276; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IChWV5KOo+YBnCjklDZnE3T/OhDUdt4B+CCpYiXtGyw=; b=lu0fIcG3dYt4Rc4YFLej3+1i20dUQ+JtOnhYsNgdRvVyFzsezr5TGn1RJAKA+h+Y7gYN2K kQfHA1iwb0ZKUTBCmg2ZpWhU9GcDWEMgLSeBJcIk3jIuwBlvCl1YaMf1CI6WBgC0LH2hlh /6GckvDK2vuua+zqjIa6k4+BvSFEooiRQalMQaFfi5QNits/w9umf57wDS9N305JEUa0eK wfuleEFs+adw+SMMggq+i68XTYRJX4wFkSgLKqAobOpSSE0Zq+oojemhQnr5QpC9V1/RvF TPAYSuIhf0OmoOqqtdW9iqYdQdgSuF6yQTu4dvIHrJLOK+a3r4D4lVHcTeWfJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1706555276; a=rsa-sha256; cv=none; b=HIE5x6ORh2Za39OfRAOjfc5fzOQK/h9byAvTfqtCF7qpJL/A/x49KzJummBF7/6FdatQp7 DZhYWS8RfnT83S2K6x4RPT0bpL+A3NY6NzKyiGnTj+mwzhokjaKA9KF8vhKCUVHys5OqSC iCg5eAEg5dKyoor8hbUrBmzpTXwQAB8GjbQdlpFyE7HPHEPYvuToHRZaaDjJVjNExnzDp9 yIrnjnmr8HN5KrFLYPmwS+5mgTJOZeCLUKNzgl/1USAlIc+d3IVSKRIy054x8Pci0QNJnf ypeiCJGEvPJ2EMDoT2ReJ00wxkt9cT66lzyHs+siH8Xn6g4neb75MyQUUQFQ6A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TNyVh1hpDz13mV for ; Mon, 29 Jan 2024 19:07:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 40TJ7uin039341 for ; Mon, 29 Jan 2024 19:07:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 40TJ7uv5039340 for threads@FreeBSD.org; Mon, 29 Jan 2024 19:07:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 271490] Deadlock between _rtld_atfork_pre and _thr_attr_init Date: Mon, 29 Jan 2024 19:07:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 13.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271490 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |markj@FreeBSD.org Resolution|--- |FIXED Assignee|threads@FreeBSD.org |kib@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jan 31 16:23:02 2024 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 4TQ6lq161Zz58pyH for ; Wed, 31 Jan 2024 16:23:19 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 4TQ6ln70Jtz4Cbh; Wed, 31 Jan 2024 16:23:17 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=kB0kTnw4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of vini.ipsmaker@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=vini.ipsmaker@gmail.com Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5111e5e4e2bso2538452e87.3; Wed, 31 Jan 2024 08:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706718196; x=1707322996; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oFoAbbGZAW6Z+E/a04r/LVKiTzG1iAKRew4mfzD8CeU=; b=kB0kTnw4jziKAbnskULY28jLbjlojc7Rsvie7weXm85bIFRV7s5NkgfZTz7XtwBpha smoRu5kEA9vvmy3yR1u/fBHcMuC+dRLoacRrcqruiWKJhW9+rUNmxyZXLfaCyU/s7IsT K18TKHBeI9EVZRuzHhJs8eII9i3BN8xlK2MMqf09n2acAqoZGUxa+2lGsDbAceE7md2E UpPLdvIjd+sU0k/Fs9U/rhtdrJ5AJ7d+Diikg2rS7i3Pq7gmjWHpDRlRYWhUK6ctTw2m HlO4c3Uw47xj/DnJrftvFHzDouK0GeKXuhZxWOFpqM0MMpqyc7hnTFu53DGgLNCvgNSf RQFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706718196; x=1707322996; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oFoAbbGZAW6Z+E/a04r/LVKiTzG1iAKRew4mfzD8CeU=; b=aWiUHXfi4X6oEcx2CTGiTuHNhgaD/mAy9r+T04JzCQWUzkggSYlbbQP3JUzzp3uyKu 8icBjRJFNseZVzaz4AFSIDliQZErVvKb2OAX0IkFvnvgbf4FQtEKqLNOYNST9tZIWZFg UMgBUzMQRS2hHmT6+jPGP3Q2YNR6YvUbnt1xhWCrq5t82xMWCOye1YfbEF+jpUUTeeAB CwTfr/efH2P6KcsxSji6HRr/0BXeaNIZZMcBFLy7+XpHgLMSbntKxYP38wuAjRfA+RaN LWOQXUKgWP2Wt0UMSQ9Q6YaV4eItf5aUrMhdo4kQvrX7wZOeTa26GqID6ioBTnQ+N4cQ NsDA== X-Gm-Message-State: AOJu0Yxkx2RvsXI9P27gBU8i6ORd7hFqVQWi5FTM9rtPGGP2cHLL7Gca sxYZq3IIOLQhqcpftbZLxgzgLuUjcxUtWzbFiieMb/yDfoxA50sLvPuWq6PUuHED69ffwMIiQR6 qWewnlLTAu5Fna4DEkDWMvQW+RHytbYG/NN0piw== X-Google-Smtp-Source: AGHT+IFb/HdGn7Ypjnf3QkZYfI4H+Wu2l8f8xVxg+/PJWSAlLDDEswIfXEa27+jRyDx1bd+9NukhLW4GOsiiG+WjJhY= X-Received: by 2002:a05:6512:33cb:b0:511:9dc:d8bf with SMTP id d11-20020a05651233cb00b0051109dcd8bfmr1830736lfg.67.1706718195660; Wed, 31 Jan 2024 08:23:15 -0800 (PST) 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 References: In-Reply-To: From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Wed, 31 Jan 2024 13:23:02 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Alan Somers Cc: Konstantin Belousov , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_MIXED_CHARSET(0.56)[subject]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4TQ6ln70Jtz4Cbh Do any objections remain for the patch? The workarounds mentioned previously don't work for me (CAP_SEEK required, but I don't control the file descriptors received through SCM_RIGHTS). Em dom., 14 de jan. de 2024 =C3=A0s 16:06, Vin=C3=ADcius dos Santos Oliveir= a escreveu: > > Em dom., 14 de jan. de 2024 =C3=A0s 15:23, Alan Somers > escreveu: > > I think you're using the term "green threading" too broadly. Golang > > uses green threads, but Rust does not. The difference is that in Rust > > with async/await, the task-switching boundaries are explicit (the > > .await syntax). So Rust uses explicit concurrency, not green > > threading. I can't speak to the other languages you mention. > > Still, we might have async IO if the implementation permits. > > > You propose an extension that would essentially create asynchronous > > (and racy) versions of read, write, readv, and writev . But what > > about copy_file_range and fspacectl? Or for that matter all the > > dozens of control-path syscalls like open, stat, chmod, and truncate? > > They would block the thread, obviously. Look, I've been playing with > async IO for most of my career. I'm not asking for exoteric APIs. I > just want a non-blocking version for read(). What's so hard about > that? From what I understand from FreeBSD source code, I can already > "unofficially" do that (offset is ignored if the concrete type is not > a real file). > > Very very few OSes actually implement async versions for anything > beyond the typical read()/write(). Even open() could block. For > anything beyond read()/write(), you just create a thread and live with > that. From a userspace perspective, it's expected that filesystem > operations such as file-move, directory-listing, etc will block the > thread. It's already expected. However you don't expect that for the > basic read()/write(). > > Again: Linux and Windows already allow that and it works fine on them. > > And again: I ask why FreeBSD is special here. I've been answering your > questions, but you've been avoiding my question every time. Why is > FreeBSD special here? Linux and Windows work just fine with this > design. Why suddenly does it become special for FreeBSD? It's the very > same application. > > > This flag that you propose is not a panacea that will eliminate all > > blocking file operations. There will still be a need for things that > > block. Rust (via the Tokio library) still uses a thread pool for such > > things. It even uses the thread pool for the equivalent of read() and > > write() (but not pread and pwrite). > > Nothing new here. I use thread pools to perform DNS queries. I allow > my user to create threads to perform blocking filesystem operations > (move, directory listing, etc). I know what I'm asking for: a read() > that won't block. I'm not asking for a competitor to io_uring. I'm > just asking for a read() that will never block my thread. > > > My point is that if you want fully asynchronous file I/O that never > > blocks you can't achieve that by adding one additional flag to POSIX > > AIO. > > It's just a read() that won't block the thread. Easy. > > Do you have concrete points for the design? What does it need to > change in the design so it becomes acceptable to you? What are the > criterias? If the implementation fulfills all these points, will it be > acceptable for you? > > > Instead, all operations would > > either specify the offset (as with pwrite, pread) or operate only at > > EoF as if O_APPEND were used. > > I strongly disagree here. Async APIs should just achieve the same > semantics one *already* has when it creates threads and performs > blocking calls. Do *not* create new semantics. The initial patch > follows this principle. Your proposal does not. > > > -- > Vin=C3=ADcius dos Santos Oliveira > https://vinipsmaker.github.io/ --=20 Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Wed Jan 31 18:19:21 2024 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 4TQ9L05PM2z59168 for ; Wed, 31 Jan 2024 18:19:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) (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 4TQ9Kz6cvWz4Pq4; Wed, 31 Jan 2024 18:19:35 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=asomers@gmail.com Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-7d2e16b552dso71622241.1; Wed, 31 Jan 2024 10:19:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706725174; x=1707329974; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=axxvuR4Pvkpi3mt+yELmqOi/IJhLsMW1kgpQ8LVknPo=; b=kWrUbJD9c52A1lrmJyNhFX2ScoNuF54VUJS9ArON/NASlRLeYI7l7YXF6JvC8Klq4I e8HVcxnlcmwTjvpIboLLmqHiIPtBF0JwfXIjFU76cX1LjkTjxS6VcCWPvcBELDxz47yo LW16RxfaXGQobf0UmFE1v9G8q+QiC88wmNG7SVm9G8mYQfgrdVyMPeEnXCq3jWNxOk/E penKynbr4frHXH0eeVetMEKCQvO4/B6kQANmXgfYmGNBB6ppsS/+gbyW9zXdGJRI2EPH Gg68f06LE4XwZLvtdKvjyBUtrgzeUcsLMkS8z+igiDTkgNtbGpvs0OvPH1cNrvgutBG0 zcgg== X-Gm-Message-State: AOJu0YxUzPPRqEHELYgAJeeDc2R3yz2EvS2nrF/z/jTH5EBdWEeRbH0q UW3t372leS+6c2LLsU5HhQOu38OILgzkfu2+buFBAST2KprdUFHH52HVI/XfUMDXSFGB+41o/sk 0ZCiQmsh1TNRi8KH8DsTXmGHsevo= X-Google-Smtp-Source: AGHT+IGJu9UiLcvUIVf0mwxDTXYnrNZu27ioihKMiV+uuYoWA9sKM6iHZ3q60ER3WY60hUUiW3Mbr84j+eGHrXSbEco= X-Received: by 2002:a05:6122:380d:b0:4b7:a77b:299 with SMTP id em13-20020a056122380d00b004b7a77b0299mr1941401vkb.16.1706725174217; Wed, 31 Jan 2024 10:19:34 -0800 (PST) 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 References: In-Reply-To: From: Alan Somers Date: Wed, 31 Jan 2024 11:19:21 -0700 Message-ID: Subject: Re: aio_read2() and aio_write2() To: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Cc: Konstantin Belousov , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [-0.92 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.98)[0.978]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-threads@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.42:from]; TAGGED_RCPT(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.42:from] X-Rspamd-Queue-Id: 4TQ9Kz6cvWz4Pq4 On Sun, Jan 14, 2024 at 12:07=E2=80=AFPM Vin=C3=ADcius dos Santos Oliveira wrote: > > Em dom., 14 de jan. de 2024 =C3=A0s 15:23, Alan Somers > escreveu: > > I think you're using the term "green threading" too broadly. Golang > > uses green threads, but Rust does not. The difference is that in Rust > > with async/await, the task-switching boundaries are explicit (the > > .await syntax). So Rust uses explicit concurrency, not green > > threading. I can't speak to the other languages you mention. > > Still, we might have async IO if the implementation permits. > > > You propose an extension that would essentially create asynchronous > > (and racy) versions of read, write, readv, and writev . But what > > about copy_file_range and fspacectl? Or for that matter all the > > dozens of control-path syscalls like open, stat, chmod, and truncate? > > They would block the thread, obviously. Look, I've been playing with > async IO for most of my career. I'm not asking for exoteric APIs. I > just want a non-blocking version for read(). What's so hard about > that? From what I understand from FreeBSD source code, I can already > "unofficially" do that (offset is ignored if the concrete type is not > a real file). Oh, are you not actually concerned about real files? aio_read and aio_write already have special handling for sockets. > > Very very few OSes actually implement async versions for anything > beyond the typical read()/write(). Even open() could block. For > anything beyond read()/write(), you just create a thread and live with > that. From a userspace perspective, it's expected that filesystem > operations such as file-move, directory-listing, etc will block the > thread. It's already expected. However you don't expect that for the > basic read()/write(). > > Again: Linux and Windows already allow that and it works fine on them. > > And again: I ask why FreeBSD is special here. I've been answering your > questions, but you've been avoiding my question every time. Why is > FreeBSD special here? Linux and Windows work just fine with this > design. Why suddenly does it become special for FreeBSD? It's the very > same application. The only sense in which FreeBSD is "special" is that we're better at finding the best solutions, rather than the quickest and hackiest. That's why we have kqueue instead of epoll, and ifconfig instead of ifconfig/iwconfig/wpa_supplicant/ip . > > > This flag that you propose is not a panacea that will eliminate all > > blocking file operations. There will still be a need for things that > > block. Rust (via the Tokio library) still uses a thread pool for such > > things. It even uses the thread pool for the equivalent of read() and > > write() (but not pread and pwrite). > > Nothing new here. I use thread pools to perform DNS queries. I allow > my user to create threads to perform blocking filesystem operations > (move, directory listing, etc). I know what I'm asking for: a read() > that won't block. I'm not asking for a competitor to io_uring. I'm > just asking for a read() that will never block my thread. > > > My point is that if you want fully asynchronous file I/O that never > > blocks you can't achieve that by adding one additional flag to POSIX > > AIO. > > It's just a read() that won't block the thread. Easy. > > Do you have concrete points for the design? What does it need to > change in the design so it becomes acceptable to you? What are the > criterias? If the implementation fulfills all these points, will it be > acceptable for you? I would like to see a design that: * Is extensible to most file system and networking syscalls, even if it doesn't include them right now. At a minimum, it should be able to include fspacectl, copy_file_range, truncate, and posix_fallocate. Probably open too. * Is reviewed by kib and Thomas Munro. * Has completion notification delivered by kqueue. * Is race-resistant. > > > Instead, all operations would > > either specify the offset (as with pwrite, pread) or operate only at > > EoF as if O_APPEND were used. > > I strongly disagree here. Async APIs should just achieve the same > semantics one *already* has when it creates threads and performs > blocking calls. Do *not* create new semantics. The initial patch > follows this principle. Your proposal does not. Shared state between asynchronous tasks is fundamentally racy if unsynchronized. And if synchronized, it fundamentally imposes a performance cost. I even recall reading a paper demonstrating that the need to assign file descriptors sequentially necessarily created shared state between threads. The authors were able to improve the performance of open() by assign file descriptors using some kind of thread-local data structure instead, and that way open() millions of files per second. That's what a good asynchronous API looks like: it's resistant to races without requiring extra synchronization. > > > -- > Vin=C3=ADcius dos Santos Oliveira > https://vinipsmaker.github.io/ From nobody Thu Feb 1 01:19:48 2024 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 4TQLg70g1Kz58hhm; Thu, 1 Feb 2024 01:20:03 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQLg63hrsz4R37; Thu, 1 Feb 2024 01:20:02 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.17.1/8.17.1) with ESMTP id 4111JmLD006020; Thu, 1 Feb 2024 03:19:51 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 4111JmLD006020 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 4111JmVY006019; Thu, 1 Feb 2024 03:19:48 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Thu, 1 Feb 2024 03:19:48 +0200 From: Konstantin Belousov To: Alan Somers Cc: =?utf-8?B?Vmluw61jaXVz?= dos Santos Oliveira , freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: aio_read2() and aio_write2() Message-ID: References: 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4TQLg63hrsz4R37 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Wed, Jan 31, 2024 at 11:19:21AM -0700, Alan Somers wrote: > On Sun, Jan 14, 2024 at 12:07 PM Vinícius dos Santos Oliveira > wrote: > > > > Em dom., 14 de jan. de 2024 às 15:23, Alan Somers > > escreveu: > > > I think you're using the term "green threading" too broadly. Golang > > > uses green threads, but Rust does not. The difference is that in Rust > > > with async/await, the task-switching boundaries are explicit (the > > > .await syntax). So Rust uses explicit concurrency, not green > > > threading. I can't speak to the other languages you mention. > > > > Still, we might have async IO if the implementation permits. > > > > > You propose an extension that would essentially create asynchronous > > > (and racy) versions of read, write, readv, and writev . But what > > > about copy_file_range and fspacectl? Or for that matter all the > > > dozens of control-path syscalls like open, stat, chmod, and truncate? > > > > They would block the thread, obviously. Look, I've been playing with > > async IO for most of my career. I'm not asking for exoteric APIs. I > > just want a non-blocking version for read(). What's so hard about > > that? From what I understand from FreeBSD source code, I can already > > "unofficially" do that (offset is ignored if the concrete type is not > > a real file). > > Oh, are you not actually concerned about real files? aio_read and > aio_write already have special handling for sockets. > > > > > Very very few OSes actually implement async versions for anything > > beyond the typical read()/write(). Even open() could block. For > > anything beyond read()/write(), you just create a thread and live with > > that. From a userspace perspective, it's expected that filesystem > > operations such as file-move, directory-listing, etc will block the > > thread. It's already expected. However you don't expect that for the > > basic read()/write(). > > > > Again: Linux and Windows already allow that and it works fine on them. > > > > And again: I ask why FreeBSD is special here. I've been answering your > > questions, but you've been avoiding my question every time. Why is > > FreeBSD special here? Linux and Windows work just fine with this > > design. Why suddenly does it become special for FreeBSD? It's the very > > same application. > > The only sense in which FreeBSD is "special" is that we're better at > finding the best solutions, rather than the quickest and hackiest. > That's why we have kqueue instead of epoll, and ifconfig instead of > ifconfig/iwconfig/wpa_supplicant/ip . > > > > > > This flag that you propose is not a panacea that will eliminate all > > > blocking file operations. There will still be a need for things that > > > block. Rust (via the Tokio library) still uses a thread pool for such > > > things. It even uses the thread pool for the equivalent of read() and > > > write() (but not pread and pwrite). > > > > Nothing new here. I use thread pools to perform DNS queries. I allow > > my user to create threads to perform blocking filesystem operations > > (move, directory listing, etc). I know what I'm asking for: a read() > > that won't block. I'm not asking for a competitor to io_uring. I'm > > just asking for a read() that will never block my thread. > > > > > My point is that if you want fully asynchronous file I/O that never > > > blocks you can't achieve that by adding one additional flag to POSIX > > > AIO. > > > > It's just a read() that won't block the thread. Easy. > > > > Do you have concrete points for the design? What does it need to > > change in the design so it becomes acceptable to you? What are the > > criterias? If the implementation fulfills all these points, will it be > > acceptable for you? > > I would like to see a design that: > * Is extensible to most file system and networking syscalls, even if > it doesn't include them right now. At a minimum, it should be able to > include fspacectl, copy_file_range, truncate, and posix_fallocate. > Probably open too. > * Is reviewed by kib and Thomas Munro. > * Has completion notification delivered by kqueue. > * Is race-resistant. I think that the request was much more modest. It is only about having the https://reviews.freebsd.org/D43448 committed. And indeed I do not see a reason to block the review from landing. I added arch@ to get this discussion more visibility. > > > > > > Instead, all operations would > > > either specify the offset (as with pwrite, pread) or operate only at > > > EoF as if O_APPEND were used. > > > > I strongly disagree here. Async APIs should just achieve the same > > semantics one *already* has when it creates threads and performs > > blocking calls. Do *not* create new semantics. The initial patch > > follows this principle. Your proposal does not. > > Shared state between asynchronous tasks is fundamentally racy if > unsynchronized. And if synchronized, it fundamentally imposes a > performance cost. I even recall reading a paper demonstrating that > the need to assign file descriptors sequentially necessarily created > shared state between threads. The authors were able to improve the > performance of open() by assign file descriptors using some kind of > thread-local data structure instead, and that way open() millions of > files per second. That's what a good asynchronous API looks like: > it's resistant to races without requiring extra synchronization. > > > > > > > -- > > Vinícius dos Santos Oliveira > > https://vinipsmaker.github.io/ From nobody Thu Feb 1 17:46:10 2024 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 4TQmYF6fqMz58KJR for ; Thu, 1 Feb 2024 17:46:25 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 4TQmYF3xpPz46KK; Thu, 1 Feb 2024 17:46:25 +0000 (UTC) (envelope-from vini.ipsmaker@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-51120e2864fso1365045e87.1; Thu, 01 Feb 2024 09:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706809583; x=1707414383; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tKzxQi7iIZk0d7O7ObRtmAdSVHj3xTWQe3dh+BSU7Vs=; b=A8Kjpbok+Cz306rg5meoAwKMbRQ+lT0Sl3dGn+hCOWdbEJudTcyWGmvJ/IbWxPxrTC aWgK5EhcIzQ1JTdeyNJowbVQyDFRCJ4zs120IP5maDHpJfXxs6RO2M9uOm/YZkX9uxNv fop8n5BUJQY2ughf6Tq/1qOzG5IbIYlpOwjZgfHZ0307+/7M5lnXoO+l7lrc9ik/eMnE rdE1rCbnQefL+vDYZ0LWuFPv+j13B1cY0zlc601Onimrm9LgBHUN2gWQ2G7Cg0ctxqZA xbqVu4U1H7nbcUQIPjDvBtB6wuBQ+DPkxE4X5/ekw+MnKUX8/vWMiSocTHofbEY6pg6g DnZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706809583; x=1707414383; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tKzxQi7iIZk0d7O7ObRtmAdSVHj3xTWQe3dh+BSU7Vs=; b=awp/BTC76eezLgiBZniFQ7+FXYnlBqQqnP7aOVlYGh8IBTwCKEbkw8Bsfzy3Hofvak 4oMugFvkeZ+xD0fz+3muT6PS7u4DJYlHGj4TuGeZzSdKn8GyjUIYbYMHwNBoEUETBg1l pd+8IRjn+g4sihmWMkZEuf+y5erOhyH9WgSQh0xlryqp7CyKvfe+Iu8Qur2cVXtMvImA nVqA4EeAABVjgfpuEzV0sVp/suOGcBmn/YIwdD0+lysYs4fAoTcdplXi19ST2V0ITAGk hZvjEMmHILp9LrxQBme29hzX+fOJLjcXhv3eF6pwW1TMrE5Z4NqQ8Oiph8I98QcxJl3R AeUA== X-Gm-Message-State: AOJu0YxMgHQtd3FYBIYARkGrqesK6dAXKwC1TArkKYB/TWiGuwn+R5jk cNmnOUTjMxS9TMeiVurtS5vaHa4di9eQobdYXUQq8nZ8kOD8zIj6a/i7yadymAcaLk3K4BvF7U9 8ElqtQxsNn4GakgnzIAP6dNZg1c7wMP/Q3Gbkaw== X-Google-Smtp-Source: AGHT+IFOK4Hvl+zbrMGZed6jVMPHgVr55/jgcReyzJ2RQmjAPC7/9ADqNTYO+xFvzNjX0C8NUielcIG58mhkBd+J71c= X-Received: by 2002:ac2:4a6e:0:b0:510:271b:1c1b with SMTP id q14-20020ac24a6e000000b00510271b1c1bmr2273256lfp.33.1706809582965; Thu, 01 Feb 2024 09:46:22 -0800 (PST) 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 References: In-Reply-To: From: =?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?= Date: Thu, 1 Feb 2024 14:46:10 -0300 Message-ID: Subject: Re: aio_read2() and aio_write2() To: Alan Somers Cc: Konstantin Belousov , freebsd-threads@freebsd.org, Konstantin Belousov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TQmYF3xpPz46KK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] Em qua., 31 de jan. de 2024 =C3=A0s 15:19, Alan Somers escreveu: > Oh, are you not actually concerned about real files? aio_read and > aio_write already have special handling for sockets. There are at least two projects that depend on this patch (the ones that I'm directly involved with): * Add a FreeBSD port for libboost's ASIO. This is just a library so I cannot speak (much) for application developers making use of libboost. However libboost has a design that is very clear (basically it exposes proactors such as what you'd find in Linux's io_uring or Windows' IOCP). * A runtime that I created for Lua developers. It makes use of libboost's ASIO. The primary use is files. The runtime needs special handling for sandboxes (another feature that it offers), and currently FreeBSD has no solutions for the problems that are addressed by Konstantin's patch. I mentioned the specifics during our conversation already. You may look at the project's documentation if you need an introduction to the project: https://docs.emilua.org/api/0.6/tutorial/sandboxes.html > The only sense in which FreeBSD is "special" is that we're better at > finding the best solutions, rather than the quickest and hackiest. > That's why we have kqueue instead of epoll, and ifconfig instead of > ifconfig/iwconfig/wpa_supplicant/ip . I'm not comparing against epoll nor Linux's ifconfig. Windows IOCP is old. We had a lot of time to understand which flaws are Windows faults and which flaws are IOCP design's faults. Windows hasn't been the only proactor for async IO. We accumulated experience for proactors. POSIX AIO combined with kqueue implements a proactor, so there's experience even within FreeBSD. Linux's io_uring is just yet another instance of proactors in the wild. Solutions shouldn't be rushed, but even if we only review at most a line per day of the mentioned patch, we've already gone past the minimum wait time. I don't care if we even spend 10 times more reviewing it, but for a patch this simple, I'd like to see something more than vague requirements that cannot be met. The patch isn't polemic at all (POSIX AIO is useless by itself, and has been extended before... many times... with no one complaining). What specifically do you have against a patch that would solve my problem? The patch can be changed, but a vague review is not helping anyone. Meanwhile I cannot resume my experiments on FreeBSD sandboxing to address real-world problems. Orchestrating fixes across a range of OSS projects that interact with each other take years. Blocking a patch this small and with clear semantics will just escalate for more years to coordinate the remaining OSS projects to adapt. If I had received the same treatment for every patch that I ever contributed, I wouldn't be able to see the result of my contributions in my own lifetime. This is not fruitful collaboration. I'm not an amateur at concurrency nor async IO. * I wrote the initial patch that fixes a bug in LLVM libc++'s condition_variable: https://reviews.llvm.org/D105758 * I fixed an event race that was present in GLib for years: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1960 * I wrote the first sucessful integration between GLib and Boost.Asio (it couldn't be written before I fixed the bug mentioned just above) * I fixed a security bug in Linux namespace tooling that would allow any user to overwrite any root-owned file: https://github.com/shadow-maint/shadow/issues/635 * I identified and fixed many bugs in Boost.Asio (a few related to running Boost.Asio on FreeBSD). A few of them are still pending for inclusion, but they'll hit the upstream repo eventually. * I successfully developed a runtime that exposes fiber concurrency for orchestrating async IO within an actor while deploying actor concurrency for exploiting scalable parallelism, and also uses the shared-nothing paradigm of the actor model for practical capability-based sandboxing. I'm not aware of any other system doing this. * I wrote patches fixing real-world issues for many other OSS projects while doing my research. I have a problem that is addressed by kib's patch. I'd like to see it solved. For a patch that is not intrusive at all (it doesn't even add a syscall), it's based on previous practice (POSIX AIO has been extended before with no one complaining, and we're doing just that... extending it once again), it's this small (very very few lines and pretty much safe to apply), and has well-understood semantics (most of the behaviour was there already), I'd like to see feedback that has concrete points on where the patch should change. The initial interaction was requirement-gauging which is unavoidable. There have been useful exchanges as well, but at some point the review derailed. I'm not seeing any concrete points on what should change for acceptance. And out of nowhere a competitor to POSIX AIO that I do not want to design has been suggested. Be free to design it, but don't block POSIX AIO patches while developing your new subsystem at your own pace. In the meantime there's an existing problem that could be fixed (and no viable concrete alternative that would fix the problem that I'm facing has been proposed). > I would like to see a design that: > * Is extensible to most file system and networking syscalls, even if > it doesn't include them right now. At a minimum, it should be able to > include fspacectl, copy_file_range, truncate, and posix_fallocate. > Probably open too. That's not POSIX AIO. Any POSIX AIO extension will be rejected by your criterias. The current POSIX AIO is already rejected by your criterias. Should we remove POSIX AIO then? POSIX AIO is practically useless without extensions. It's only useful in the BSD world where it has an extension for kqueue integration. FreeBSD even has other extensions besides kqueue integration (e.g. aio_readv()). LIO_FOFFSET won't prevent you from developing and proposing a new FreeBSD async IO API that competes with POSIX AIO. You can design your POSIX AIO competitor at your own pace with no rush. In the meantime, I have a problem to be fixed. > * Is reviewed by kib and Thomas Munro. We can get to Thomas Munro once we solve your own requirements. Can you elaborate requirements that are actually possible to meet? A patch for POSIX AIO must meet the POSIX AIO mindset. You're asking for a new subsystem that has nothing to do with POSIX AIO. > * Has completion notification delivered by kqueue. Okay. > * Is race-resistant. Race-resistant? Filesystem is a global resource. You're specifically asking for a solution that cannot be developed (and all existing APIs already violate). Can you be more specific? > [...] That's what a good asynchronous API looks like io_uring is a good async API. Among other things, it offers read() using current file offset. What part of io_uring became "bad" because it allows skipping an explicit offset? And you're too vague when you talk about "races". Again: filesystem is a global resource. Even if your process is not creating races, the interaction between different processes might create races, and there's nothing to do here. -- Vin=C3=ADcius dos Santos Oliveira https://vinipsmaker.github.io/ From nobody Sun Feb 4 09:50:50 2024 X-Original-To: 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 4TSPs71T4pz59Rv0 for ; Sun, 4 Feb 2024 09:50:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSPs66Dhrz48lC for ; Sun, 4 Feb 2024 09:50:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707040250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ye8k1v9eFVp63hdFdQPyONJThjqcr8OGWylafoHV8/I=; b=RbUgF7k19dB+9si/lYvmLFEf1erz+xM991tSgNnPZczDlBo+Fpk3SJexVMiOD7Y0K5rhp9 YpVNCGZ2q0p7/ePMNwIJ/3np76OZF6QFaufqdADZvrGRSMqCN7vuvslw3SI6h2eCM7UFXg XlYauMS7clHrIjEEOCWbIstE4BFeiwQ7XLPAsaf2mFxjOfD/L43KzMkFwB0LJq/lCBdU2u kOt9hrnFJUhxTjrVfqMnTFV65U/4xIsYESs5Ikx87jeU8B7WNNnHmhtnRUt7wWMHTXFn2g /EIfyYnXZlViwCCfqyqEtyrxNgAeEJZjCXXuHaNAKTDMzCO418JaCor8JaNnlA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707040250; a=rsa-sha256; cv=none; b=hNvoBw9YoulfNn4u6pbk1jGDMQ0rp8M9GMoZ1DTsVxmtPXw5qsnzh4s6mcH+gywVgpbbE6 V7FTpR0Eom4AgHVaqgosD/K2a4dDoxFbIuE37RZvDyMV2/mWD7D5ZANTrm0PYf78FqIxQ0 4DR/imfyg8CydDFSjnStm/6QUEoyVZPyXSnAvUdPKeKgWc3/bSWG7zlb+C97zvPc7XBkFz D/4LbnVsO3vrqWnHG95Zgwun2tT+KOsbwccbsnRStIKfNbjUgyfXWZrkftkR9kRk39G2tl JhazZAg2YID8MbKxupor4xTtpE0HIgbPUfMZDQ7d8HqBbcmNrro7vFMWoCFn5Q== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSPs65J5HzsQP for ; Sun, 4 Feb 2024 09:50:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4149ooku012989 for ; Sun, 4 Feb 2024 09:50:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4149ooPl012951 for threads@FreeBSD.org; Sun, 4 Feb 2024 09:50:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] mtx Date: Sun, 04 Feb 2024 09:50:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hodong@nimfsoft.art X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 Bug ID: 276818 Summary: mtx Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: threads Assignee: threads@FreeBSD.org Reporter: hodong@nimfsoft.art --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 09:53:53 2024 X-Original-To: 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 4TSPwd2N9Qz59S2D for ; Sun, 4 Feb 2024 09:53:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSPwd01Ywz49nf for ; Sun, 4 Feb 2024 09:53:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707040433; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2/vB6b9QBBcMS0ylzIECRdar0O8tLQKmEIJvm5b45fk=; b=NWPOr3cTc6bg7Yjh343BFyTiVLKVQfpeLvl27SoWjosfncjlGxkd4Kolf/IWGTdHIQc2nG JxnV5CjqJ7dsSo9U1c0d23X1PSRtZQV0FTXbqCpadeo29g2+vPxP6GTM2QCAisGF2sOI62 Pv55ycfLHALgBYZ0uaofkocx44Z5acBsRoCpoJlYHYwF7TpgNUL9UcG4wU4jNet6cnzfvc 5SFeLob7XKhCiUS+/977HU99yVkJF4vrqTNBlOmUjS+43r59Wxew5xr6ElJpUn8XtzklU7 lXYRi+WHMV3qGBme3hapQmJ/Wv5AegpwAWht49hQuO+DqAFqfnsDW8lTwuoolw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707040433; a=rsa-sha256; cv=none; b=WX2SzW8jLtmSi+IC0kWOMiEA0We0RZimRK3mzmYSS5EtWEJurnelHP6/gPb9poZDIrnR4u 6cnVG+FIdciKE6ypWmg7iqzdnMTa6ZpofE+eNvp+F19JcLtzivCkhZhnh9h0L1HEmxKct3 bIhdj0oB9jOlqY6gsDbsyERpWewDbmIA2EzgUffApK/JJpXVLJaQJuJqNNuG3SEwzVHrYH DaY+aJE5tB3CYxxunBk4TCHy7cgm8dWQRzDBbnjy7DDuSjEWHYp6BWN2g6zokVuhWuk1+c WJA/YOLWFSwrM/sYehAJNz7gUWjSxx6ZKzsJlRxZUynzxaBRcjRZzayfNHEkXQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSPwc6CCMzsQv for ; Sun, 4 Feb 2024 09:53:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4149rqEI041010 for ; Sun, 4 Feb 2024 09:53:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4149rqHg041009 for threads@FreeBSD.org; Sun, 4 Feb 2024 09:53:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 09:53:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hodong@nimfsoft.art X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 Hodong changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|mtx |[libc] mtx_init memory leak --- Comment #1 from Hodong --- Hello. A memory leak occurs in mtx_init. #include int main () { mtx_t mtx; mtx_init (&mtx, mtx_plain); mtx_destroy (&mtx); return 0; } $ cc mtx.c -lstdthreads -o mtx $ valgrind --leak-check=3Dfull ./mtx =3D=3D26748=3D=3D Memcheck, a memory error detector =3D=3D26748=3D=3D Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward = et al. =3D=3D26748=3D=3D Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyr= ight info =3D=3D26748=3D=3D Command: ./mtx =3D=3D26748=3D=3D=20 =3D=3D26748=3D=3D=20 =3D=3D26748=3D=3D HEAP SUMMARY: =3D=3D26748=3D=3D in use at exit: 1,748 bytes in 3 blocks =3D=3D26748=3D=3D total heap usage: 3 allocs, 0 frees, 1,748 bytes alloca= ted =3D=3D26748=3D=3D=20 =3D=3D26748=3D=3D 20 bytes in 1 blocks are definitely lost in loss record 1= of 3 =3D=3D26748=3D=3D at 0x484CDE4: malloc (vg_replace_malloc.c:446) =3D=3D26748=3D=3D by 0x4C791B2: pthread_mutexattr_init (in /lib/libthr.s= o.3) =3D=3D26748=3D=3D by 0x485EA9D: mtx_init (in /usr/lib/libstdthreads.so.0) =3D=3D26748=3D=3D by 0x2016FC: main (in /home/hodong/projects/snippets/m= tx) =3D=3D26748=3D=3D=20 =3D=3D26748=3D=3D LEAK SUMMARY: =3D=3D26748=3D=3D definitely lost: 20 bytes in 1 blocks =3D=3D26748=3D=3D indirectly lost: 0 bytes in 0 blocks =3D=3D26748=3D=3D possibly lost: 0 bytes in 0 blocks =3D=3D26748=3D=3D still reachable: 1,728 bytes in 2 blocks =3D=3D26748=3D=3D suppressed: 0 bytes in 0 blocks =3D=3D26748=3D=3D Reachable blocks (those to which a pointer was found) are= not shown. =3D=3D26748=3D=3D To see them, rerun with: --leak-check=3Dfull --show-leak-= kinds=3Dall =3D=3D26748=3D=3D=20 =3D=3D26748=3D=3D For lists of detected and suppressed errors, rerun with: = -s =3D=3D26748=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 fr= om 0) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 10:09:11 2024 X-Original-To: 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 4TSQGH4bDzz59TB1 for ; Sun, 4 Feb 2024 10:09:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSQGH2GNWz4DLX for ; Sun, 4 Feb 2024 10:09:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707041351; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DGodp396J6pPchZXG7PVEMx6BMRkINySKyT/cF9P9vs=; b=jEYSgSr3C/UlY86xpkC/J7P+neVju/iiLkumXtpmha+zWJ9OrjAsLeazSm0MQA+4WpLsPo DDOxfdJ2STrxODCThKAcse41txNVjokYKmTMzIvlSEVPKwQJgblS+Ja63KFrulmdg8p28z 3PJ3eu6SX4Q5nCBxTxxcZLDC5cY6RR+aRzDExO6lf/IEy9sKRVFSssZP+ePKEw7Nwtm5iJ aysAl1IWXE8DUg21i07IxvGM2foIZHJgNz2pAJiW0vJ2ABsZBhiEBlAh93xikdWCuVHVup ZVrxv1ByqsUvDVINIrGwBJGgsyntoA/cYWxfkdOC4P9YqlzBBB5Vs4//6QYMng== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707041351; a=rsa-sha256; cv=none; b=N6JyuxNnzQFh+/mrHX2GTZZftUAaOW+bTYEHpbHlFBeu9kbccuxpzYnCsoKJXqrN3fdc0X CToi2wOBjFbcuskbfIWIo+Mj6WAj/3QOoYjFTAtAbCdpxCYLfqpjAAN4RalOD9Mg35LogE OYb5HOSl9jE+rbHyepzAtrSvgEPsSyqzhLQQEgJXpvKVLhrkfzZaNfoIx3f1K9mt5LlKjt NVmCfJuDyNfSQsvHqpQ0AvXEQS72TiCnQ0nXCmI4MTjjV3zwjqq8ac541eJWhi0RLbZiKp cLU7lzZVbGPDSCtn5/zLZZiyTPYDWnHuKTf0DSzG0cdn6rykxEr0tzivr6prow== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSQGH17r0zsmd for ; Sun, 4 Feb 2024 10:09:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414A9BJo009863 for ; Sun, 4 Feb 2024 10:09:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414A9BJ2009862 for threads@FreeBSD.org; Sun, 4 Feb 2024 10:09:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 10:09:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hodong@nimfsoft.art X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 --- Comment #2 from Hodong --- Created attachment 248171 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D248171&action= =3Dedit fix a memory leak pthread_mutexattr_destroy(&attr); I added this. This doesn't cause any memory leaks, but I don't know if it's the right way= to do it or not. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 10:15:36 2024 X-Original-To: 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 4TSQPh4msFz59Txg for ; Sun, 4 Feb 2024 10:15:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSQPh3l1yz4Dy0 for ; Sun, 4 Feb 2024 10:15:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707041736; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0ihBnJ6S6mmhyT+bRZjjbr34Fff46LwgwsM361Zky7I=; b=MZrrBEM6+/mx2aH7LvaSzWcibrYoWH/PCcaWPX6x6gVH18CrLAY/vt8Kx2bPd+Oy1JglI6 6PeB3c7dU6rY7yBvGULpxPuCFrn/wxgOe+XPxDw9qd5hsgj43Z9v71jMzkPUKbN+qS7Po1 WP7QzEjzmVlzuNNqlReroWvQVnYPmbOWniZXYYimY7SAPgboWORM9B8r7AqZMB5AWgj33x AnGVygvUCx4VGclxdnQtVrBtXWQkAgOf0CRGbmX5nvILmUD1p+8PaQuUrLim0UUgFzEueZ pdJOOBLCfWApD93C+M+0kLfrwvRl+IMixto3WI/mgMNouyuGXmCdl6DGSsVaLQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707041736; a=rsa-sha256; cv=none; b=g6sB91h9j2f6Mrrt7FDZCXckZwUWk24eGEU7R5PHdDGQq0iHZZGd/D+/K9jlEghNsRfvfs Y99HNmZrWjw+E2CRW0YuZ365DT9W1P4bPBTsKGKT67cH6J4bNkyzVWN/kOQ/XJffec2dya 4AE8ROFBjOlTrRz1lpncjvgwK57YP4AV8dliwzoZkPSa0ETwbQH0O1k2BHZi0a/RMUKoZH jSUmrEiP68zOhPSxDU0lkFxSs7R0GFbmpdSUzYiGaX0Xv9OBuigiDv3UR6gttVikxekvcc Gzl/uZS4Ur0lHcAdLheCUz+wE0NGFad4uhurY6YGlcx6Sl9fxgfETnptDnCRJQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSQPh2pFTztFS for ; Sun, 4 Feb 2024 10:15:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414AFaKN054501 for ; Sun, 4 Feb 2024 10:15:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414AFadF054499 for threads@FreeBSD.org; Sun, 4 Feb 2024 10:15:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 10:15:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 Konstantin Belousov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org --- Comment #3 from Konstantin Belousov --- If pthread_mutexattr_init() returned error, you should not call _destroy(). --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 11:00:47 2024 X-Original-To: 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 4TSRPr1CbTz59YPd for ; Sun, 4 Feb 2024 11:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSRPr03Xtz4HMY for ; Sun, 4 Feb 2024 11:00:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707044448; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lv8ZLUxdxumHis9Ae8vRf5m90HEaWLG4n9pEycb2qDA=; b=ghMrKP+anY9y/sonKIBVySJVi4bzXyALcpVQV1zOoPm74IXteYNZsxUCvTRFcDd2h2CKZi GuXqy9wSDYSjrRPROKO2QlS/sSLWVe9UwwW08V5CY3kpaW76bLY6VrCd0R5AblDtAkMCem EUI/XOZMOd34fz7KSzZtsgFYbDpvTi+IKjqLKrNznLWdbHNo8BpyT08tYQMI1qHbheXp+U +obgfXVr7318Z1842sEypKDh15iP23P8BO2jtP1+HD/gg4Dpfmrvqqo7cDE70BTnXdVBjp OpFogoYDYh4okh73AhDjAEsAFzWM/qxBN5oKNT783xsUPL4cmGF4cZr9MEEYXw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707044448; a=rsa-sha256; cv=none; b=hD/3BV09Yrf1i/1ClnTJJYZ+IAjqfdoD0ZgvTdF/zRLucMF7qbnpekTQ2Gcf8poFLnsZsv eWAS7+Do2wEBFEWgE7xp3aGtpv/6an3zTFN2baHT8WI8gptHVeUtVIqKRfEPjoH58iUyG+ wQtUfWTZIbQjRMRGpm/VqnuMVcb6qOqtvNd7rK4r7UF3XEb7RJG4C3SfyqxxlhiVJ5vcPE d/XylXisP49y8YIM/Yr30GPqv8Kmdwnlqbbwkalf1XqYntEfi3Nh1Kt3tgilqVOaPr0+/f E5l5WCpYdPuobwCdNIBPCInKp69PsaWuBHJvBTlU/1VfB/d7go59UWbYm/t4rQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSRPq6GLbzvGw for ; Sun, 4 Feb 2024 11:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414B0l6h077902 for ; Sun, 4 Feb 2024 11:00:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414B0lpm077874 for threads@FreeBSD.org; Sun, 4 Feb 2024 11:00:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 11:00:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hodong@nimfsoft.art X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 Hodong changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #248171|0 |1 is obsolete| | --- Comment #4 from Hodong --- Created attachment 248174 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D248174&action= =3Dedit fix a memory leak I modified the patch file and uploaded it again. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 11:11:59 2024 X-Original-To: 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 4TSRfl6zzLz59Z6f for ; Sun, 4 Feb 2024 11:11:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSRfl5fPbz4JXT for ; Sun, 4 Feb 2024 11:11:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707045119; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gGbN1IFTEZMnzZiL3yWTPxE1o7Ykm5/VcNMeSsPM6Ws=; b=JsuofCOrGBUQg1a5KlITudiFu3JHFhsu9U7JxoA1oyjwo9N0E31dvaPQry6G94nRO+/Z6B Ws0dIPdl8qwmOSz87w2ucmvmj5w/q90NsSSzQVBJMei98GTGfJUmreWwI7wFeWnSm9oCXT 3IkaitIDxglv6qg9+Ze5ZOVGhlNDZ7W5qlRtfU/9/+JPpCR4Cfq4ZcKGNpjXwfApARz4KK xNhwaSHexvaPmYANj1MKvPuzRBOEEUb9IXODH4eZp7Oa4ocUkuqlADb85WyrtvettnahHM dKTRJVoiHA1veLtL3ZQqhXF3jt+IaTwJN1fb0YDI+ZVXkTmFyZ4QA+Azs9bjQA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707045119; a=rsa-sha256; cv=none; b=FdwMYuBuvFlGGXNLf17WvpvSCLHDbCeRhYw4EPT/QntVZrRdtvRm0ohED4OtMUPw1+70sl Bgz04/hDL1THNEcH8NRN6XGZpIm7Z0HO6a+Y13a5h9fyYmm/cchAa7cXcNpZJfoG7ADuHy Q7a35Twt1Zp4NbL7E4DhyIxXYrJH9zJK5cXltsI/xxiu1lz9Sp/EXF5+QpS+NOndUXG/Ji K0gBtivOYMHIg1QlhX+TLe4O+TXAjOFnMUdhLNFMLBDDx8CY47+t8fIQ34pWxaw0kdiPfq nt3cWEGskxN4JCqHWm+lqEJ1Q6IgJ/ZrlzNtu6qH1sdILFHHrm0/4Ay/usKKzg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSRfl4kdgzvJb for ; Sun, 4 Feb 2024 11:11:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414BBx2m043428 for ; Sun, 4 Feb 2024 11:11:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414BBxLK043427 for threads@FreeBSD.org; Sun, 4 Feb 2024 11:11:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 11:11:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 --- Comment #5 from Konstantin Belousov --- I propose the following modification, which avoids writing the call to pthread_mutexattr_destroy() twice. Are you fine with it? diff --git a/lib/libstdthreads/mtx.c b/lib/libstdthreads/mtx.c index 719ba6486e41..3027a4e48c8d 100644 --- a/lib/libstdthreads/mtx.c +++ b/lib/libstdthreads/mtx.c @@ -43,7 +43,7 @@ int mtx_init(mtx_t *mtx, int type) { pthread_mutexattr_t attr; - int mt; + int mt, res; switch (type) { case mtx_plain: @@ -60,11 +60,12 @@ mtx_init(mtx_t *mtx, int type) if (pthread_mutexattr_init(&attr) !=3D 0) return (thrd_error); - if (pthread_mutexattr_settype(&attr, mt) !=3D 0) - return (thrd_error); - if (pthread_mutex_init(mtx, &attr) !=3D 0) - return (thrd_error); - return (thrd_success); + res =3D thrd_success; + if (pthread_mutexattr_settype(&attr, mt) !=3D 0 || + pthread_mutex_init(mtx, &attr) !=3D 0) + res =3D thrd_error; + pthread_mutexattr_destroy(&attr); + return (res); } int --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 11:42:45 2024 X-Original-To: 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 4TSSLG0YdTz59cS9 for ; Sun, 4 Feb 2024 11:42:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSSLF6CZBz4MYY for ; Sun, 4 Feb 2024 11:42:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707046965; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sv/4fHQMQwXzGCazsPuZcUpkMikAdzcNCuuSPWbgfhI=; b=uzt5KhHP8wx9sKZxSmReHxkQExR+6H6Sd3+JDr+CCdFnz9f7Z4kg+27AtFDqbaOLJHWpDt ribJGzl1lG9wFp9Xi8c/3NqULoaVzK9eCo70Ih4BQZl6rxB6mpFtiFFeXZg3NWf4TkxtIF SUFLjd+RLP+4rMbt7zy5S7LD+xcoK2Lqe/kVGRBjm2GoDOpUrUWFkJ9jwORs7k+3UbbKNY EgHUR1L2KVQ/hL67lJfieknFCqpNhSXkHV4yTBJeXlRfBPH9IU8GFAfM4NtrmGJPupkx60 DJ5ZIcdrlaxJrpz+s9PsWN3uBRr8BptcMQ3ZEoZLLwvzZTwQTcfJkS/wpumcFg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707046965; a=rsa-sha256; cv=none; b=Pfz+dxm7pFhhJVPYI5sd4MaXMe2pgxDHwPgHlrkgrbhe8pR7z1lMb/ILeeFsuDAFmOJtCQ eq/5Z6FETCdnyB4GHCdNFiVaxXDDSaG6NMwiEKZecbk5eLdLyJcufV4XHSHXue53p0Nbs1 mVag8MhBicEKOVn4a/4IiPByyB6qOoYLfv3amgJBz4kfbWYl2UmpIJCkW7X0X8KBo7IT0P 8QaohoXMroeFnrCITBQQKS39/rIFtkNPf94jNi5Xdnez3aC+mfFQl87BOfpnToI85FVssS CZ2XMHHEz7RcAvuuZfpP5iRDHXnhdbvUKuQhOCcOJx2/QQWumeH/wRPsLfnzSg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSSLF5Hjnzw3F for ; Sun, 4 Feb 2024 11:42:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414Bgj14001099 for ; Sun, 4 Feb 2024 11:42:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414BgjuU001098 for threads@FreeBSD.org; Sun, 4 Feb 2024 11:42:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 11:42:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: hodong@nimfsoft.art X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 --- Comment #6 from Hodong --- (In reply to Konstantin Belousov from comment #5) Good. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 11:52:47 2024 X-Original-To: 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 4TSSYq49c7z59dXc for ; Sun, 4 Feb 2024 11:52:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSSYq2Sv9z4NhX for ; Sun, 4 Feb 2024 11:52:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707047567; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=emdj+TOa97WvOiB6pplA0VCxUs9BrxCqfpIO+bRZ6qk=; b=ex4/3PeFpKSLmbIU+rvHDJ3NLeLV5lgf9k9YloMfnYX/wOqtUwAovoRHfYGwquSGBGP4Kb 2PFSOOG7rsTsW7aXuklQvStmp99UrBf1Zs6Lag9LN1tBChRyf+exsDQVCXVeGighZnzJkG CCDLeUjgYURj/R6dHzGPesrRVC92IttlwDWNXPACc/qs+L/ZOBlCDtJkcKknBkF5FQUOXZ nGWwruuuyW3CisaJ5bBRfWCf32p9QcFFumSDYoB8qnmWu/exUBeOwomwfLMiPMo6RgUi0N EWhOfnhACugxZ6OCRtTdaOpaEBmC5fUofuzvlpp7M8l6sdVG3Te2jHmJewrbOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707047567; a=rsa-sha256; cv=none; b=sqK+fYzvq6xVAdTiKXq1dCakcnMHNaRVup7gZezdRcipIsWwa9NFyQyXVVfISsT6pWszH5 qwTD2ooad1XxdZTw17LynPR926oXnhqQmyGlvXgBtPw+Fn2PaBRXaoc7MbtoD9BA4algHX OIrAUMlbqzYNtS3o2ld8IYXSdgKk3Boe0ULCCsJMXsfb4UW6SHX7aOL8LPERlmuTIS+/23 l+vuTmLBao7U4h730/QCWBNGvBBU0Fkqx2uBix0eepksiX+VGcx34QRGrhBAwY4wE3L3C1 brEFLp/SAnJSknAeS3Ywhqn3+AHS7B3gEsuKDn0pS9VyRjnxE4He4Vka2G1EQg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSSYq18N7zvpD for ; Sun, 4 Feb 2024 11:52:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414Bqlht049701 for ; Sun, 4 Feb 2024 11:52:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414BqlGL049700 for threads@FreeBSD.org; Sun, 4 Feb 2024 11:52:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 11:52:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 --- Comment #7 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Da03f768612ad98a886458197c531a0b92= 203bf84 commit a03f768612ad98a886458197c531a0b92203bf84 Author: Hodong AuthorDate: 2024-02-04 10:14:22 +0000 Commit: Konstantin Belousov CommitDate: 2024-02-04 11:50:56 +0000 libstdthreads: destroy mutexattr in mtx_init() PR: 276818 MFC after: 1 week lib/libstdthreads/mtx.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 4 17:59:19 2024 X-Original-To: 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 4TSchl5xrxz58Trf for ; Sun, 4 Feb 2024 17:59:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TSchl3MDCz4tcB for ; Sun, 4 Feb 2024 17:59:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1707069559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MGCOY/qs18w0KHHcz/oL0hCeYt0DrGBJveVaUGWGbpk=; b=qnuku43DfnNvNIVeVk0Q9hOQDQfH1d9s1oYHnVWw3xQzpSvj72e/zbDUdnRu6n5G39JFZJ O4yRK1+O+EfPLj0mPaK9dqJrQQeLbIlcHh0Xio9u5MCyM4FD8Pbe9znZ4EUnQtyI87EpL2 i/cfwneq1jJ7+Ph7681bikZsqaUDeTsdf/Oe1mFGndx5tmwa9a9FiiHbAUC1Imldu6ZSNX KqySuA92ufv5Ay7NU0OJ4vgwIyiEWGbL+gYj5OMiVCqWBgmLmWxGh68CNj205dH5OehcU5 /kkPKhXGzpr59pieCW0hZ50r7j+piZqtcuyYIdqrgJgdim/Tk7e79UgH9oIffg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1707069559; a=rsa-sha256; cv=none; b=xNYnRNNcWd2RaFVGSLnQLb+v6zazFBWuhAjPhBusMRT2Zcct+ZtBUs0FFdxqlZgEq5hZzC asZ3+F9KAGYmknMBn8EkrikbRV39Wb9YNEjmMOUiNN3NxuCnW3i8AC2ARqkEO6GZ7EM0Ia 0Xf87gwXJlV8M8XgQ0Wxbgldmd4lGuu8be/ne43MdjUov7eJhye0ItylTsakezkXuuet1k yaeD/Hz05kk849a35Pzh4q4i56M7dRncF3P2upVEGJK6OX4vFSegCv4enR3iYPzW7ISvxg Hb2nBPaXpYzLBwZgNvDlYOH3eU4MFvvsVspgn7vsm7D3357r83AaDLYVJrFX3A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4TSchl21HGz16V5 for ; Sun, 4 Feb 2024 17:59:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 414HxJmU097692 for ; Sun, 4 Feb 2024 17:59:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 414HxJdw097691 for threads@FreeBSD.org; Sun, 4 Feb 2024 17:59:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 276818] [libc] mtx_init memory leak Date: Sun, 04 Feb 2024 17:59:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: threads X-Bugzilla-Version: 14.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276818 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|threads@FreeBSD.org |kib@FreeBSD.org Status|New |In Progress CC| |markj@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.=