Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp2834389pxb; Fri, 8 Oct 2021 16:52:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxY5jv1ZEOC4aUyjc3Lgh5FQf5LcNqZsiQibmP+MDQPweyDQUEb1ZJ8pAw+an2D6zQUr6w X-Received: by 2002:a17:906:3adb:: with SMTP id z27mr7833586ejd.291.1633737169260; Fri, 08 Oct 2021 16:52:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633737169; cv=none; d=google.com; s=arc-20160816; b=NePlHZPlueOoIsg4woM1v23YNU1z66INw1M4OzB/VvnxsOodGylnuvtj1kimw2Iid5 PW4e1Kzu06gLkreIKz1X6aN9EBnRuHCwuUlZE5uTuMIhIYk7w5rWdNO4ddvuHIDmZV0q h4Z17XF60+q580rpSs/01R7MxNhSWl5XHepLoNYlxV16dsttpalLt71EVQpZtrcST9Um j7rmGwH1M8MZZ8I6XkTk/zInCD1odCDmeVvd+5VF+p+0PpTOzvuIG7uIZ2OKEv3nMR0R yhb83eG9VBdLozewD5494ZQe9J2rxRrGBCbzui/E1bdd3Msr201FBWamM8lQxkU2PG2o 40ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=BRYKOA16FjaAyGoc3ilSItYjIJmFWQXRT2OkwM2L9tA=; b=xNwPoBjjblPGnO696q8+ATaqYPJyxN+E/RdiTWfbycaQpZ7zTnos2tZ3j1GNdQM8pL DoE/+IKYYb+V/x/CveIAXnHxPQebbPa9zZNh6uc80XY3O9V5eBnGic6dJwYk+fZGXuTN eaLP18lMcfH55nR4kRHfhwcAYGFNZzwy2nqpHeiBIpoZC/bkdKyjwcU/EuUmCNAjMNxe 67O2ZL6HDLKFByHy5TKsuz44O6/jfMLIuaa9PTxncIJYd/DcODRYVQrnomHeNT1T4MOs xZ9XAVBGa2yYciC1Olta+2vLGkoZ+/eCoPxDZDa6kAtUXzxDc9r4lRK6bLp+20a/SCTg UXcg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a24si887808edr.610.2021.10.08.16.52.25; Fri, 08 Oct 2021 16:52:49 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243892AbhJHXuU (ORCPT + 99 others); Fri, 8 Oct 2021 19:50:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:41378 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243797AbhJHXuT (ORCPT ); Fri, 8 Oct 2021 19:50:19 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6A97560F5E; Fri, 8 Oct 2021 23:48:23 +0000 (UTC) Date: Fri, 8 Oct 2021 19:48:21 -0400 From: Steven Rostedt To: Yinan Liu Cc: mark-pk.tsai@mediatek.com, peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] scripts: ftrace - move the sort-processing in ftrace_init to compile time Message-ID: <20211008194821.3b6a18a4@oasis.local.home> In-Reply-To: <0b783c9e-c129-6907-0637-5c7638158a65@linux.alibaba.com> References: <20210911135043.16014-1-yinan@linux.alibaba.com> <20210911135043.16014-2-yinan@linux.alibaba.com> <20210911095937.5a298619@rorschach.local.home> <0b783c9e-c129-6907-0637-5c7638158a65@linux.alibaba.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 3 Oct 2021 21:42:10 +0800 Yinan Liu wrote: > Sorry for my slow progress . I have encountered some problems with the > sorting > of the module's mcount in compile time. The .ko file will be relocated > after insmod > or modprobe, most of the mcount relocation is based on .text section, > but there are > also a small part of mcount relocation based on .init.text section such > as module_init(). > The loading position of .init.text and .text does not seem to be in a > definite order. Right, there's no guarantee that the .text portion of a module is placed before or after the .init.text portion. > > For example, when I insmod ip_tables.ko twice, the front and back > positions of init.text > and .text are different, so we cannot sort the mcounts in the two > sections, which makes > the mcount sorting in the module meaningless. > > What is your opinion on this? Probably just keep the sorting algorithm in the kernel and take place on module load. If you still want to sort at compile time, then do the sort for .init functions separate from the .text ones, and have a way to extract this information (shouldn't be too hard) in the kernel at module load, and then just swap the init and text functions if they were added in the reverse order that was expect. The functions in .init will either be before all the functions in .text or after. They wont be intermingled. Thus, if they are both sorted, then they are placed correctly or the two groups of functions need to be switched. No other sorting should be necessary. -- Steve