From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id F3A4E385842B for ; Mon, 10 Apr 2023 22:07:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F3A4E385842B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1plzft-0002vF-Gv; Mon, 10 Apr 2023 18:07:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=+eHaS13zqa7I9hvC9I0ILl0XcVcHOC4Lb861TMyDXv8=; b=llS2CeejMMXca7u2xk6L 8gKNuLUasUmetm8AqwNZB9rkJIQhK4fUjH30MdvK1rkwCOA25CYJHL8TV/xhzJy6sSvDr5LjwNr/2 rjt2FXG20Jrl3X/GiIwRHsllCGvb7UtuvNKgXc06rK9hY40HjEA2hNXw+47TlvBwfV/H60Ne3pwXE 2+o3BSo2pF4ArvCmgueriHXG2stxrkTDakeEtoNmTDvkdG8VWCss1HYnrYNQ817gbz8oPD4r3BL89 7JcaKxbwoCwhaYeMN2gcaN29xj93xhDp/4X93qLnIs57/Gs7Bn1MMdVWgT7eY8/5cGXfQW9nQ3Tso rVtudlm2cHy0zw==; Received: from [2a01:cb19:4a:a400:de41:a9ff:fe47:ec49] (helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1plzft-0006M7-4Y; Mon, 10 Apr 2023 18:07:45 -0400 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1plzfr-000qqQ-2k; Tue, 11 Apr 2023 00:07:43 +0200 Date: Tue, 11 Apr 2023 00:07:43 +0200 From: Samuel Thibault To: Sergey Bugaev Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port Message-ID: <20230410220743.65jputiumkdy2awr@begin> Mail-Followup-To: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org References: <20230319151017.531737-1-bugaevc@gmail.com> <20230319151017.531737-27-bugaevc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230319151017.531737-27-bugaevc@gmail.com> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,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: Sergey Bugaev, le dim. 19 mars 2023 18:10:09 +0300, a ecrit: > /* Called by MiG to deallocate the reply port. */ > void > -__mig_dealloc_reply_port (mach_port_t arg) > +__mig_dealloc_reply_port (mach_port_t port) > { > - mach_port_t port = __hurd_local_reply_port; > - __hurd_local_reply_port = MACH_PORT_NULL; /* So the mod_refs RPC won't use it. */ > + set_reply_port (MACH_PORT_NULL); /* So the mod_refs RPC won't use it. */ > > if (MACH_PORT_VALID (port)) > __mach_port_mod_refs (__mach_task_self (), port, I believe we still want to use mach_port_t port = 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. Samuel