From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id DC0DC3858D32 for ; Fri, 14 Apr 2023 08:29:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC0DC3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x22c.google.com with SMTP id bm45so5851655oib.4 for ; Fri, 14 Apr 2023 01:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681460989; x=1684052989; 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=zGO6k3WMukSqktB81bklT1KGb+MVIhJsEN4+hCO1K04=; b=Fo+cQI5mQ6yYRQOvx4dCcOkuX0YH8gNkQQu27c7tyhYDBB7RNTi7xiJNTDilsf6S17 QDynrdKvocy1MFEbGsA7t+10nxK9BovQxOfA85cQZ2RwvgfI5zWJIprR1zo/BPg2cgAX e+qgrLsx25BfPGc7ZiON9oQ+tHR7nQl1Ab4j4uTc3Ir2KorpoHu31lBhlq04wyV5X5YY /+BYsuwpTdJkOuTqTupt3hnGR0o9hOyBxgYqI13SU9DIHMSahWtW12LPlI5opghG5q5b /BmlHsAsxAc9z64b9vJ01+WZVOYpvG2z67OnptJhjjwg/t/p7atSe4WsfaQZ/yi2PYpT DNQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681460989; x=1684052989; 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=zGO6k3WMukSqktB81bklT1KGb+MVIhJsEN4+hCO1K04=; b=irgHYvKovULp5zaCJhaW7XDBMPdMgnuRpRGbW00FxfqwSAyiD+doWlJKjzyCf2ExNG weu3uqcApYY635uFALGva/60r7ws7DZmX6Y2wlhWztdcL5fJjQ7R4MKS2o4vNgmixn4Y LT5mFDbkIxfrM1sbhzd3VwMImqOTTb1BwnQ0fiTJGZTSFd3TY4fvt1qypXYvfEV9v0RQ X4C/pfJBF9CqhI4hCOcotYUL3CAnf1g7/vemQdgSNEXt3Qxd2+3XJ+v0vWfz39Gcmjx3 V5yiqPmE54kgiaoOl3ldDBqSgCfO0slQL20/5x7RENoPFEi3RVGBijyXVQUZVOAwnrhD M4iQ== X-Gm-Message-State: AAQBX9dR2d558pckngsJulKfKeCM2jO/eUP/tpIoOXS21Wj3HZetBmwP Tgb4XtOJ67Hsf3uUa0rMgRxSKDsI2Rqe4HO+ianhpdwLvW4= X-Google-Smtp-Source: AKy350YYBXpbOEvX9N9kHoaPYrS7g4TLXcPhECvw96jOZdsmhtDUixuAstow4TC8eVMX24vR0yKBUiNpOv4JVasG6q0= X-Received: by 2002:a05:6808:288:b0:38b:2f3f:c613 with SMTP id z8-20020a056808028800b0038b2f3fc613mr1158266oic.4.1681460988508; Fri, 14 Apr 2023 01:29:48 -0700 (PDT) MIME-Version: 1.0 References: <20230412234657.ntztyz7iau55lcwt@begin> <20230413101058.wfmy7mb4dexsrbio@begin> <20230413214738.gz2rjnvjvwci7v4o@begin> In-Reply-To: <20230413214738.gz2rjnvjvwci7v4o@begin> From: Sergey Bugaev Date: Fri, 14 Apr 2023 11:29:37 +0300 Message-ID: Subject: Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds To: Samuel Thibault Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Apr 14, 2023 at 12:47=E2=80=AFAM Samuel Thibault wrote: > #10 0x0106bc20 in __libc_assert_fail (assertion=3D0x1222762 "port =3D=3D = arg", > file=3D0x121c2a0 "../sysdeps/mach/hurd/mig-reply.c", line=3D92, > function=3D0x121c2c4 <__PRETTY_FUNCTION__.0> "__mig_dealloc_reply_por= t") > at __libc_assert_fail.c:31 > #11 0x010283d2 in __GI___mig_dealloc_reply_port (arg=3D) > at ../sysdeps/mach/hurd/mig-reply.c:92 > #12 0x012eb23e in __msg_sig_post (process=3D27, signal=3D15, sigcode=3D0,= refport=3D35) > at /usr/src/glibc-upstream/build/hurd/RPC_msg_sig_post.c:160 > #13 0x01074dbc in kill_port (refport=3D, msgport=3D) > at ../sysdeps/mach/hurd/kill.c:67 Interesting... So first of all we're wrong, and the signal code does not destroy the reply port. In fact it takes care to restore it: /* Destroy the MiG reply port used by the signal handler, and restore the reply port in use by the thread when interrupted. */ reply_port =3D THREAD_GETMEM (THREAD_SELF, reply_port); THREAD_SETMEM (THREAD_SELF, reply_port, scp->sc_reply_port); if (MACH_PORT_VALID (reply_port)) __mach_port_destroy (__mach_task_self (), reply_port); (Yes, that's the very same code we've altered recently, but it also restored the reply port before my changes.) See, it destroys the current reply port, and restores scp->sc_reply_port. So then when we jump back to the user's code (which should be in intr-msg), it gets MACH_RCV_TIMED_OUT (if that's what happened), and proceeds to destroy the port itself. One notable thing here: the sigreturn code (above) uses sc_reply_port to destroy the current reply port. So: * if the rcv timed out, we're going to destroy the reply port, but we haven't yet, so the server could fake a reply to mach_port_destroy * if the mach_port_destroy RPC itself fails, we'll dealloc the user's port right here, and then it'll mismatch what the user expects it to be The latter is in fact what's tripping the assertion in your test case. mach_port_destroy (well, your test case contains my mach_port_mod_refs) expects to receive a matching reply, but instead we get a msg_sig_post_reply. We'd have caught this earlier if we didn't neglect the result of mach_port_destroy. Q: But why do we get msg_sig_post_reply here, why not in rpc_wait_trampoline, *before* running the signal handler? A: Because msg_sig_post is uninterruptible. (and this is stupid! and so frustrating! we should just make it interruptible) So: we should not use the user's reply port for this RPC. This is my fault (747812349d42427c835aeac987aa67641d84f1ad). In my defense, there was no comment explaining why this would be a bad idea; we should write one. I'll prepare a patch. But secondly, if we are not destroying the user's reply port, but restoring it, then I don't think the "port =3D MACH_PORT_NULL, arg =3D stale name" case can happen? So we don't need to handle it? We should really just assert (arg =3D=3D port), and this will help us find more broken code. Thoughts? Sergey