Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp178544ybl; Tue, 7 Jan 2020 04:23:25 -0800 (PST) X-Google-Smtp-Source: APXvYqyYAXxRrpfpek8lA7RsEVC7Y1I8Zwbd/SdtxpE31uNJGh4Id8hhN1POYmn17wGJnNE8ng39 X-Received: by 2002:a9d:6c92:: with SMTP id c18mr106847539otr.157.1578399805622; Tue, 07 Jan 2020 04:23:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578399805; cv=none; d=google.com; s=arc-20160816; b=hpDwXRDC5aAAIXRd0Y9fY+yCxAAOZEmWZac3mDa8MDGIK9+/2p1ojQpIKGwUG3NP4Y Jx1UiArBdDomqBq5sBnDMntIz9ntbWc6cFMwGB1Utgj57k9UhwsBZ23t6w5ySQCjDqiu UyRsQbYMoXQO1+suRL/OHGVT2XTqwNWhfAYxm+zX9sAYfgOfWGEwABm4xoO0zuq5IyCZ ku8cMmj4KkmSPgp8sz9r+QhkwWEqpEOkLhx1hqqcO6LMs0YAAI9F5CSXS4/6OActTvJy vM9bBgpnGI/GT2rcG7rww/NWiJWQnNYKFZL+e+/NS9kkg9oYflGM67FV0KV+YGsfV6XU pT2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=hW/YZ5xCWThwjhEerlmA7j9jX6u1HwIksWbPU4X5VWA=; b=T0gyr867EcIPM3Pj5M1uU2EfIpgRPUUNx3eouVKlut0MkWAW/6FS4bdKJmBeDMzc33 uJgwO3hZDFg1GN37xqwm8AkJEiFMRPj0hoSyczMm0ZIV2ZDuY5Ys1OCru9VDbLmW6Rno 0OV1xolbJOYOVtz1/ELrG+P0w4KeSldOCJMvmTQQzPz14vXFoZ7Kujud/EkP5ZS+wYja qlKAx6SAUCgAOVCntAsMql+kwq+YTKjw9oJ6IrTQYApNu9LrWijqCd2ezaZC3tIZClCl GEm3S5fRXx9EHyFeGU3aYJ4NWrGCalZTf+NDz/NhPk+JLtMZMzj04iVtSPxFS3bqMF49 4Qsg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k10si5832345otf.237.2020.01.07.04.23.13; Tue, 07 Jan 2020 04:23:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728221AbgAGMWD (ORCPT + 99 others); Tue, 7 Jan 2020 07:22:03 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:20330 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728172AbgAGMWC (ORCPT ); Tue, 7 Jan 2020 07:22:02 -0500 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 007CHuUr048563 for ; Tue, 7 Jan 2020 07:22:01 -0500 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xar48suhv-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 07 Jan 2020 07:22:01 -0500 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Jan 2020 12:21:59 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 7 Jan 2020 12:21:58 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 007CLu2J54591720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jan 2020 12:21:56 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 576FF42041; Tue, 7 Jan 2020 12:21:56 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0CED442045; Tue, 7 Jan 2020 12:21:56 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.152.85.9]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 7 Jan 2020 12:21:55 +0000 (GMT) From: Thomas Richter To: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, acme@kernel.org, ak@linux.intel.com Cc: gor@linux.ibm.com, sumanthk@linux.ibm.com, heiko.carstens@de.ibm.com, Thomas Richter Subject: [PATCH] perf test: Fix test case Merge cpu map Date: Tue, 7 Jan 2020 13:21:50 +0100 X-Mailer: git-send-email 2.17.1 X-TM-AS-GCONF: 00 x-cbid: 20010712-0016-0000-0000-000002DB283B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20010712-0017-0000-0000-0000333D9EDB Message-Id: <20200107122150.9093-1-tmricht@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2020-01-07_03:2020-01-06,2020-01-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=2 clxscore=1015 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001070102 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit a2408a70368a ("perf evlist: Maintain evlist->all_cpus") introduces a test case for cpumap merge operation, see functions perf_cpu_map__merge() and test__cpu_map_merge(). The test case fails on s390 with this error message: [root@m35lp76 perf]# ./perf test -Fvvvvv 52 52: Merge cpu map : --- start --- cpumask list: 1-2,4-5,7 perf: /root/linux/tools/include/linux/refcount.h:131:\ refcount_sub_and_test: Assertion `!(new > val)' failed. Aborted (core dumped) [root@m35lp76 perf]# The root cause is in the function test__cpu_map_merge(): It creates two cpu_maps named 'a' and 'b': struct perf_cpu_map *a = perf_cpu_map__new("4,2,1"); struct perf_cpu_map *b = perf_cpu_map__new("4,5,7"); and creates a third map named 'c' which is the result of the merge of maps a and b: struct perf_cpu_map *c = perf_cpu_map__merge(a, b); After some verifaction of the merged cpu_map all three of them are have their reference count reduced and are freed: perf_cpu_map__put(a); (1) perf_cpu_map__put(b); perf_cpu_map__put(c); The release of perf_cpu_map__put(a) is wrong. The map is already released and free'ed as part of the function perf_cpu_map__merge(struct perf_cpu_map *orig, | struct perf_cpu_map *other) +--> perf_cpu_map__put(orig); | +--> cpu_map__delete(orig) At the end perf_cpu_map_put() is called for map 'orig' alias 'a' and since the reference count is 1, the map is deleted, as can be seen by the following gdb trace: (gdb) where #0 tcache_put (tc_idx=0, chunk=0x156cc30) at malloc.c:2940 #1 _int_free (av=0x3fffd49ee80 , p=0x156cc30, have_lock=) at malloc.c:4222 #2 0x00000000012d5e78 in cpu_map__delete (map=0x156cc40) at cpumap.c:31 #3 0x00000000012d5f7a in perf_cpu_map__put (map=0x156cc40) at cpumap.c:45 #4 0x00000000012d723a in perf_cpu_map__merge (orig=0x156cc40, other=0x156cc60) at cpumap.c:343 #5 0x000000000110cdd0 in test__cpu_map_merge ( test=0x14ea6c8 , subtest=-1) at tests/cpumap.c:128 Thus the perf_cpu_map__put(a) (see (1) above) frees map 'a' a second time and causes the failure. Fix this be removing that function call. Output after: [root@m35lp76 perf]# ./perf test -Fvvvvv 52 52: Merge cpu map : --- start --- cpumask list: 1-2,4-5,7 ---- end ---- Merge cpu map: Ok [root@m35lp76 perf]# Signed-off-by: Thomas Richter --- tools/perf/tests/cpumap.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/tests/cpumap.c b/tools/perf/tests/cpumap.c index 4ac56741ac5f..29c793ac7d10 100644 --- a/tools/perf/tests/cpumap.c +++ b/tools/perf/tests/cpumap.c @@ -131,7 +131,6 @@ int test__cpu_map_merge(struct test *test __maybe_unused, int subtest __maybe_un TEST_ASSERT_VAL("failed to merge map: bad nr", c->nr == 5); cpu_map__snprint(c, buf, sizeof(buf)); TEST_ASSERT_VAL("failed to merge map: bad result", !strcmp(buf, "1-2,4-5,7")); - perf_cpu_map__put(a); perf_cpu_map__put(b); perf_cpu_map__put(c); return 0; -- 2.21.0