From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Sasha Levin <sashal@kernel.org>,
linux-snps-arc@lists.infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU
Date: Wed, 27 Nov 2019 09:32:58 +0100 [thread overview]
Message-ID: <20191127083258.GA1834144@kroah.com> (raw)
In-Reply-To: <20191127080123.21890-1-abrodkin@synopsys.com>
On Wed, Nov 27, 2019 at 11:01:23AM +0300, Alexey Brodkin wrote:
> 8-letter strings representing ARC perf events are stores in two
> 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc.
>
> And the same order of bytes in the word is used regardless CPU endianness.
>
> Which means in case of big-endian CPU core we need to swap bytes to get
> the same order as if it was on little-endian CPU.
>
> Otherwise we're seeing the following error message on boot:
> ------------------------->8----------------------
> ARC perf : 8 counters (32 bits), 40 conditions, [overflow IRQ support]
> sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji'
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
> Stack Trace:
> arc_unwind_core+0xd4/0xfc
> dump_stack+0x64/0x80
> sysfs_warn_dup+0x46/0x58
> sysfs_add_file_mode_ns+0xb2/0x168
> create_files+0x70/0x2a0
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0
> Failed to register pmu: arc_pct, reason -17
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
> Stack Trace:
> arc_unwind_core+0xd4/0xfc
> dump_stack+0x64/0x80
> __warn+0x9c/0xd4
> warn_slowpath_fmt+0x22/0x2c
> perf_event_sysfs_init+0x70/0xa0
> ---[ end trace a75fb9a9837bd1ec ]---
> ------------------------->8----------------------
>
> What happens here we're trying to register more than one raw perf event
> with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters
> and encoded into two 32-bit words. In this particular case we deal with 2
> events:
> * "IJMP____" which counts all jump & branch instructions
> * "IJMPC___" which counts only conditional jumps & branches
>
> Those strings are split in two 32-bit words this way "IJMP" + "____" &
> "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core
> being big-endian then we read "PMJI" + "____" & "PMJI" + "___C".
>
> And since we interpret read array of ASCII letters as a null-terminated string
> on big-endian CPU we end up with 2 events of the same name "PMJI".
>
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: stable@vger.kernel.org
> ---
>
> Greg, Sasha, this is the same patch as
> commit 5effc09c4907 ("ARC: perf: Accommodate big-endian CPU")
> but fine-tuned to be applicable to kernels 4.19 and older.
Thanks, now queued up.
greg k-h
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: stable@vger.kernel.org, Sasha Levin <sashal@kernel.org>,
linux-snps-arc@lists.infradead.org
Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU
Date: Wed, 27 Nov 2019 09:32:58 +0100 [thread overview]
Message-ID: <20191127083258.GA1834144@kroah.com> (raw)
In-Reply-To: <20191127080123.21890-1-abrodkin@synopsys.com>
On Wed, Nov 27, 2019 at 11:01:23AM +0300, Alexey Brodkin wrote:
> 8-letter strings representing ARC perf events are stores in two
> 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc.
>
> And the same order of bytes in the word is used regardless CPU endianness.
>
> Which means in case of big-endian CPU core we need to swap bytes to get
> the same order as if it was on little-endian CPU.
>
> Otherwise we're seeing the following error message on boot:
> ------------------------->8----------------------
> ARC perf : 8 counters (32 bits), 40 conditions, [overflow IRQ support]
> sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji'
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
> Stack Trace:
> arc_unwind_core+0xd4/0xfc
> dump_stack+0x64/0x80
> sysfs_warn_dup+0x46/0x58
> sysfs_add_file_mode_ns+0xb2/0x168
> create_files+0x70/0x2a0
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0
> Failed to register pmu: arc_pct, reason -17
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3
> Stack Trace:
> arc_unwind_core+0xd4/0xfc
> dump_stack+0x64/0x80
> __warn+0x9c/0xd4
> warn_slowpath_fmt+0x22/0x2c
> perf_event_sysfs_init+0x70/0xa0
> ---[ end trace a75fb9a9837bd1ec ]---
> ------------------------->8----------------------
>
> What happens here we're trying to register more than one raw perf event
> with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters
> and encoded into two 32-bit words. In this particular case we deal with 2
> events:
> * "IJMP____" which counts all jump & branch instructions
> * "IJMPC___" which counts only conditional jumps & branches
>
> Those strings are split in two 32-bit words this way "IJMP" + "____" &
> "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core
> being big-endian then we read "PMJI" + "____" & "PMJI" + "___C".
>
> And since we interpret read array of ASCII letters as a null-terminated string
> on big-endian CPU we end up with 2 events of the same name "PMJI".
>
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: stable@vger.kernel.org
> ---
>
> Greg, Sasha, this is the same patch as
> commit 5effc09c4907 ("ARC: perf: Accommodate big-endian CPU")
> but fine-tuned to be applicable to kernels 4.19 and older.
Thanks, now queued up.
greg k-h
next prev parent reply other threads:[~2019-11-27 8:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 8:01 [PATCH] ARC: perf: Accommodate big-endian CPU Alexey Brodkin
2019-11-27 8:01 ` Alexey Brodkin
2019-11-27 8:32 ` Greg Kroah-Hartman [this message]
2019-11-27 8:32 ` Greg Kroah-Hartman
-- strict thread matches above, loose matches on Subject: below --
2019-10-22 14:04 Alexey Brodkin
2019-10-22 14:04 ` Alexey Brodkin
2019-10-26 13:10 ` Sasha Levin
2019-11-05 19:52 ` Alexey Brodkin
2019-11-05 19:52 ` Alexey Brodkin
2019-11-21 20:39 ` Greg Kroah-Hartman
2019-11-21 20:39 ` Greg Kroah-Hartman
2019-11-27 8:02 ` Alexey Brodkin
2019-11-27 8:02 ` Alexey Brodkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191127083258.GA1834144@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Alexey.Brodkin@synopsys.com \
--cc=linux-snps-arc@lists.infradead.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.