From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com [IPv6:2001:4860:4864:20::29]) by sourceware.org (Postfix) with ESMTPS id B62D83858404 for ; Tue, 11 Apr 2023 08:00:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B62D83858404 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-oa1-x29.google.com with SMTP id 586e51a60fabf-1842e278605so8809479fac.6 for ; Tue, 11 Apr 2023 01:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681200040; 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=OWKlXf5TyRTtpQYWw16BSoxsKKUuuuWXb2rBix1A8q4=; b=YsOR07lVmdtnsdqp4JHMwtCeQRDa0VvIYwlqC7whI0GYPHxuYaYNOwUsdBx856HaSD RerPdOQ0DvPU5tcZEfUuFnlMcKn4gk9onactGKeCy5TKh3UIQgUpypevW9qxQTDIQ34I Rk8+52Nb7hsAynye9IdHwGom5FLoWmoHK6cd8lm6SaWDi35o8Vi6b8XoHz+WeQ0JHrwu g2e+A64NmofeV2t9WthIpHSj7fC/11+ebrWHrxCEpMRaVVdIUGkmepzCOHu4cnUwYr4S Q30jkHMu9EdmNDDIlQZJ4GPZ4dQi+G4/DSxn/F0hpjXuw2aKM2M7IMx4vqvSBaDdKIpG qxAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681200040; 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=OWKlXf5TyRTtpQYWw16BSoxsKKUuuuWXb2rBix1A8q4=; b=mM8XnOUKQAh/ALqA6eLeV56uFsoXtEBldLtvdR0YyK3ul1QxIGKJ4fZDKXALFGWnKD GHETj++IMQGxHLQPo8KVQyCwDqjDE1qHFY7o+92nvqoERBFTUnC9Po5bJ0PGDNOYOJIv LGmBqMpaN5MvG26tvwV7N7HS20Hgzlxy9Y0nNDpxtrkq+NQ8yifsiuwy06j/gsmW2QXZ s3uV+sNi8UJPIUeL+1HGvXfnnZM/qmcmFYKlOi79Av1a9SlYrATu/lB6LKs1XV0ApqqQ LWzxso3depnr5DZ0S5Ee6/VYxKQ5/sHyBD7wG7heN5IF0IhSuVshsMhgdFRBKWUsU1Pz zowg== X-Gm-Message-State: AAQBX9c/W/P5qnIinWvHo2JfJ43tzR18xeM89fS7cvpiDchs0wk+cd7+ A623kdilNvKOtxLdgSPQAozqtdDI61H1QukHfqX8CK3TiXI= X-Google-Smtp-Source: AKy350b+yiQtOwvVuJ9a/vH7QSmx75snrCWGwSfPpuE43v6/gH3Tde1inRKs8Qis10N/7roW8RKE0rXuWThTuicsvnU= X-Received: by 2002:a05:6871:726:b0:183:fc80:7361 with SMTP id f38-20020a056871072600b00183fc807361mr6002960oap.4.1681200038618; Tue, 11 Apr 2023 01:00:38 -0700 (PDT) MIME-Version: 1.0 References: <20230319151017.531737-1-bugaevc@gmail.com> <20230319151017.531737-27-bugaevc@gmail.com> <20230410220743.65jputiumkdy2awr@begin> In-Reply-To: <20230410220743.65jputiumkdy2awr@begin> From: Sergey Bugaev Date: Tue, 11 Apr 2023 11:00:27 +0300 Message-ID: Subject: Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port 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 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 Tue, Apr 11, 2023 at 1:07=E2=80=AFAM Samuel Thibault wrote: > I believe we still want to use > > mach_port_t port =3D get_reply_port(); > > because the caller might not know whether its port is still valid > or not, e.g. when a signal interrupted the RPC and thus we had to > deallocate the reply port to make sure the server doesn't get confused. > In that case the caller will still have the old reply port name, which > we don't want to reallocate since it might already have been reused for > something else. *Great* point! (And I should have thought of that..., but hey, this is what code reviews are for, right?) Side note, I really really dislike this idea of some code still referencing port names that are no longer valid / deallocated / reused by someone else. This is really prone to use-after-frees. Typically we'd solve this by leaving a dead-name right in place of the port, and having mig_dealloc_reply_port () dealloc this dead name. But in this case... we're fairly sure that the code really doesn't do anything with the name that it has, other than immediately calling mig_dealloc_reply_port () on it; and there'd have to be a separate code pat= h for deallocating the dead name since mach_port_mod_refs (recv, -1) won't do it (mach_port_destroy would handle both, but using that is a terrible idea)= . So in order not to overcomplicate this, in this particular case, it should be fine to just deallocate the stored reply port and not what the user has, as you're saying. But it definitely needs a comment explaining this. And maybe an assert (port =3D=3D arg || port =3D=3D MACH_PORT_NULL). Sergey