Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1882788pxp; Mon, 7 Mar 2022 04:33:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJx6uJ5ttuSBsYlei23R8sNAr+ZINMifiSL5WcIEOYDFvgG2tOMIr6TxbbTj6QOx9GR0fLLr X-Received: by 2002:a17:907:8a0a:b0:6d8:85a6:4d42 with SMTP id sc10-20020a1709078a0a00b006d885a64d42mr9401527ejc.138.1646656435525; Mon, 07 Mar 2022 04:33:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646656435; cv=none; d=google.com; s=arc-20160816; b=xGh1YfzNm7BPIKFKgx14v3XJg+634HzdzqUAz309XhhWOPMyi4Arw7AgBKxL/Sp2Mq 5z340SuY4Vqy0fVegZquQOmQdjetVWS5jeOQr8OBv0q6UJpISChkPFGGb5OWC17pijas VH68hi/Cy48TNw8+4xmx6cwwc5tVWF/BBLqtpRf8UKxf4PBs8/0QKAopTbmnialDJKmg hKI6gw+rkeWtoErQxi2/nd9WqGj7li598BaB+kVU7wVNy6dtKemPKH/d1AOoQ4KmFuuH gNPLkwbftXSkX54/U3UN3SKYEUbNm/DVxXa2UWbqawsby92Qu2DLvseMo3GrScBDY1in xUvw== 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=0MkWaYRzOAWaM4vv4otFDkSusmurRmrZTm9Vja443UY=; b=q7aRWHPInmGCfexplhC+KkUf6n/Jt83sL6PpUh/HdvxGPPkb0+90dFqh3+kHBmt4Cg 1y0SeRi757enoPSoSy7671BkK7JQ6tHVWpS31CtxQHn4vlXlI/MKsvrqrku/58glcL+/ 2mEdAfeoY66jpFYj3aeNo3sAWVMYPwoI7aZOQXRijus6o7ToNXQjs875lZhnR6ZuUsMP Cr+Nl9aEJhoVWACSL3w0GfS2nIIrUHVm6lpUf7KJNeQhvcJRo4pQ84kZ/HdKSOi25E19 JCdSKu09f/0fDlVf09BfwgnS/AuvtDac290D/4okURw0rRoRfqE++INhk+gjOOQez2n2 L7nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Dt89HROO; 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 p2-20020a17090635c200b006cee1df7efbsi7149854ejb.5.2022.03.07.04.33.26; Mon, 07 Mar 2022 04:33:55 -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=Dt89HROO; 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 S241742AbiCGKVJ (ORCPT + 99 others); Mon, 7 Mar 2022 05:21:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240386AbiCGKA7 (ORCPT ); Mon, 7 Mar 2022 05:00:59 -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 48AE21AD97; Mon, 7 Mar 2022 01:47:51 -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 EAE96B810A8; Mon, 7 Mar 2022 09:47:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41944C340F3; Mon, 7 Mar 2022 09:47:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646646468; bh=8ad7hhpsKaQKZ/x+ehmMy/jaSuprqSGytdAm0fQADec=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dt89HROOB8Kg97pE03yEbIpYCPYzyYRxSo9fhwAVunxZDMcQQYv8HAAddEO722z0p cPV6Zp8AWLau/5f7J47BfEo1GTlCR9zkzhSU5Yux3yl5udN1Bze7BxUXnlxr3+7yhK YH9Qsioqz2dNj8McZ/XHE7ymd0X9K0+NYi1Y+lIw= 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 5.15 252/262] tracing/histogram: Fix sorting on old "cpu" value Date: Mon, 7 Mar 2022 10:19:56 +0100 Message-Id: <20220307091710.759260026@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091702.378509770@linuxfoundation.org> References: <20220307091702.378509770@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 @@ -2049,9 +2049,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(tr, HIST_ERR_FIELD_NOT_FOUND, @@ -4478,7 +4478,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))