Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp7898114rwn; Wed, 14 Sep 2022 06:13:25 -0700 (PDT) X-Google-Smtp-Source: AA6agR6LFYOSG5xN/OX9NvUYikm4KKM/OoF+Zkb37aPI8n41ZBTC/gRQxoQSuy9XXKbYXVspc5oH X-Received: by 2002:a05:6a00:198e:b0:541:f85a:6c27 with SMTP id d14-20020a056a00198e00b00541f85a6c27mr19414977pfl.81.1663161205364; Wed, 14 Sep 2022 06:13:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663161205; cv=none; d=google.com; s=arc-20160816; b=ctB1bBeJcXFGzWjYMeC+kS4HNR+lJmC3i6MMOCtWyVmIC5LLUMHJisuO2wnCzmvxD7 yXIrAlFgPy5ohATHJ9R1DOt4EZWHHchuknTtcDIHu6gFdnNQfDN+ah/n7ov2YClOX3rh 1kbmay5YY252I3FQf5rxBNh4A4ym7M7KjGLz3CYsj8MZyLHQQOOLYPd9+aU4XyHn8H1J 8tm/mUjAMuyazG0C7E8JdCPzJCdtbRMutx+f8mVoqMrixw8eyL4geXMKVg3NQk76DTw6 +z9/4GU9zpbLAK+WIdULptvfGly3hOWwzYceENfjg3o9HrQUIpyB/1mC0DqRkP6dAEFH iEeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:organization :mime-version:message-id:date:subject:cc:to:from:dkim-signature; bh=D8L4JKPcergxufM6vKVo02neZ/gJSaDKmvzZ5SX73iI=; b=XVKBMT3oAFgkVvr2+S5/SuVdntUcW7BLrLs6rmdEUI9KrRR2Snz81IoC6p9F86OEpw dAyDZy5J1BHiM5AGtF0/33Z6eLSNYHYpjitRWdYdykdtJO/+Ti2g5IrWWhiGFzJIW7nx 36Sh05uHktLMhEgLarmicW7cRtu8VgAU/Yotv0YkJh94o+RAL3+pnhHCOmzEy3P5MsH/ JDP9oya8vENV0YnSRq/JKMKIpoWxI18A1uY3E8kRkj4VntUV2OXpXnFsU0BeRT650VTf gS3rtJ4m03TIBmZhr1DgKJ8WzwuuBzra/ttJB5xS9Hz6nHYumq8DQGqYWH0xaQYYO13u NSdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KIzi0VJQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d16-20020a170903231000b001782884c948si12492044plh.426.2022.09.14.06.13.11; Wed, 14 Sep 2022 06:13:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=KIzi0VJQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229751AbiINMYq (ORCPT + 99 others); Wed, 14 Sep 2022 08:24:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37240 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229520AbiINMYp (ORCPT ); Wed, 14 Sep 2022 08:24:45 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF1446461; Wed, 14 Sep 2022 05:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663158283; x=1694694283; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Q+9dbMUMn5Gtzb8375/dbn8RO/Ru0bbyWDSY78Ma/lU=; b=KIzi0VJQM+XJ8c4tC8NK4eax6PrPxlNi8kndFQNPDY3+2nKK0HEuBKLM J6AkcdUDc0eDpnpqIJPh4YUas7ZrWt1mdqwqoUin+m7urkstn2XBGx0qd aSf9U82Ap3J4Qc/SdHUaj+auWGool8X3jew1M+cwow+m9dLYtzgSKbakm ed3TTh6pstGBRkL/lQ8U3m0ZkwcQn7eDaIrTM8CpZi4IaMCdRTGH3v30H 8Kh+TVgt06VDMVtcZgDdSPaBYzz+KQFH9TS1Edd+PdGEx0YPzMTDFC4ec tM2Q0zCVNVoURVTrq4AFGDufUuuEh23TWqipHBV3ddQijioXlwyFeHIvP w==; X-IronPort-AV: E=McAfee;i="6500,9779,10470"; a="324666316" X-IronPort-AV: E=Sophos;i="5.93,315,1654585200"; d="scan'208";a="324666316" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2022 05:24:43 -0700 X-IronPort-AV: E=Sophos;i="5.93,315,1654585200"; d="scan'208";a="612489606" Received: from ahunter6-mobl1.ger.corp.intel.com (HELO ahunter-VirtualBox.home\044ger.corp.intel.com) ([10.252.32.55]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2022 05:24:40 -0700 From: Adrian Hunter To: Arnaldo Carvalho de Melo Cc: Jiri Olsa , Namhyung Kim , Ian Rogers , Daniel Dao , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: [PATCH] perf kcore_copy: Do not check /proc/modules is unchanged Date: Wed, 14 Sep 2022 15:24:29 +0300 Message-Id: <20220914122429.8770-1-adrian.hunter@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org /proc/kallsyms and /proc/modules are compared before and after the copy in order to ensure no changes during the copy. However /proc/modules also might change due to reference counts changing even though that does not make any difference. Any modules loaded or unloaded should be visible in changes to kallsyms, so it is not necessary to check /proc/modules also anyway. Remove the comparison checking that /proc/modules is unchanged. Reported-by: Daniel Dao Fixes: fc1b691d7651 ("perf buildid-cache: Add ability to add kcore to the cache") Signed-off-by: Adrian Hunter --- tools/perf/util/symbol-elf.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c index 75bec32d4f57..647b7dff8ef3 100644 --- a/tools/perf/util/symbol-elf.c +++ b/tools/perf/util/symbol-elf.c @@ -2102,8 +2102,8 @@ static int kcore_copy__compare_file(const char *from_dir, const char *to_dir, * unusual. One significant peculiarity is that the mapping (start -> pgoff) * is not the same for the kernel map and the modules map. That happens because * the data is copied adjacently whereas the original kcore has gaps. Finally, - * kallsyms and modules files are compared with their copies to check that - * modules have not been loaded or unloaded while the copies were taking place. + * kallsyms file is compared with its copy to check that modules have not been + * loaded or unloaded while the copies were taking place. * * Return: %0 on success, %-1 on failure. */ @@ -2166,9 +2166,6 @@ int kcore_copy(const char *from_dir, const char *to_dir) goto out_extract_close; } - if (kcore_copy__compare_file(from_dir, to_dir, "modules")) - goto out_extract_close; - if (kcore_copy__compare_file(from_dir, to_dir, "kallsyms")) goto out_extract_close; -- 2.25.1