Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2837506pxb; Mon, 19 Apr 2021 15:36:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLU2EK7gjcuG808v4YLmLHdooYQjgN6xp1mtBEdbC2cOMr7/ZqarpX2Hru/mJFw6LhMEop X-Received: by 2002:a05:6402:1912:: with SMTP id e18mr5390325edz.184.1618871772036; Mon, 19 Apr 2021 15:36:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618871772; cv=none; d=google.com; s=arc-20160816; b=mBd9+xIiUWp6db9Q6vDw497vpFbs/29BqccsTlXolinPb4AfxxxJO5VBwIYPlkBAoH ieg/Mbq9K6bXNPO6qOt4F544EScKf6EikJ3EAyJddwxaLbEOCEr8aRuoXYs6wbPfKLTc ZwzVEj0biu+5S013bdEW9JhrRALPRr+5hNY+i05cyHb7t+SidaeQMG/FB0pa7RWzkcxU Cx4yFPJ9s6H94l0FgvVn17C0Mh7OcKc0yesXCnqpR02KkkQ3CkwZRsp3aNzdwLuFnSSR QHvPGpc4y1ipupBz31aOzMv8+5HmuGZVTqI5wb7Sjc7HdEXNYw3O+lXwVX4fFN0ZlREB x2iw== 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=U5kE9wY/9aU10oJqh/+hOpHTh/mwpLxZ3LDF61VCTjg=; b=MESolkE9mg0x+WNJZ90hfBxLwNkrQvi4z+CLc/Db2+hxLys1UAskER9D9RsOLIDufR VcIu4JrllTVJSGE0yHgYyLqrWk6uVi24lmUzK04pPqz9W1oXzVXp16kqETha+tUGB8Ht e09+cB1KBCp35kaTuVibyM9YTDilHvawGZmb78YCUIO4a7Nn/RgEMpiTVLo5j+TDxBI/ b0LRAacCTQrbo1NKgiOd3Wg5VaGwn/fkTRjBt4+T17Tx2C67VXd5xE0qAi9Jp9f+vODh W3JeJ/hagoefg+OHT+CfwLJ5n/l0tKP7RBt6p3nZ096ROLYj0nOaJsroDBWhPqBY/0+P XNxQ== 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 d12si11883346ejj.422.2021.04.19.15.35.49; Mon, 19 Apr 2021 15:36:12 -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 S230029AbhDSWfW (ORCPT + 99 others); Mon, 19 Apr 2021 18:35:22 -0400 Received: from foss.arm.com ([217.140.110.172]:51976 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229537AbhDSWfW (ORCPT ); Mon, 19 Apr 2021 18:35:22 -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 B99C61435; Mon, 19 Apr 2021 15:34:51 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 823453F792; Mon, 19 Apr 2021 15:34:50 -0700 (PDT) Date: Mon, 19 Apr 2021 23:34:48 +0100 From: Qais Yousef To: Florian Fainelli Cc: Alexander Sverdlin , linux-arm-kernel@lists.infradead.org, Steven Rostedt , Ingo Molnar , Russell King , linux-kernel@vger.kernel.org, Ard Biesheuvel , Linus Walleij Subject: Re: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE Message-ID: <20210419223448.vummlz37nyc3a64i@e107158-lin.cambridge.arm.com> References: <20210330114035.18575-1-alexander.sverdlin@nokia.com> <20210409153309.wbebto3eufui35qs@e107158-lin> <20210412110810.t7pqkwawn5zmqbca@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/19/21 14:54, Florian Fainelli wrote: > > > On 4/12/2021 4:08 AM, Qais Yousef wrote: > > Hi Alexander > > > > Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in > > your future postings. > > > > On 04/12/21 08:28, Alexander Sverdlin wrote: > >> Hi! > >> > >> On 09/04/2021 17:33, Qais Yousef wrote: > >>> 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 :-/ > >> > >> No, it's actually two small ifdefed blocks added before and after an original call, > >> which parameters have been modified as well. The issue with arch.mod was explained > >> by Steven Rostedt, maybe you've missed his email. > > > > If you're referring to arch.mod having to be protected by the ifdef I did > > address that. Please look at my patch. > > > > My comment here refers to the ugliness of this ifdefery. Introducing 2 simple > > wrapper functions would address that as I've demonstrated in my > > suggestion/patch. > > What is the plan to move forward with this patch series, should v8 be > submitted into RMK's patch tracker and improved upon from there, or do > you feel like your suggestion needs to be addressed right away? There's no objection from my side to submitting this and improve later. Thanks -- Qais Yousef