Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1446569pxf; Fri, 9 Apr 2021 08:37:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzGbTwv0yE0GdGuzHFho/fzn1hV7VtXLKAOjheE64IIj740s8dhGggcSXYhu0Uxb0/74CJb X-Received: by 2002:a17:906:250d:: with SMTP id i13mr3402775ejb.474.1617982625705; Fri, 09 Apr 2021 08:37:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617982625; cv=none; d=google.com; s=arc-20160816; b=i/mt5vQoei+NreSKPuXNwcfgOr0sgZF+W+CAbqHCpTVSim5TNJPYzyAbS7Q97Vpd+C IF5fy/70HL8jhRzLcE5VJ2jW7tAq7LiKbm41UMSzwYdjoGnE4rKzrr2IsWh5bhB/sa9M MM3iaQX7nlk/dATf3OC6PeDxQxYM3pX/A0dyRk/orfxfwU6MIC5I9utcAxNSVOfmz/TR kKKmWo0+b6SfybS+SRmSdtTiQBWiU6uPAMUwlREXTSts6WkNW/FxF6QuZGfR/Q1JX46F pSq8qZIZ6ZeTPqP2LQUKO6Kvi4vpcSnvgz12vlBygRFprM3HKd4WTisvzWFYslMPOExV EXog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=96R8o9nsWn+cl1hvJDJhZzDDjsJQU97DVNXKLAsWOOg=; b=hA4nsteBPbNO/4HfjqqRagwV8na9tLenQEjKk6kpTvcYwzYQd3b76z0B89LmKwwol4 kME/226cvSsIU6lpAEMCwpSB6dmqaRYg6ZBLbSzTYctpWvGKUBN0SwodyYsu85vW4bzf m0wKrTxsB8LQE+rN/uWnn/62cPVcfoxHquENqOOqUHVCyiTl55FSLEhMPIxHz1OSjOHb 6mitBarajA/jB+Q1ib23Y0RfI83/U9d0raN4P+giOarAlp0HiGIg2bF4BJWCFAQFuJwm iIkY3qEko5J24WUlcdTnVydJho0x/BRO1+iVSe40CAlSjyVXidaFHrOAkQQjfFIQkPcY nPWg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 26si2248477ejy.13.2021.04.09.08.36.42; Fri, 09 Apr 2021 08:37:05 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233288AbhDIPdc (ORCPT + 99 others); Fri, 9 Apr 2021 11:33:32 -0400 Received: from foss.arm.com ([217.140.110.172]:53788 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229665AbhDIPd3 (ORCPT ); Fri, 9 Apr 2021 11:33:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7384F1FB; Fri, 9 Apr 2021 08:33:13 -0700 (PDT) Received: from e107158-lin (unknown [10.1.195.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3C9483F694; Fri, 9 Apr 2021 08:33:12 -0700 (PDT) Date: Fri, 9 Apr 2021 16:33:09 +0100 From: Qais Yousef To: Alexander A Sverdlin Cc: linux-arm-kernel@lists.infradead.org, Steven Rostedt , Ingo Molnar , Russell King , Florian Fainelli , linux-kernel@vger.kernel.org, Ard Biesheuvel , Linus Walleij Subject: Re: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE Message-ID: <20210409153309.wbebto3eufui35qs@e107158-lin> References: <20210330114035.18575-1-alexander.sverdlin@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210330114035.18575-1-alexander.sverdlin@nokia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding Linus Walleij back to CC On 03/30/21 13:40, 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() I still think the ifdefery in patch 3 is ugly. Any reason my suggestion didn't work out for you? I struggle to see how this is better and why it was hard to incorporate my suggestion. For example - old = ftrace_call_replace(ip, adjust_address(rec, addr)); +#ifdef CONFIG_ARM_MODULE_PLTS + /* mod is only supplied during module loading */ + if (!mod) + mod = rec->arch.mod; + else + rec->arch.mod = mod; +#endif + + old = ftrace_call_replace(ip, aaddr, + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) || !mod); +#ifdef CONFIG_ARM_MODULE_PLTS + if (!old && mod) { + aaddr = get_module_plt(mod, ip, aaddr); + old = ftrace_call_replace(ip, aaddr, true); + } +#endif + There's an ifdef, followed by a code that embeds !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/ And there was no need to make the new warn arg visible all the way to ftrace_call_repalce() and all of its users. FWIW Tested-by: Qais Yousef If this gets accepted as-is, I'll send a patch to improve on this. Thanks -- Qais Yousef