Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2284390iof; Wed, 8 Jun 2022 01:24:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwb8aFR7Gzth/Vz+eH1VYyF4GFhkmmD5NgWcyVUw7By0CuaoCLyTHboepgjQPtsVJhEPa4T X-Received: by 2002:a17:903:1248:b0:151:9708:d586 with SMTP id u8-20020a170903124800b001519708d586mr32979484plh.15.1654676683843; Wed, 08 Jun 2022 01:24:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654676683; cv=none; d=google.com; s=arc-20160816; b=TC/uXkSwriCVyqmyOtVB4nVUuTrkzU4j35/TrPwhunr7wwk+eGbS9Z+l+GjKKvkTrI AR3Y3GnWlV5+2Ah6n+4iT1ezKIyyo8AcDL9azars2+6uPjpAYgbJ6KxtOIrtzhqaGkD6 1qQqnYjlPeCrQGFtmz//N6lqQBYWfj4jF6uE8ChKYqz47v78mvz6S7jBSrh2hdrXjg4l 9g8EVcbRgoNN6kViMlk4Sx3NSc+UwSvR5rr1x7NAlBiFWyIg5D+AJC4EgSPMrM3U/2St 33VrW6nrteXaOPM6bVGXqW76La0PePBIRH89gGMR5YJXq3KkPboMv5kPhO8/oHQ4rSxO A8Ig== 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=bF7olC4KlswwOpTCIDnJ4KASpvqTQfsf0IhcaXCXupo=; b=nEfHX1o5nbqbA81OzvDQHDXncyj1JYCQZFPgqidD6agl8ePt4lmsQDVDL5YuYHVX2r bZN+XSQs9ZY8zdX3amaLnoePixXKO7veKrMOv/zUw5GbR/6TkKpcNEBkEVd6zlWLIqDe XeSPIBm48LkuhD5DMsx4HNnYmz04/pKXmDqY95nIA/1NYGWsQlXeNDCCHJ8rJ+jSS0oz 4dQLuWNMTh7gMcUUJJxfTyVXgmqvyHUdxCNzNQdKWHK3N7OG1ZymeC2Ay3ewUK7Q0AP7 rZ5xwsb/q11ksUxsOjQTU9tcYzjD4meok3Lbo6Y2ue9o3zNrdXDvzLyoZF09W+OoA/EM zRBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kRNTOM63; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id l15-20020a170903120f00b00161c545c5c3si34753851plh.601.2022.06.08.01.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 01:24:43 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kRNTOM63; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0F4AD1D8080; Wed, 8 Jun 2022 00:55:37 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348108AbiFGRmJ (ORCPT + 99 others); Tue, 7 Jun 2022 13:42:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347596AbiFGRaw (ORCPT ); Tue, 7 Jun 2022 13:30:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BF6D4FF5AE; Tue, 7 Jun 2022 10:27:37 -0700 (PDT) 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 78EC9B822B0; Tue, 7 Jun 2022 17:27:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE9BBC385A5; Tue, 7 Jun 2022 17:27:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654622855; bh=f15wNlRoY4rStJEgJPLKlAn0P6gzOzR/k90BBXc8Atk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kRNTOM63kj/fkrmDxCpK7gnXZjmu1wlIF2atS2UJpxL16CrQClTFh8G+0aDAiaHkS i6FhHC/iyoVubKnv9J6uxFSXF1gEHzZIiYqOKjGwIURJTVWIdEDLtdiqs2MW4vKzHy Lo6iGDHyPyxa5XQAB7vSMDhrahDzj905PMp+TkO4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dmitry Monakhov , Peter Zijlstra , Ravi Bangoria , Sasha Levin Subject: [PATCH 5.10 200/452] perf/amd/ibs: Use interrupt regs ip for stack unwinding Date: Tue, 7 Jun 2022 19:00:57 +0200 Message-Id: <20220607164914.523627774@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164908.521895282@linuxfoundation.org> References: <20220607164908.521895282@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=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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: Ravi Bangoria [ Upstream commit 3d47083b9ff46863e8374ad3bb5edb5e464c75f8 ] IbsOpRip is recorded when IBS interrupt is triggered. But there is a skid from the time IBS interrupt gets triggered to the time the interrupt is presented to the core. Meanwhile processor would have moved ahead and thus IbsOpRip will be inconsistent with rsp and rbp recorded as part of the interrupt regs. This causes issues while unwinding stack using the ORC unwinder as it needs consistent rip, rsp and rbp. Fix this by using rip from interrupt regs instead of IbsOpRip for stack unwinding. Fixes: ee9f8fce99640 ("x86/unwind: Add the ORC unwinder") Reported-by: Dmitry Monakhov Suggested-by: Peter Zijlstra Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220429051441.14251-1-ravi.bangoria@amd.com Signed-off-by: Sasha Levin --- arch/x86/events/amd/ibs.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c index 780d89d2ae32..8a85658a24cc 100644 --- a/arch/x86/events/amd/ibs.c +++ b/arch/x86/events/amd/ibs.c @@ -312,6 +312,16 @@ static int perf_ibs_init(struct perf_event *event) hwc->config_base = perf_ibs->msr; hwc->config = config; + /* + * rip recorded by IbsOpRip will not be consistent with rsp and rbp + * recorded as part of interrupt regs. Thus we need to use rip from + * interrupt regs while unwinding call stack. Setting _EARLY flag + * makes sure we unwind call-stack before perf sample rip is set to + * IbsOpRip. + */ + if (event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) + event->attr.sample_type |= __PERF_SAMPLE_CALLCHAIN_EARLY; + return 0; } @@ -692,6 +702,14 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs) data.raw = &raw; } + /* + * rip recorded by IbsOpRip will not be consistent with rsp and rbp + * recorded as part of interrupt regs. Thus we need to use rip from + * interrupt regs while unwinding call stack. + */ + if (event->attr.sample_type & PERF_SAMPLE_CALLCHAIN) + data.callchain = perf_callchain(event, iregs); + throttle = perf_event_overflow(event, &data, ®s); out: if (throttle) { -- 2.35.1