From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) by sourceware.org (Postfix) with ESMTPS id 27BFF3858D1E for ; Wed, 29 Mar 2023 13:14:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 27BFF3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-17aceccdcf6so16129781fac.9 for ; Wed, 29 Mar 2023 06:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680095646; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=/2YDxus7vQWsZSJewwZ2i5wulTmy0eUAwqLlSSTUCa8=; b=ZGbooAAUjQ7cd4qPOarB+n8gPeHhgul8ZRKVjDKobJKMsa7jR3j7q7eKkvGwoWLDF9 YCoIjxCY8Ay9mXD64t2YGgvXLzN5xZLrj2Xfxxlpp9dqgJLI+hP91ivkIKLa7Bmja0yS hjH+w5JyTirUeItI++E62zf3p2dW7C92VMV+PT9KdsBRzTrpuYdS8jmnz9eTYSYSY3MJ BxI70MqUq3WTkT9aDfkdGsjBrTu0CUoqgXwyL0n8EHJjshrb3UhPt2THdQjsesR0u9Rg v2+ErzfR38DfqDkhX7shPX6E5PaQ7PxVfvz/MaEdts2I8xHl9tfHu6vwsr0Yqr+22xms WMOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680095646; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/2YDxus7vQWsZSJewwZ2i5wulTmy0eUAwqLlSSTUCa8=; b=TThQzBFeLm0AGgE84aKLqoBk+SZJgOaziuZtfwiyMCks/8eYo9A0n3RXZ9x8sHrXT6 9Ro0XZ2aKZAbmKGoli0mRrd4rwR39TrNnvQHXscCkl6dzny0YqJJLtKmUjAAum09MRCi BY/hjGOkKEip5qOMh5AbPN9y6TIBfrayBlO/5A0/tyhPeUe0aaF1n8Y37tZdMqks5zhm c37weZInFRkUaAygxygWLJymmTN0lxcOC6ja/iTyKIHWcKEAIIlTYRTbsAnjUSVg1Fdi nNCG00wW+3ClTkg4UTtz5BCwOONLzjDntqOZfqDvA3mFwmrJttGywVPS3FXVJoeM1WgV V10Q== X-Gm-Message-State: AO0yUKU0EH1B9INmFB2gIeVsY4WqJK9IBvUJMFO1Zoc6teqeIddkrF6h bEnpes5tXA3UaNt5svkug+/ZzD34hFlA4JI9yFkERA== X-Google-Smtp-Source: AKy350Ya3y4dGEEz1fE24X7F7j1Vzv8V53Jr/vPMG4YwawJThyCC9UOGLvDMbuWTXKw5EJ3mkWEfrA== X-Received: by 2002:a05:6871:215:b0:17a:d06e:6bdc with SMTP id t21-20020a056871021500b0017ad06e6bdcmr10890697oad.25.1680095646315; Wed, 29 Mar 2023 06:14:06 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761? ([2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761]) by smtp.gmail.com with ESMTPSA id x13-20020a056830114d00b0069dc250cb24sm8502325otq.3.2023.03.29.06.14.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 06:14:05 -0700 (PDT) Message-ID: <1994774e-d2a0-3cae-1012-3c3fa912659c@linaro.org> Date: Wed, 29 Mar 2023 10:14:02 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs Content-Language: en-US To: Jan Kratochvil Cc: Florian Weimer , libc-alpha@sourceware.org, Anton Kozlov , Siddhesh Poyarekar References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,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 29/03/23 09:12, Jan Kratochvil wrote: > On Tue, 21 Mar 2023 00:47:53 +0800, Adhemerval Zanella Netto wrote: >> if I >> understood it correctly when criu restores a dump it will only restore private >> mappings from the process and not shared ones? If so, how does it handle >> restoring on a system on an older glibc (or on a system with any dependency >> older than the one that the process was dumped)? Does it only restore file >> backed shared mappings based on naming? > > Different OS (components) version is not supported, similar to: > https://cr.openjdk.org/~heidinga/crac/Portability_of_checkpoints.pdf > 2. Same hardware, different distro Thanks for the link, so it does seems that CRIU does not save anonymous file-backed maps, this is what I understood from CRIU memory restore doc [1] where open file mappings are done by 'files engines' (where I presume it is either an external process or a library, correct if I am wrong). Another issue you might see (even on same distro) is that Intel is doing a *lot* of performance backports on release branches which means that even glibc in the same release version might ended up with different sets of ifunc variants (since this does not really affect ABI). I am not sure how it would reflect on distribution itself, but assuming a distro that follows the glibc release branch it might indeed happen. [1] https://criu.org/Memory_dumping_and_restoring > > >> Using a custom built glibc with --disable-multi-arch along with rpath, you >> have a dissociated glibc from the system. You can even tune to use an >> specific x86_64-vX abi if you see that the workload benefits from some >> specific string/mem/math routine. > > Then I need to build also all other used libraries and that is what is called > nowadays a container. Which is a perfectly valid use case. But building > a custom distribution (=glibc) is not a supported way of running any software. > [This is my personal opinion, I do not speak for any company.] In fact I think for this specific problem is the best solution. Along with a JVM built with rpath, it means you will pack everything it requires and assure that once it is installed from same package, the glibc won't enable any optimization not supported and make sure that any distro backport won't break these assumptions. It also works with all scenarios you raised, assuming that 3rd party libraries (outside the JVM package itself) does play nice in such scenarios.