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 C4B0F3858D28 for ; Tue, 11 Apr 2023 20:18:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4B0F3858D28 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 1pmKS1-0001xj-AY; Tue, 11 Apr 2023 16:18:49 -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=sCisSBqgzL3L8JhX2btWs2WyYZYVUnff1YnDiBWnabU=; b=bYluaq7ZymoT9xLccm9J fQFXNpaN4Kx0lNOmlJTNfddMNKtCb0yEDMFjMeJYb5j46hVDNjvFmMuVr4a9b0UWGq7pEajuqhs0g bHlxvu2ESKtbx6ln7jOwuLl6gQ4YunfO1+bHro2paHwgMgtiR/jEk3nRnLcXaQop4sZQ9z6U/Xsll vCqya3t/Xqq6snTFtPhKr+8Vxw3g8PQ/C2WvpjSvxT+0h32ZumpeBPthKcDa5ZYli630dfSmh0MN0 MJ6woBOtW7XH38ZO3M21EOi02o+UvntQ3HImCd3yjKkfmi8qZSoRiBdTwtvGZdR2/LKHYvUYYbABp Jsi5U5Xhbg05Pw==; 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 1pmKRy-0006uX-3M; Tue, 11 Apr 2023 16:18:49 -0400 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pmKRx-000hCS-0N; Tue, 11 Apr 2023 22:18:45 +0200 Date: Tue, 11 Apr 2023 22:18:45 +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: <20230411201845.oias7lryrvm3cck7@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: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-6.3 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 mar. 11 avril 2023 11:00:27 +0300, a ecrit: > 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. That could be better indeed. Rather than modifying refs under the hood, let the code manage them. > 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 path > 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. Completely agree :) > And maybe an assert (port == arg || port == MACH_PORT_NULL). If that does indeed work, yes :) Samuel