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 ED48E3858D38 for ; Mon, 10 Apr 2023 22:35:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED48E3858D38 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 1pm07A-0001C9-0M; Mon, 10 Apr 2023 18:35:56 -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=rqU5XYWwnqmA/e7cGBqOi+SuWds3tv6fBtaYUBFDGRA=; b=qxnb7p9f+JJowkUrgIfb pQL8zNO8qotcv/7l0rrF+T7sZRpdU1TU4c0rBiAQIwycxB36sz9GXOcv1+m8BNrBfTPBXRdSs8Wrs UTKGB22ha/9S7pQTR+gUc8bHwsxRB5N7Cpg7jg9oBkZQ8l6VZcj7vVo0ukRiVdQ2bHj8tFFKVNc5K M+gIVOoaVRdXWMhQ81EM4PkAFWrUsnpOU/u/Fks09tzd8ws9A2xUAQz2xX60X4nSzJjzfcn7WAkX8 oDQYzhWr3pLEE7kS7jJWcKy7fqhg9kTqDkSdVi4NE2Kjas1Rp6Llbos9yKyY8YJBrlcASshpBXZqu Js6RdgNqGoaQuA==; 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 1pm078-0005cN-RV; Mon, 10 Apr 2023 18:35:55 -0400 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pm076-000wUQ-2q; Tue, 11 Apr 2023 00:35:52 +0200 Date: Tue, 11 Apr 2023 00:35:52 +0200 From: Samuel Thibault To: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port Message-ID: <20230410223552.q4l3gbcqrapkygn2@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> <20230410220743.65jputiumkdy2awr@begin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230410220743.65jputiumkdy2awr@begin> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-6.4 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: Samuel Thibault, le mar. 11 avril 2023 00:07:43 +0200, a ecrit: > 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 deallocate > something else.