Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp883225pxf; Thu, 1 Apr 2021 16:53:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRRE1zlxYBM2r4PSMsEUexbMjbA9AfpGrpPoVwwo/rMQ+mlNZfDFKiE7S6+T5SLbCzYmL8 X-Received: by 2002:a05:6638:1614:: with SMTP id x20mr10234364jas.19.1617321189863; Thu, 01 Apr 2021 16:53:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617321189; cv=none; d=google.com; s=arc-20160816; b=mHQlA+jI2JEoJDZnCo57raPMIZTjq+YF/NBV2pgWraa6dLjzR3170ppf7CXW3kc7/6 IhOdIs2oAPS+NKV4G81t5uSCi7a8Ceh2SfiYOCrFpxfr4uvIQIEbDveYe9SXwE/l4hfr X74skxyIj/WbBv3+UO7bkCWDUfnTSvEvD4+aAvPHjTNDAkz46oKUwEPSNC1gDGEoQaEY CfQ5HfIz22zFOoxztrCHM8uBWatGZSE6Hl5pRiVEbz5MLSgNMmepk8AfnKVMj0lNnHEH tzcNIiZA122wu1/Z4BD41YqJavCqn+Srjh2Cx4rd2YBtaDxU/Lkpx65BQNTJmdPVp88V Gpdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:subject:from:dkim-signature; bh=SEHNUE5bPreCk0YNPUlKmfUdSYB5CVpf+CCeqNykU10=; b=bM1iyd6p7P9W2CANRC9hJzyjghoxBxhs/Q8Qrg8jmbWbdvdIFd+JGzbh0do+Cc9zSz NwpalU4G6YrFxOIc8qO/gYj249UZa/UjMGOG0vPqtpQF8vSMnIpq6AO2TC6j6ZInieri btWLz01tKgKunUzwu/z13ZRiFQWa9dTwyd6iMlXmxaJFsBhDXbAeX4/qoff+Jrnl1FxS twH4KxswnwMgut96UPOMWKBKRbZ63GzT1MWgTOuxpJZCrS1TZXGndGkbz+7xd1gcH+Vp pB7aFq8KG6VySoFmCsMJZRnqhchIokAst1/UaMFM1mODA5ErEdC1FNwB6kuzWMZlDgI9 w+1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=J7xW51Cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h30si1398196ila.131.2021.04.01.16.52.54; Thu, 01 Apr 2021 16:53:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=J7xW51Cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235296AbhDAXwh (ORCPT + 99 others); Thu, 1 Apr 2021 19:52:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233789AbhDAXwh (ORCPT ); Thu, 1 Apr 2021 19:52:37 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88265C0613E6 for ; Thu, 1 Apr 2021 16:52:36 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id v23so1765424ple.9 for ; Thu, 01 Apr 2021 16:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SEHNUE5bPreCk0YNPUlKmfUdSYB5CVpf+CCeqNykU10=; b=J7xW51CzYpZjYXmWQCq34hmEsImnvM5EBx2wI1bgXtbsw6s2Oamp64yTcGoDbiOvis V1YvW3rn/1DOyHFJn3DfArOwMa00YQbA+nIMr+CY31DoO4xniAPSGfG4DWhgf15qdtfW dQ3Cc2fTIFX+grA2YRgCoJvCMQfAx8hFhvvkqBbBOyscRyGPNJu8w0/q+G2SEc9iIBEa 47L3zguwbA/shghY9ja8ylRWn6yRKZPIC64KQnbGdBXWHZjzEbF4vnjKKYpFAqQhpHIg WbX9i6VAFejIDGzrFQC3Dj877LrFcCInLTPRU/nUAdIjvEaxCRefigmg/3vURoU8wDIH 5f+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SEHNUE5bPreCk0YNPUlKmfUdSYB5CVpf+CCeqNykU10=; b=AGh0vUBtvzK5jhllEoXcWtHZcX5j1lOdSznJC05+Bb74xvrozRZOMbvhK3kPI4JBlm DJ9zXLoBTtAPzKbfoifqSOQRU8ja9/4Uo1sZJfQjdA7JDY1qcPRNffcz7AJPwjwONEhe zRNn3pnxb73LE12G5d01368j/1iBiRZWnnqPIoh/DaAZ/b8/nu+emdbFAwVmbKauH+hG gLSy6i+GM+3P1/COj1e54gs9KJYpvOegSVukT5SyU+rLsYF0sqpOmcqlZHHts+dPoZKg sGAe9s8i8kz532fDhD6eqCJhMvD3lxAZ6G746BPRG5oQ0z9nmME6YmHxcKfZWp2p1WIV shBw== X-Gm-Message-State: AOAM532lnWr7GvJTPzmS3jcMUFTtxw5YrkztTrB7xiWkuqnMfUEqXC1L ZCw70IbNqqDkjGJMDBUGTxI= X-Received: by 2002:a17:902:7d8d:b029:e6:4061:b767 with SMTP id a13-20020a1709027d8db02900e64061b767mr10150510plm.32.1617321155872; Thu, 01 Apr 2021 16:52:35 -0700 (PDT) Received: from [10.67.49.104] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id d2sm6237968pjx.42.2021.04.01.16.52.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Apr 2021 16:52:35 -0700 (PDT) From: Florian Fainelli Subject: Re: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE To: Alexander A Sverdlin , linux-arm-kernel@lists.infradead.org Cc: Steven Rostedt , Ingo Molnar , Russell King , linux-kernel@vger.kernel.org, Ard Biesheuvel , Qais Yousef References: <20210330114035.18575-1-alexander.sverdlin@nokia.com> Message-ID: Date: Thu, 1 Apr 2021 16:52:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210330114035.18575-1-alexander.sverdlin@nokia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/30/21 4:40 AM, Alexander A Sverdlin wrote: > From: Alexander Sverdlin > > FTRACE's function tracer currently doesn't always work on ARM with > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > code modifier cannot cope with introduced veneers and turns the > function tracer off globally. > > ARM64 already has a solution for the problem, refer to the following > patches: > > arm64: ftrace: emit ftrace-mod.o contents through code > arm64: module-plts: factor out PLT generation code for ftrace > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > arm64: ftrace: fix building without CONFIG_MODULES > arm64: ftrace: add support for far branches to dynamic ftrace > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > But the presented ARM variant has just a half of the footprint in terms of > the changed LoCs. It also retains the code validation-before-modification > instead of switching it off. > > Changelog: > v8: > * Add warn suppress parameter to arm_gen_branch_link() > v7: > * rebased > v6: > * rebased > v5: > * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block > * use "for" loop instead of "while" > * scripts/recordmcount is filtering reloc types > v4: > * Fixed build without CONFIG_FUNCTION_TRACER > * Reorganized pre-allocated PLTs handling in get_module_plt(), > now compiler eliminates the whole FTRACE-related handling code > if ARRAY_SIZE(fixed_plts) == 0 > v3: > * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled > v2: > * As suggested by Steven Rostedt, refrain from tree-wide API modification, > save module pointer in struct dyn_arch_ftrace instead (PowerPC way) FWIW, ftracetest did not pick up new failures (nor were new tests fixed) with this patch series. -- Florian