Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2190922pxb; Mon, 12 Apr 2021 17:26:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxhhvX0ZDzZ/Q/qe2IOVmsIE4I7Rf200A4ZJzhEXpTqbyHhcOj+lFEFZCvjsxz9522qmQo X-Received: by 2002:a17:906:5487:: with SMTP id r7mr28803925ejo.550.1618273578136; Mon, 12 Apr 2021 17:26:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618273578; cv=none; d=google.com; s=arc-20160816; b=rjFvB0JC5vs7jF/VI92Ab2yzlEsiSJsdY2bOd473L6bO6YNgaPIzQJ4eXddap7ZCUu eaNMnTdHBjY5LJdxWQ3uG0TzeYBrjx35bgjs4Cnny/7ngBqmqMHl6fuzDwRdtkqu7xzU 5VagjwA6WgTkGTGEItt2jGujqsXu/FngVvgvKEvFt0Ezo1Kyoy3jDBZ1Zpzob44RQft8 k6ly5hP3j6Exh4s0P/98QZ4vLezURB0mOsXTmiexq1TPKssiAYhgBAfjqZkFQkxPwVks 0+OLiiNpav5k3oid35Y+Xe5Iyiak3XOdu/UZuFPPu31H8G9rqvA3gwx+1pAZ17ppYukd 5PZA== 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=ZyyOTfscUCsmBF3UOieIrES1Pbdhl3hqQb9ggCt11Co=; b=MRLvG+zRjO2xSIa/hQXd9VgSu3pP356tZtZh+5EL2OBdv+oQ3eYlgb1kvgAx4LLrgg PIhWWjaBgnI9bFM2of2ucSI6KGbV+hsQW0mGDEwml88ILLkdE/h4AzSyoOxPnB/EDDUA Q5K/Q0FsXEObmOTB4JRW++GujLemMqfBq6NXhkqdR5j53VIGkbz+Q+WEK6yk1oofkuu/ E6VHMSrQkH489amr+OojoQzvEB4dmFKMoSUEk2dRqMcchd5QKLi0GKxBj0PZzJvWwlbB nZfE8KQrT8SUyyRtbPjzLshtDf9xYbBJTPEItBnVU00bD5+DwSdj+TwORJ3ECU9oUy09 RYkA== 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 y6si8959273edd.79.2021.04.12.17.25.54; Mon, 12 Apr 2021 17:26:18 -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 S239658AbhDLLId (ORCPT + 99 others); Mon, 12 Apr 2021 07:08:33 -0400 Received: from foss.arm.com ([217.140.110.172]:46934 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237520AbhDLLId (ORCPT ); Mon, 12 Apr 2021 07:08:33 -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 283F031B; Mon, 12 Apr 2021 04:08:15 -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 DED233F694; Mon, 12 Apr 2021 04:08:13 -0700 (PDT) Date: Mon, 12 Apr 2021 12:08:10 +0100 From: Qais Yousef To: Alexander 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: <20210412110810.t7pqkwawn5zmqbca@e107158-lin.cambridge.arm.com> References: <20210330114035.18575-1-alexander.sverdlin@nokia.com> <20210409153309.wbebto3eufui35qs@e107158-lin> 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 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. Thanks -- Qais Yousef