From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by sourceware.org (Postfix) with ESMTPS id B07CA3858D20 for ; Fri, 14 Apr 2023 08:53:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B07CA3858D20 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-ot1-x331.google.com with SMTP id w19-20020a9d6393000000b006a43ff0f57cso802788otk.5 for ; Fri, 14 Apr 2023 01:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681462435; x=1684054435; 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=mqYrEVcjbLsCXsv/PJ1OmiaCLPU/k07wZ16R+4ippOw=; b=JQJvje8dq+dzsMo6NdY2SZurN8d7FyH5DErj/M9rDAYqcPwiRnZKps48d+Ziizrp2H pUfM1Sy1XA4D5G2CdIYThiIYVv2a8GacbWVvmHg/sxh1PRnihAafGQHg/Hfm8G5/Ir/a pq/q+Cltf2CwfU5uzS24xMyW+cLKNQgCcIqmmMiQxXnp9z9C9HGrjY55xfmog+dZnrib gnvRwEtH5yKZegyR+uORmuvGtO+1/JNKh/erhx41I1D18XRs6Ocmv5v6MXN2n5LKenI1 uQjQgPdtsl/m5F5JydrRT9tRwnbHH/Yn5Ya6Z7mTR0zBvfZ01MFwRsFCz6WeORWSGv6u aHvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681462435; x=1684054435; 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=mqYrEVcjbLsCXsv/PJ1OmiaCLPU/k07wZ16R+4ippOw=; b=bwQJgDPKbX69mdCthsr4GTzhyj6U0ZOAg84sHJe/MkHsjZa4iFwz/yxwUpckP7nhNp MyW8BEauvEaP/VCKBpvUif9fwx+nqo3xPPsEO0dvMr50ex5CsBTtcp66aJp93V9YZ7Ew NLwwAQFcbnc5FdyLSLMnd9p0Ry86KcY+JoI8sT8rD5VT8mjqUmzs0Jg3DwLtvMy6hC2Z +TAjaRGtel+vNTjuyOEbInGQkmTNu5myjHsMgIg786sIVNl7SJ0Zfjb4yxv5uLPEg2Co cIecuIrwrtk+XM7A1oX046pCQiNr7ulj4LigwRfWVGdxvgvDJDBsX8zI4a2e2x0UobK8 Blpw== X-Gm-Message-State: AAQBX9eAFYgIQOWpBMSCZrfG/ZzHydhKDa0ukWkVN1OT+qh1SfnJl72b hejkz1P5VWeh4LPEKVS082iDF1kuaHirDz2Bkvi7ka/PGVU= X-Google-Smtp-Source: AKy350YqRtwRnjWhnQaxOpZEPHJmdq9NGAWtUqmg6hiG1ovJGorFyBJcNBHyPS1c091FAQauN7qZCWjiaYJGFjQbfe4= X-Received: by 2002:a9d:6283:0:b0:699:7883:940d with SMTP id x3-20020a9d6283000000b006997883940dmr1249998otk.7.1681462434859; Fri, 14 Apr 2023 01:53:54 -0700 (PDT) MIME-Version: 1.0 References: <20230412234657.ntztyz7iau55lcwt@begin> <20230413101058.wfmy7mb4dexsrbio@begin> <20230413214738.gz2rjnvjvwci7v4o@begin> <20230414083647.xz2iimas7jgzp4kr@begin> In-Reply-To: <20230414083647.xz2iimas7jgzp4kr@begin> From: Sergey Bugaev Date: Fri, 14 Apr 2023 11:53:43 +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.4 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 11:39=E2=80=AFAM Samuel Thibault wrote: > Sergey Bugaev, le ven. 14 avril 2023 11:29:37 +0300, a ecrit: > > 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? And just as I sent this, I discovered that there is in fact a place where we do destroy the port! Ugh! It's in _hurdsig_abort_rpcs, if the interrupt_operation call fails. Let's maybe not do that either? We're already making mach_msg seem to have returned EINTR, which intr-msg knows how to handle. Currently it's doing this: case EINTR: /* Either the process was stopped and continued, or the server doesn't support interrupt_operation. */ if (ss->intr_port !=3D MACH_PORT_NULL) /* If this signal was for us and it should interrupt calls, the signal thread will have cleared SS->intr_port. Since it's not cleared, the signal was for another thread, or SA_RESTART is set. Restart the interrupted call. */ { /* Make sure we have a valid reply port. The one we were using may have been destroyed by interruption. */ m->header.msgh_local_port =3D rcv_name =3D __mig_get_reply_port (= ); m->header.msgh_bits =3D msgh_bits; option =3D user_option; timeout =3D user_timeout; goto message; } err =3D EINTR; /* The EINTR return indicates cancellation, so clear the flag. */ ss->cancel =3D 0; break; but I'm thinking it instead should be doing this: case EINTR: /* Either the process was stopped and continued, or the server doesn't support interrupt_operation. */ if (ss->intr_port !=3D MACH_PORT_NULL) /* If this signal was for us and it should interrupt calls, the signal thread will have cleared SS->intr_port. Since it's not cleared, the signal was for another thread, or SA_RESTART is set. Restart the interrupted call. */ { /* Our RPC was interrupted, and the server may have kept the repl= y right. Get a fresh reply port from MIG. */ __mig_dealloc_reply_port (rcv_name); m->header.msgh_local_port =3D rcv_name =3D __mig_get_reply_port (= ); m->header.msgh_bits =3D msgh_bits; option =3D user_option; timeout =3D user_timeout; goto message; } err =3D EINTR; /* The EINTR return indicates cancellation, so clear the flag. */ ss->cancel =3D 0; break; ...coupled with _hurdsig_abort_rpcs not deallocating our port. wdyt? Sergey