Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1778022pxp; Mon, 7 Mar 2022 02:05:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+lfl1YA05AHhZWWBoPnRvCnLhFMxPN12C8ni9d9DLbJczOXfL2Se+ufL3Lcnkqe3svcZV X-Received: by 2002:a05:6402:43cd:b0:416:5064:b3a0 with SMTP id p13-20020a05640243cd00b004165064b3a0mr2472107edc.44.1646647545977; Mon, 07 Mar 2022 02:05:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646647545; cv=none; d=google.com; s=arc-20160816; b=Xi1owxk9YSyhQsZVGt7TYgWtWyxx1ellRSHyDEwZZIZiCca6whrq1A4Zk+RGpJBPUY 9gWwlBxauf+d1R78wIWKAqvf7OYhCOI/FwYCGr2RkgSY2iqO8vs2C61J8MkeYOlNt8as ziJnLhk9z8e9xCqx+oZfhT1N3WBT4Gtjh0xxzBapGjz7ap1iB9Br28Bgtgv77Ak+eDv/ CDHqgCwWsa1U46aBSmKx+HblhJx0e1rcQq1mBct3EbHFZkxnrfQL5hG6s2q1xP2/ePTE LTyou9o1TVsKcWBdtulK4g6HlNKFu/Y8y6m9Jzeq0w3i+avZNyEao/C56LE8lwydj+7M W7TQ== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=09cQ+k+2yL/DAAQuf0Vg/qEF3iz0y1EmvNU6V+vyYdc=; b=v1eIaBJ7466shoNU+vH3tmzgd4GmktpCjgkAQU1Ov8+7bOoSCePLtp9VK3zfq2wZyS llVfTIifYuTR8yFQE8aGhw4nqBR6MeN7+xWeEs3Tf/nW7neHxcJqf7EkEqd7+M9bJa4p ufGjqNiwI0uO2axxvCeHacSEj1/2mZsRwSPihcxOu6ODmejGcSx+hFYWKBcIkMrwvDG/ Izu+ShTE88UJqxbs2BGU+09WZanujZZgASvjig4a7Oto8/E142pKm3BB5wdy0efwqCA6 GWg7VgErwvoMSwAv1JOe93YwbLafX++OXoHIbHjDSUz2c1zT5lS/EAG/Sk2oawL3WOn/ KLOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OoUjF9iY; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y13-20020a056402358d00b00410d41d96ddsi12202964edc.76.2022.03.07.02.05.23; Mon, 07 Mar 2022 02:05:45 -0800 (PST) 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=@linuxfoundation.org header.s=korg header.b=OoUjF9iY; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237354AbiCGJcc (ORCPT + 99 others); Mon, 7 Mar 2022 04:32:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237588AbiCGJ2P (ORCPT ); Mon, 7 Mar 2022 04:28:15 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD7E959A53; Mon, 7 Mar 2022 01:25:38 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6902BB810C0; Mon, 7 Mar 2022 09:25:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A746C340F3; Mon, 7 Mar 2022 09:25:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646645136; bh=HWYJjQ/cZgIGMRUPf4mSbGH1m7UM1K6qwwDWI70pjBQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OoUjF9iYC79AQ2Dz9nSvI5FfsKA3Myq/vwn6JHTIyl2jFla/wyShParQplixZpuJo qv5jRR14yHxlnKb+CWyZfiaRhnHSJtqzvyEInUw6hsM1IEZz3XKNczRxMiM8DHs40U vzcim8sISEVuQETh7HTe1cdz40/6U3dh+J8uQxqo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Bristot de Oliveira , "Steven Rostedt (Google)" Subject: [PATCH 4.19 49/51] tracing/histogram: Fix sorting on old "cpu" value Date: Mon, 7 Mar 2022 10:19:24 +0100 Message-Id: <20220307091638.385184567@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091636.988950823@linuxfoundation.org> References: <20220307091636.988950823@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,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 From: Steven Rostedt (Google) commit 1d1898f65616c4601208963c3376c1d828cbf2c7 upstream. When trying to add a histogram against an event with the "cpu" field, it was impossible due to "cpu" being a keyword to key off of the running CPU. So to fix this, it was changed to "common_cpu" to match the other generic fields (like "common_pid"). But since some scripts used "cpu" for keying off of the CPU (for events that did not have "cpu" as a field, which is most of them), a backward compatibility trick was added such that if "cpu" was used as a key, and the event did not have "cpu" as a field name, then it would fallback and switch over to "common_cpu". This fix has a couple of subtle bugs. One was that when switching over to "common_cpu", it did not change the field name, it just set a flag. But the code still found a "cpu" field. The "cpu" field is used for filtering and is returned when the event does not have a "cpu" field. This was found by: # cd /sys/kernel/tracing # echo hist:key=cpu,pid:sort=cpu > events/sched/sched_wakeup/trigger # cat events/sched/sched_wakeup/hist Which showed the histogram unsorted: { cpu: 19, pid: 1175 } hitcount: 1 { cpu: 6, pid: 239 } hitcount: 2 { cpu: 23, pid: 1186 } hitcount: 14 { cpu: 12, pid: 249 } hitcount: 2 { cpu: 3, pid: 994 } hitcount: 5 Instead of hard coding the "cpu" checks, take advantage of the fact that trace_event_field_field() returns a special field for "cpu" and "CPU" if the event does not have "cpu" as a field. This special field has the "filter_type" of "FILTER_CPU". Check that to test if the returned field is of the CPU type instead of doing the string compare. Also, fix the sorting bug by testing for the hist_field flag of HIST_FIELD_FL_CPU when setting up the sort routine. Otherwise it will use the special CPU field to know what compare routine to use, and since that special field does not have a size, it returns tracing_map_cmp_none. Cc: stable@vger.kernel.org Fixes: 1e3bac71c505 ("tracing/histogram: Rename "cpu" to "common_cpu"") Reported-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman --- kernel/trace/trace_events_hist.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -2635,9 +2635,9 @@ parse_field(struct hist_trigger_data *hi /* * For backward compatibility, if field_name * was "cpu", then we treat this the same as - * common_cpu. + * common_cpu. This also works for "CPU". */ - if (strcmp(field_name, "cpu") == 0) { + if (field && field->filter_type == FILTER_CPU) { *flags |= HIST_FIELD_FL_CPU; } else { hist_err("Couldn't find field: ", field_name); @@ -4642,7 +4642,7 @@ static int create_tracing_map_fields(str if (hist_field->flags & HIST_FIELD_FL_STACKTRACE) cmp_fn = tracing_map_cmp_none; - else if (!field) + else if (!field || hist_field->flags & HIST_FIELD_FL_CPU) cmp_fn = tracing_map_cmp_num(hist_field->size, hist_field->is_signed); else if (is_string_field(field))