From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id MUXUNjJ2TmoviCwAWB0awg (envelope-from ) for ; Wed, 08 Jul 2026 12:09:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1783526962; bh=9dx9i5GCwt1eotpFIIkdJcKu4IHPqna1Ybq2XWBxcEI=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ejZ0/dmJhYDuzzYnbjmqa0D6uMkF42XevijXnQdFuNSgEQ064wAFKWiluoBFoxUdz I20XnK8fPT3Q8qTauIYhBMOhEoBCS6NHEcPQcroJdzlbdOSRxHK40SCgjzgdqfqrTb jvK7F+MFzTGEQjRtjFp7/VmBfzMLPFahknNkFfks= Received: by simark.ca (Postfix, from userid 112) id D00231E024; Wed, 08 Jul 2026 12:09:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=hmj2tBBv; dkim-atps=neutral Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 293D51E024 for ; Wed, 08 Jul 2026 12:09:22 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 13EA44BA2E20 for ; Wed, 8 Jul 2026 16:09:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 13EA44BA2E20 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=hmj2tBBv Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 8907C4BA540B for ; Wed, 8 Jul 2026 16:08:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8907C4BA540B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8907C4BA540B Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783526936; cv=none; b=W935FrMpUmnIO6x/rTJPPBIUTeGv9QFi+1EKieLkZqOY2vrETn7EMCqsVc0yDkU+pls4YhVlHt7tSxRai4YOQPz0MrSC2D/Ak4UX68Uaqhv6Br9v/AYE3S+Mq54whgUhGM9Ut74JCNu1SXLj58JwEKna2j2tT51ZxlMC/prfRk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783526936; c=relaxed/simple; bh=9dx9i5GCwt1eotpFIIkdJcKu4IHPqna1Ybq2XWBxcEI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Rj0ggn9NbB055NFx/wQKm9F5BQau16Cn2g+7L3lVzbbXkuK7N+yHHRTvAVu2nzlH091HFnWb4AM9ypRWLPEq7Cz/O8emb7LZsGC4T5DygTpy/cELzE3/9/7us42nAzDHN1Te/6WEt7aFgA9yh8WGidFMZIg5YaeFXCWrtXaZghg= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=hmj2tBBv DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8907C4BA540B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1783526934; bh=9dx9i5GCwt1eotpFIIkdJcKu4IHPqna1Ybq2XWBxcEI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=hmj2tBBvbhj2uK5qkQWsmRlldbEkNrcS0jJdAfTuAG+I0LluY2PsPkxROV+25va3O jJbgcH4r+tccenc0ItVFTbnMg2D7mf0lFZdRlPRtKJYHk4VRX4rBya2Qmxvo2QVH1J zktJS5ZwIICRCEp9hiqihJAS+l1M8R0O2Q0aCu9Q= Received: by simark.ca (Postfix) id 91BCE1E024; Wed, 08 Jul 2026 12:08:53 -0400 (EDT) Message-ID: <3393854d-960c-4935-8808-8193c9857f98@simark.ca> Date: Wed, 8 Jul 2026 12:08:53 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/10] gdb/solib-rocm: move per-inferior data to rocm_solib_ops To: Lancelot SIX , Simon Marchi , gdb-patches@sourceware.org References: <20260608200100.666134-6-simon.marchi@efficios.com> <6fq2jwcy7nc6ande7vbiuxkd3n2u2nrrvzvezw2ivok6epyewc@zqfl6jj7qneb> Content-Language: fr From: Simon Marchi In-Reply-To: <6fq2jwcy7nc6ande7vbiuxkd3n2u2nrrvzvezw2ivok6epyewc@zqfl6jj7qneb> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 7/6/26 1:09 PM, Lancelot SIX wrote: > On Mon, Jun 08, 2026 at 04:00:29PM -0400, Simon Marchi wrote: >> Move the data currently stored in an inferior registry directly into >> rocm_solib_ops. This changes the storage of this data from "per >> inferior" to "per program-space", but it should be equivalent, since >> there is usually a 1:1 mapping between those two. The only time there >> isn't a 1:1 mapping is during a vfork, before the exec/exit, but no ROCm >> activity happens during that slice of time. >> >> Function rocm_update_solib_list becomes >> rocm_solib_ops::update_solib_list. >> >> Function rocm_bfd_iovec_open becomes rocm_solib_ops::bfd_iovec_open. >> >> Most of the changes consist of accessing the fields directly, instead of >> going through the solib_info object. >> >> The rocm_solib_ops constructor has to take an inferior as a parameter, >> rather than a program_space, because of the fd cache. >> > > Hi Simon, > > It seems that this patch introduces a use-after-free issue when handling > the "detach-on-fork on", "follow-fork-mode child" case (I see this with > the gdb.rocm/fork-exec-gpu-to-non-gpu.exp testcase with ASAN enabled). > > When doing the case where we follow the child, we reach > rocm_solib_target_inferior_forked: > > if (detach_on_fork && follow_child && fork_kind == TARGET_WAITKIND_FORKED) > { > auto rocm_ops_holder = child_inf->pspace->release_solib_ops (); > auto rocm_ops > = gdb::checked_static_cast (rocm_ops_holder.get ()); > child_inf->pspace->set_solib_ops (rocm_ops->release_host_ops ()); > } > > On exit here of this block, the rocm_ops is deleted (calls > rocm_solib_ops::~rocm_solib_ops). > > However, at this stage, if there are still solibs which were opened by > rocm_solib_ops, the next call to update_solib_list will lead to deleting > the solib which do not exist anymore (so far so good). Any file > rocm-solib still open at this point will eventually be closed when we > close the associated BFD. This calls into rocm_solib_fd_cache::close, > which tries to access the rocm_solib_fd_cache::m_cache field. However, > this is a reference to a rocm_solib_ops::m_fd_cache, which is now gone, > leading to a use after free. > > This was not an issue until this patch because the fd_cache was owned by > the per-inferior rocm_solib_data. which is not going anywhere during the fork. Ok, thanks for the analysis. I didn't spot this because I didn't fully test each commit. The issue goes away at the main multiple solib ops patch, because it adds the behavior of removing all the solibs owned by a given solib_ops when removing that solib_ops. Having known this, I would perhaps have kept this cleanup for later. But now, the subsequent patches are based on this one, and removing it is not trivial and risks introducing more issues. So the fix I propose is: - Move the remove_solib patch before this one, this is trivial. Make remove_solib public from the start (it would become public in the last patch anyway). - Change this patch to call remove_solib on the solibs owned by the rocm_solib_ops. This mimics what the last patch does. The end result of the series is the same, it just changes the intermediary states. I would send a new version of the series with those changes. Simon