From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1CE99C433EF for ; Tue, 15 Feb 2022 19:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xYaq48w21eU4wgRHP5V4XVs9FSYYNKW3wAcIPmnbpGg=; b=qKz9PL9aDiKOOV QCpWj/zfmFPNDKYLSsFO21J7htLKaF46IKoapM4DsEGfQ73mv01T/2B4GHOS5q213GylAbveHxgEC 0FLZoiIOYcH8rwrEUP9+BiqT7shEWGI3bGJPRtVD3woVM+VmLR/fP82/nvakVXswO1cbu5OzP7jm3 tfaYQuhEjcb+6R3xFIqHrevIjTa6P6AoVfukyqqimw6663B98JEuENd7Yb92qRJXqZnFiLlZ92FoL OKcb941jAqJFLXK5dDECu6esiMPj9oiXqsoWe5a7co/hEP3IQhLzvs0BThtV3QNHYF7n+mTBvZbZQ rOuLFo1fXSKq04f8W6YA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nK34d-004CR9-IK; Tue, 15 Feb 2022 19:01:15 +0000 Received: from mail-il1-f180.google.com ([209.85.166.180]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nK34Y-004CNG-Js for linux-arm-kernel@lists.infradead.org; Tue, 15 Feb 2022 19:01:11 +0000 Received: by mail-il1-f180.google.com with SMTP id n5so15570017ilk.12 for ; Tue, 15 Feb 2022 11:01:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UBBmp4DgxbJ3nAuN//yjsP9FmwDmp49m+83tg2kI50Y=; b=WLghsF6qRl+NeC2Dq9OqzADhfQ8HEPRgsJT3cBGn7B2rdS7e0UgX/XSlfcW5CgBZdf 7nOibP+YD5CNEO4aaqJUZIlFgahBTTuVXKEZSu4QQ0XB6918FShJ9JQeuoZp7dcNDqx2 BSx941X+q7N0jiDa6hbhgRr6vyCqn2LasXMxlulk3GDyJT/A/EQU6gwNZLN+ZnGc0VmZ F3QqoXPK/BML+L4OpvEx2AnnkXZJdspcQC9wbXhZUIFE5cB1SdG4Es/gjoSB2UN927nm i/1w6xuge+1S1ED2zuitnD35WExiqeTT02Bf5r/2SyhU8afH0bglXKl6jAmBgleKYQN7 L7kg== X-Gm-Message-State: AOAM530mqOnEK8+LV+oHO7obEbEsiH8j4AqSR5EIhAIj4dB8Q9Gg9o9q Dr2CH8OLCIZHjGgaQyEvIA== X-Google-Smtp-Source: ABdhPJzr1JvD7wkz7BTuJejx6Q5hZPGEsJZTOE5TvygVd8PbAcJonZNUWrC4RHzDEmQr1FWxeEBVHA== X-Received: by 2002:a05:6e02:1687:: with SMTP id f7mr281589ila.143.1644951668921; Tue, 15 Feb 2022 11:01:08 -0800 (PST) Received: from robh.at.kernel.org ([64.188.179.250]) by smtp.gmail.com with ESMTPSA id q18sm18818854ils.78.2022.02.15.11.01.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Feb 2022 11:01:08 -0800 (PST) Received: (nullmailer pid 3747771 invoked by uid 1000); Tue, 15 Feb 2022 19:01:06 -0000 Date: Tue, 15 Feb 2022 13:01:06 -0600 From: Rob Herring To: Mark Rutland , Anshuman Khandual Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Will Deacon Subject: Re: [PATCH 2/2] perf: Expand perf_branch_entry.type Message-ID: References: <1643348653-24367-1-git-send-email-anshuman.khandual@arm.com> <1643348653-24367-3-git-send-email-anshuman.khandual@arm.com> <6168f881-92a4-54f8-929a-c2f40a36c112@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220215_110110_681900_85DD53A8 X-CRM114-Status: GOOD ( 32.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 04, 2022 at 04:02:04PM +0000, Mark Rutland wrote: > On Fri, Feb 04, 2022 at 10:25:24AM +0530, Anshuman Khandual wrote: > > On 2/2/22 5:27 PM, Mark Rutland wrote: > > > On Fri, Jan 28, 2022 at 11:14:13AM +0530, Anshuman Khandual wrote: > > >> @@ -1370,8 +1376,8 @@ struct perf_branch_entry { > > >> in_tx:1, /* in transaction */ > > >> abort:1, /* transaction abort */ > > >> cycles:16, /* cycle count to last branch */ > > >> - type:4, /* branch type */ > > >> - reserved:40; > > >> + type:6, /* branch type */ > > > > > > As above, is this a safe-change ABI-wise? > > > > If the bit fields here cannot be expanded without breaking ABI, then > > there is a fundamental problem. Only remaining option will be to add > > new fields (with new width value) which could accommodate these new > > required branch types. > > Unfortunately, I think expanding this does break ABI, and is a fundamental > problem, as: > > (a) Any new values in the expanded field will be truncated when read by old > userspace, and so those may be mis-reported. Maybe we're not too worried > about this case. 'type' or specfically branch stack is not currently supported on arm64. Do we expect an old userspace which this didn't work on to start working with a new kernel? Given at least some of the new types are arch specific, perhaps the existing type field should get a new 'PERF_BR_ARCH_SPECIFIC' or 'PERF_BR_EXTENDED' value (or use PERF_BR_UNKNOWN?) which means read a new 'arch_type' field. Another option is maybe some of these additional types just shouldn't be exposed to userspace? For example, are branches to FIQ useful or leaking any info about secure world? Debug mode branches also seem minimally useful to me (though I'm no expert in how this is used). > (b) Depending on how the field is placed, existing values might get stored > differently. This could break any mismatched combination of > {old,new}-kernel and {old,new}-userspace. > > In practice, I think this means that this is broken for BE, and happens to > work for LE, but I don't know how bitfields are defined for each > architecture, so there could be other brokenness. > > Consider the test case below: [...] > ... where the low bits of the field have moved, and so this is broken even for > existing values! So that is a separate issue to be fixed and not directly related to the size of 'type'. Looks like it needs similar '#if defined(__LITTLE_ENDIAN_BITFIELD)' treatment as some of the other struct bitfields. Though somehow BE PPC hasn't had issues? Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel