[yocto] [meta-zephyr][master][langdale][PATCH] zephyr-kernel/3.1: update to latest commit

2022-12-19 Thread Naveen Saini 
Recent commits have CVE-2022-2741 fixed.

Also backported CVE-2022-2993 fix.

Signed-off-by: Naveen Saini 
---
 ...ix-SMP-local-keys-check-when-startin.patch | 51 +++
 .../zephyr-kernel/zephyr-kernel-src-3.1.0.inc |  3 +-
 2 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 
meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch

diff --git 
a/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch
 
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch
new file mode 100644
index 000..68650c3
--- /dev/null
+++ 
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/files/0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch
@@ -0,0 +1,51 @@
+From 74d26b70f080a5dc60c6a1aa2bfec38043ee30d4 Mon Sep 17 00:00:00 2001
+From: Joakim Andersson 
+Date: Fri, 5 Aug 2022 10:50:47 +0200
+Subject: [PATCH] Bluetooth: host: Fix SMP local keys check when starting
+ encryption
+
+Fix SMP check of existing local keys when attempting to start security
+with required security mode 1 level 4. The logic for checking the
+conditions was wrong, leading to a situation where encryption would be
+attempted to be started by the central instead of initiating a new
+pairing procedure. This would fail when the connection was encrypted and
+the connection would be disconnected.
+
+Upstream-Status: Backport 
[https://github.com/zephyrproject-rtos/zephyr/commit/83d5402fe830973f943bde085d80f0d3643e811a]
+https://github.com/zephyrproject-rtos/zephyr/pull/52947/files
+CVE: CVE-2022-2993
+
+Signed-off-by: Joakim Andersson 
+Signed-off-by: Naveen Saini 
+---
+ subsys/bluetooth/host/smp.c | 10 +-
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/subsys/bluetooth/host/smp.c b/subsys/bluetooth/host/smp.c
+index 02a847f97d..555f09fefd 100644
+--- a/subsys/bluetooth/host/smp.c
 b/subsys/bluetooth/host/smp.c
+@@ -357,15 +357,15 @@ static bool smp_keys_check(struct bt_conn *conn)
+   return false;
+   }
+ 
+-  if (conn->required_sec_level > BT_SECURITY_L2 &&
++  if (conn->required_sec_level >= BT_SECURITY_L3 &&
+   !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED)) {
+   return false;
+   }
+ 
+-  if (conn->required_sec_level > BT_SECURITY_L3 &&
+-  !(conn->le.keys->flags & BT_KEYS_AUTHENTICATED) &&
+-  !(conn->le.keys->keys & BT_KEYS_LTK_P256) &&
+-  !(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE)) {
++  if (conn->required_sec_level >= BT_SECURITY_L4 &&
++  !((conn->le.keys->flags & BT_KEYS_AUTHENTICATED) &&
++(conn->le.keys->keys & BT_KEYS_LTK_P256) &&
++(conn->le.keys->enc_size == BT_SMP_MAX_ENC_KEY_SIZE))) {
+   return false;
+   }
+ 
+-- 
+2.25.1
+
diff --git 
a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc 
b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
index 68016e4..b3feb6a 100644
--- a/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
+++ b/meta-zephyr-core/recipes-kernel/zephyr-kernel/zephyr-kernel-src-3.1.0.inc
@@ -2,7 +2,7 @@
 
 SRCREV_FORMAT = "default"
 
-SRCREV_default = "2ddd73feafd3316af2c547c34d6969bea637d5c6"
+SRCREV_default = "a7d946331f4f9361d1531984524dd8f151ae20b0"
 SRCREV_canopennode = "53d3415c14d60f8f4bfca54bfbc5d5a667d7e724"
 SRCREV_chre = "0edfe2c2ec656afb910cfab8ed59a5ffd59b87c8"
 SRCREV_civetweb = "094aeb41bb93e9199d24d665ee43e9e05d6d7b1c"
@@ -109,6 +109,7 @@ SRC_URI_ZSCILIB ?= 
"git://github.com/zephyrproject-rtos/zscilib;protocol=https"
 SRC_URI_PATCHES ?= "\
 file://0001-3.1-cmake-add-yocto-toolchain.patch;patchdir=zephyr \
 
file://0001-3.1-x86-fix-efi-binary-generation-issue-in-cross-compila.patch;patchdir=zephyr
 \
+
file://0001-3.1-Bluetooth-host-Fix-SMP-local-keys-check-when-startin.patch;patchdir=zephyr
 \
 "
 
 SRC_URI = "\
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58839): https://lists.yoctoproject.org/g/yocto/message/58839
Mute This Topic: https://lists.yoctoproject.org/mt/95782023/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Issue with accessing network from a recipe

2022-12-19 Thread Gärding Antti via lists . yoctoproject . org 
Hi,

Thanks! That helped my team find out a solution or at least a work-around: 
setting do_configure[network] and do_compile[network] to "1" in local.conf.

I would have another related questions, though: Should the commands requiring 
network access work if they are invoked from do_fetch? I tried that and it 
didn't work.


Best regards,
Antti Gärding


Kohteesta: Martin Jansa 
Lähetetty: maanantaina 19. joulukuuta 2022 klo 16.16
Vastaanottaja: Gärding Antti 
Kopio: yocto@lists.yoctoproject.org 
Aihe: Re: [yocto] Issue with accessing network from a recipe

Hi,

that is intentional, recipes should fetch sources with bitbake fetcher (which 
respects MIRROR/PREMIRROR/DL_DIR etc) in do_fetch and network shouldn't be used 
in other tasks (unless explicitly enabled in well explained exceptions).

bitbake can now restrict network access in various tasks based on "network" 
flag as implemented in:
  
https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543
  
https://git.openembedded.org/bitbake/commit/?id=9d6341df611a1725090444f6f8eb0244aed08213
and oe now enables network mostly only in do_fetch and few special tasks as 
implemented in:
  
https://git.openembedded.org/openembedded-core/commit/?id=7ce1e88a3ad85bbb925bb9f7167dc0a5fd1c27f4

Regards,

On Mon, Dec 19, 2022 at 2:02 PM Gärding Antti via 
lists.yoctoproject.org
 
mailto:etteplan@lists.yoctoproject.org>>
 wrote:
Hi,

I am having an issue with a recipe whose do_configure requires network 
connections and I wonder if this issue could be related to Yocto so that this 
list would be the correct place to ask for ideas.

The problem appears when trying to build dotnet-hello-world which comes with 
meta-dotnet 
(https://github.com/jeremy-prater/meta-dotnet).
 I am not the only one having this issue, but many people, including the 
layer's author, also report having no problems. Googling gives a lot of 
suggestions, but as this is related to .NET, all of them are related to Windows 
/ Visual Studio environment and I don't know how to apply them using Yocto.

In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool 
dotnet as a host tool to fetch what is needed to build and run the program. As 
a part of that, it uses NuGet, the package manager for .NET, which says "error 
NU1301: Unable to load the service index for source 
https://api.nuget.org/v3/index.json".

If I modify the recipe so that it tries to curl that file, I get "Could not 
resolve host:

[yocto] [layerindex-web] [PATCH] layerindex/utils.py: Add to baseconfig=True for bb.parse.handle()

2022-12-19 Thread Robert Yang 
Bitbake's api has been changed via:
afb8478d3 parse: Add support for addpylib conf file directive and 
BB_GLOBAL_PYMODULES

The conf file won't be parsed without baseconfig=True:
bb.parse.ParseError: ParseError at /path/to/oe-core/meta/conf/layer.conf:132: 
unparsed line: 'addpylib ${LAYERDIR}/lib oe'

Signed-off-by: Robert Yang 
---
 layerindex/utils.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/layerindex/utils.py b/layerindex/utils.py
index 6566710..9d94015 100644
--- a/layerindex/utils.py
+++ b/layerindex/utils.py
@@ -314,7 +314,10 @@ def is_branch_valid(layerdir, branch):
 def parse_conf(conf_file, d):
 if hasattr(bb.parse, "handle"):
 # Newer BitBake
-data = bb.parse.handle(conf_file, d, include=True)
+if hasattr(bb.parse.parse_py.ConfHandler, "__addpylib_regexp__"):
+data = bb.parse.handle(conf_file, d, include=True, baseconfig=True)
+else:
+data = bb.parse.handle(conf_file, d, include=True)
 else:
 # Older BitBake (1.18 and below)
 data = bb.cooker._parse(conf_file, d)
-- 
2.37.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58837): https://lists.yoctoproject.org/g/yocto/message/58837
Mute This Topic: https://lists.yoctoproject.org/mt/95781944/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] M+ & H bugs with Milestone Movements WW51

2022-12-19 Thread Stephen Jolley 
All,

YP M+ or high bugs which moved to a new milestone in WW51 are listed below: 


Priority

Bug ID

Short Description

Changer

Owner

Was

Became


Medium+

  14467

curl timeout while dnf is downloading package

randy.macl...@windriver.com

sakib.sa...@windriver.com

4.2 M1

4.2 M2


 

  14522

qemuppc doesn't shutdown within timeout (serial console issues)

randy.macl...@windriver.com

sakib.sa...@windriver.com

4.2 M1

4.2 M2


 

  14825

AB-INT PTEST: tcl socket.test failure

randy.macl...@windriver.com

ross.bur...@arm.com

4.2 M1

4.2 M2


 

  14920

oe-selftest-armhost qemu x86-64 kernel NULL pointer dereference in 
handle_level_irq/setup_IO_APIC

randy.macl...@windriver.com

bruce.ashfi...@gmail.com

4.2 M1

4.2 M2


 

  14921

devtool failure: No such file or directory: 
'/tmp/devtoolqambdi_6eh/singletask.lock'

randy.macl...@windriver.com

richard.pur...@linuxfoundation.org

4.2 M1

4.2 M2

Thanks, 

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58836): https://lists.yoctoproject.org/g/yocto/message/58836
Mute This Topic: https://lists.yoctoproject.org/mt/95773102/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW50!

2022-12-19 Thread Stephen Jolley 
All,

The below were the owners of enhancements or bugs closed during the last
week!


Who

Count


tim.orl...@konsulko.com

1


Grand Total

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58835): https://lists.yoctoproject.org/g/yocto/message/58835
Mute This Topic: https://lists.yoctoproject.org/mt/95773087/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Current high bug count owners for Yocto Project 4.2

2022-12-19 Thread Stephen Jolley 
All,

Below is the list as of top 31 bug owners as of the end of WW51 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 89
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

35


ross.bur...@arm.com

30


randy.macl...@windriver.com

25


bruce.ashfi...@gmail.com

25


richard.pur...@linuxfoundation.org

23


david.re...@windriver.com

23


sakib.sa...@windriver.com

10


jpewhac...@gmail.com

10


saul.w...@windriver.com

9


zheng@windriver.com

5


pa...@zhukoff.net

5


alexandre.bell...@bootlin.com

4


tim.orl...@konsulko.com

4


sundeep.kokko...@gmail.com

3


hongxu@windriver.com

2


sundeep.kokko...@windriver.com

2


naveen.go...@windriver.com

2


s...@bigsur.com

2


akuster...@gmail.com

2


jon.ma...@arm.com

2


bluelightn...@bluelightning.org

2


anton.anto...@arm.com

1


martin.ja...@gmail.com

1


thomas.per...@bootlin.com

1


qi.c...@windriver.com

1


rybczyn...@gmail.com

1


workjagade...@gmail.com

1


aeh...@gmail.com

1


tvgamb...@gmail.com

1


martin.bee...@online.de

1


mhalst...@linuxfoundation.org

1


Grand Total

235

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58834): https://lists.yoctoproject.org/g/yocto/message/58834
Mute This Topic: https://lists.yoctoproject.org/mt/95772993/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2022-12-19 Thread Stephen Jolley 
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 414
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "4.2", "4.3", "4.99" and "Future", the more pressing/urgent
issues being in "4.2" and then "4.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58833): https://lists.yoctoproject.org/g/yocto/message/58833
Mute This Topic: https://lists.yoctoproject.org/mt/95772977/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Issue with accessing network from a recipe

2022-12-19 Thread Martin Jansa 
Hi,

that is intentional, recipes should fetch sources with bitbake fetcher
(which respects MIRROR/PREMIRROR/DL_DIR etc) in do_fetch and network
shouldn't be used in other tasks (unless explicitly enabled in well
explained exceptions).

bitbake can now restrict network access in various tasks based on "network"
flag as implemented in:

https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543

https://git.openembedded.org/bitbake/commit/?id=9d6341df611a1725090444f6f8eb0244aed08213
and oe now enables network mostly only in do_fetch and few special tasks as
implemented in:

https://git.openembedded.org/openembedded-core/commit/?id=7ce1e88a3ad85bbb925bb9f7167dc0a5fd1c27f4

Regards,

On Mon, Dec 19, 2022 at 2:02 PM Gärding Antti via lists.yoctoproject.org
 wrote:

> Hi,
>
>
>
> I am having an issue with a recipe whose do_configure requires network
> connections and I wonder if this issue could be related to Yocto so that
> this list would be the correct place to ask for ideas.
>
>
>
> The problem appears when trying to build dotnet-hello-world which comes
> with meta-dotnet (https://github.com/jeremy-prater/meta-dotnet). I am not
> the only one having this issue, but many people, including the layer's
> author, also report having no problems. Googling gives a lot of
> suggestions, but as this is related to .NET, all of them are related to
> Windows / Visual Studio environment and I don't know how to apply them
> using Yocto.
>
>
>
> In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool
> dotnet as a host tool to fetch what is needed to build and run the program.
> As a part of that, it uses NuGet, the package manager for .NET, which says
> "error NU1301: Unable to load the service index for source
> https://api.nuget.org/v3/index.json;.
>
>
>
> If I modify the recipe so that it tries to curl that file, I get "Could
> not resolve host: api.nuget.org". If I do the same but use numeric
> address, I get "Couldn't connect to server".
>
>
>
> If I run the commands in the recipe manually in the same environment I use
> for Yocto builds, using .NET SDK I have installed manually, they work.
>
>
>
> My build environment is Ubuntu 20.04 run inside a Docker container.
>
>
>
>
>
> Best regards,
>
> Antti Gärding
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58832): https://lists.yoctoproject.org/g/yocto/message/58832
Mute This Topic: https://lists.yoctoproject.org/mt/95764092/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 13/13] Documentation: arm64: Document PMU counters access from userspace

2022-12-19 Thread Adrian Zaharia 
From: Raphael Gault 

commit aa1005d15d2aee10e5b93a25db076c47e05c4efa upstream

Add documentation to describe the access to the pmu hardware counters from
userspace.

Signed-off-by: Raphael Gault 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20211208201124.310740-6-r...@kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Adrian Zaharia 
---
 Documentation/arm64/perf.rst | 78 +++-
 1 file changed, 77 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/perf.rst b/Documentation/arm64/perf.rst
index 9c76a97baf28..29b330999571 100644
--- a/Documentation/arm64/perf.rst
+++ b/Documentation/arm64/perf.rst
@@ -1,6 +1,9 @@
 .. SPDX-License-Identifier: GPL-2.0
 
-=
+
+Perf
+
+
 Perf Event Attributes
 =
 
@@ -86,3 +89,76 @@ exclude_host. However when using !exclude_hv there is a 
small blackout
 window at the guest entry/exit where host events are not captured.
 
 On VHE systems there are no blackout windows.
+
+Perf Userspace PMU Hardware Counter Access
+==
+
+Overview
+
+The perf userspace tool relies on the PMU to monitor events. It offers an
+abstraction layer over the hardware counters since the underlying
+implementation is cpu-dependent.
+Arm64 allows userspace tools to have access to the registers storing the
+hardware counters' values directly.
+
+This targets specifically self-monitoring tasks in order to reduce the overhead
+by directly accessing the registers without having to go through the kernel.
+
+How-to
+--
+The focus is set on the armv8 PMUv3 which makes sure that the access to the pmu
+registers is enabled and that the userspace has access to the relevant
+information in order to use them.
+
+In order to have access to the hardware counters, the global sysctl
+kernel/perf_user_access must first be enabled:
+
+.. code-block:: sh
+
+  echo 1 > /proc/sys/kernel/perf_user_access
+
+It is necessary to open the event using the perf tool interface with config1:1
+attr bit set: the sys_perf_event_open syscall returns a fd which can
+subsequently be used with the mmap syscall in order to retrieve a page of 
memory
+containing information about the event. The PMU driver uses this page to expose
+to the user the hardware counter's index and other necessary data. Using this
+index enables the user to access the PMU registers using the `mrs` instruction.
+Access to the PMU registers is only valid while the sequence lock is unchanged.
+In particular, the PMSELR_EL0 register is zeroed each time the sequence lock is
+changed.
+
+The userspace access is supported in libperf using the perf_evsel__mmap()
+and perf_evsel__read() functions. See `tools/lib/perf/tests/test-evsel.c`_ for
+an example.
+
+About heterogeneous systems
+---
+On heterogeneous systems such as big.LITTLE, userspace PMU counter access can
+only be enabled when the tasks are pinned to a homogeneous subset of cores and
+the corresponding PMU instance is opened by specifying the 'type' attribute.
+The use of generic event types is not supported in this case.
+
+Have a look at `tools/perf/arch/arm64/tests/user-events.c`_ for an example. It
+can be run using the perf tool to check that the access to the registers works
+correctly from userspace:
+
+.. code-block:: sh
+
+  perf test -v user
+
+About chained events and counter sizes
+--
+The user can request either a 32-bit (config1:0 == 0) or 64-bit (config1:0 == 
1)
+counter along with userspace access. The sys_perf_event_open syscall will fail
+if a 64-bit counter is requested and the hardware doesn't support 64-bit
+counters. Chained events are not supported in conjunction with userspace 
counter
+access. If a 32-bit counter is requested on hardware with 64-bit counters, then
+userspace must treat the upper 32-bits read from the counter as UNKNOWN. The
+'pmc_width' field in the user page will indicate the valid width of the counter
+and should be used to mask the upper bits as needed.
+
+.. Links
+.. _tools/perf/arch/arm64/tests/user-events.c:
+   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm64/tests/user-events.c
+.. _tools/lib/perf/tests/test-evsel.c:
+   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/tests/test-evsel.c
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12039): 
https://lists.yoctoproject.org/g/linux-yocto/message/12039
Mute This Topic: https://lists.yoctoproject.org/mt/95765181/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 12/13] arm64: perf: Enable PMU counter userspace access for perf event

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 83a7a4d643d33a8b74a42229346b7ed7139fcef9 upstream

Arm PMUs can support direct userspace access of counters which allows for
low overhead (i.e. no syscall) self-monitoring of tasks. The same feature
exists on x86 called 'rdpmc'. Unlike x86, userspace access will only be
enabled for thread bound events. This could be extended if needed, but
simplifies the implementation and reduces the chances for any
information leaks (which the x86 implementation suffers from).

PMU EL0 access will be enabled when an event with userspace access is
part of the thread's context. This includes when the event is not
scheduled on the PMU. There's some additional overhead clearing
dirty counters when access is enabled in order to prevent leaking
disabled counter data from other tasks.

Unlike x86, enabling of userspace access must be requested with a new
attr bit: config1:1. If the user requests userspace access with 64-bit
counters, then the event open will fail if the h/w doesn't support
64-bit counters. Chaining is not supported with userspace access. The
modes for config1 are as follows:

config1 = 0 : user access disabled and always 32-bit
config1 = 1 : user access disabled and always 64-bit (using chaining if needed)
config1 = 2 : user access enabled and always 32-bit
config1 = 3 : user access enabled and always 64-bit

Based on work by Raphael Gault , but has been
completely re-written.

Cc: Will Deacon 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Catalin Marinas 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-perf-us...@vger.kernel.org
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20211208201124.310740-5-r...@kernel.org
[will: Made armv8pmu_proc_user_access_handler() static]
Signed-off-by: Will Deacon 
Signed-off-by: Adrian Zaharia 
---
 arch/arm64/kernel/perf_event.c | 119 +++--
 1 file changed, 112 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index bba0b0e24de4..1864760d385d 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -288,6 +288,7 @@ static struct attribute_group armv8_pmuv3_events_attr_group 
= {
 
 PMU_FORMAT_ATTR(event, "config:0-15");
 PMU_FORMAT_ATTR(long, "config1:0");
+PMU_FORMAT_ATTR(rdpmc, "config1:1");
 
 static int sysctl_perf_user_access __read_mostly;
 
@@ -296,9 +297,15 @@ static inline bool armv8pmu_event_is_64bit(struct 
perf_event *event)
return event->attr.config1 & 0x1;
 }
 
+static inline bool armv8pmu_event_want_user_access(struct perf_event *event)
+{
+   return event->attr.config1 & 0x2;
+}
+
 static struct attribute *armv8_pmuv3_format_attrs[] = {
_attr_event.attr,
_attr_long.attr,
+   _attr_rdpmc.attr,
NULL,
 };
 
@@ -334,7 +341,7 @@ static struct attribute_group armv8_pmuv3_caps_attr_group = 
{
  */
 #defineARMV8_IDX_CYCLE_COUNTER 0
 #defineARMV8_IDX_COUNTER0  1
-
+#defineARMV8_IDX_CYCLE_COUNTER_USER32
 
 /*
  * We unconditionally enable ARMv8.5-PMU long event counter support
@@ -346,18 +353,22 @@ static bool armv8pmu_has_long_event(struct arm_pmu 
*cpu_pmu)
return (cpu_pmu->pmuver >= ID_AA64DFR0_PMUVER_8_5);
 }
 
+static inline bool armv8pmu_event_has_user_read(struct perf_event *event)
+{
+   return event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT;
+}
+
 /*
  * We must chain two programmable counters for 64 bit events,
  * except when we have allocated the 64bit cycle counter (for CPU
- * cycles event). This must be called only when the event has
- * a counter allocated.
+ * cycles event) or when user space counter access is enabled.
  */
 static inline bool armv8pmu_event_is_chained(struct perf_event *event)
 {
int idx = event->hw.idx;
struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 
-   return !WARN_ON(idx < 0) &&
+   return !armv8pmu_event_has_user_read(event) &&
   armv8pmu_event_is_64bit(event) &&
   !armv8pmu_has_long_event(cpu_pmu) &&
   (idx != ARMV8_IDX_CYCLE_COUNTER);
@@ -691,6 +702,28 @@ static inline u32 armv8pmu_getreset_flags(void)
return value;
 }
 
+static void armv8pmu_disable_user_access(void)
+{
+   write_sysreg(0, pmuserenr_el0);
+}
+
+static void armv8pmu_enable_user_access(struct arm_pmu *cpu_pmu)
+{
+   int i;
+   struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
+
+   /* Clear any unused counters to avoid leaking their contents */
+   for_each_clear_bit(i, cpuc->used_mask, cpu_pmu->num_events) {
+   if (i == ARMV8_IDX_CYCLE_COUNTER)
+   write_sysreg(0, pmccntr_el0);
+   else
+   armv8pmu_write_evcntr(i, 0);
+   }
+
+   write_sysreg(0, pmuserenr_el0);
+   write_sysreg(ARMV8_PMU_USERENR_ER | ARMV8_PMU_USERENR_CR, 
pmuserenr_el0);
+}
+

[linux-yocto][v5.10/standard/base][PATCH 11/13] arm64: perf: Add userspace counter access disable switch

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit e2012600810c9ded81f6f63a8d04781be3c300ad upstream

Like x86, some users may want to disable userspace PMU counter
altogether. Add a sysctl 'perf_user_access' file to control userspace
counter access. The default is '0' which is disabled. Writing '1'
enables access.

Note that x86 supports globally enabling user access by writing '2' to
/sys/bus/event_source/devices/cpu/rdpmc. As there's not existing
userspace support to worry about, this shouldn't be necessary for Arm.
It could be added later if the need arises.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Catalin Marinas 
Cc: linux-perf-us...@vger.kernel.org
Acked-by: Will Deacon 
Reviewed-by: Mark Rutland 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20211208201124.310740-4-r...@kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Adrian Zaharia 
---
 Documentation/admin-guide/sysctl/kernel.rst | 11 +++
 arch/arm64/kernel/perf_event.c  | 17 +
 2 files changed, 28 insertions(+)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst 
b/Documentation/admin-guide/sysctl/kernel.rst
index a4b1ebc2e70b..93a828288034 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -898,6 +898,17 @@ enabled, otherwise writing to this file will return 
``-EBUSY``.
 The default value is 8.
 
 
+perf_user_access (arm64 only)
+=
+
+Controls user space access for reading perf event counters. When set to 1,
+user space can read performance monitor counter registers directly.
+
+The default value is 0 (access disabled).
+
+See Documentation/arm64/perf.rst for more information.
+
+
 pid_max
 ===
 
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index cdb3d4549b3a..bba0b0e24de4 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -289,6 +289,8 @@ static struct attribute_group armv8_pmuv3_events_attr_group 
= {
 PMU_FORMAT_ATTR(event, "config:0-15");
 PMU_FORMAT_ATTR(long, "config1:0");
 
+static int sysctl_perf_user_access __read_mostly;
+
 static inline bool armv8pmu_event_is_64bit(struct perf_event *event)
 {
return event->attr.config1 & 0x1;
@@ -1075,6 +1077,19 @@ static int armv8pmu_probe_pmu(struct arm_pmu *cpu_pmu)
return probe.present ? 0 : -ENODEV;
 }
 
+static struct ctl_table armv8_pmu_sysctl_table[] = {
+   {
+   .procname   = "perf_user_access",
+   .data   = _perf_user_access,
+   .maxlen = sizeof(unsigned int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = SYSCTL_ZERO,
+   .extra2 = SYSCTL_ONE,
+   },
+   { }
+};
+
 static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char *name,
  int (*map_event)(struct perf_event *event),
  const struct attribute_group *events,
@@ -1107,6 +1122,8 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu, char 
*name,
cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_CAPS] = caps ?
caps : _pmuv3_caps_attr_group;
 
+   register_sysctl("kernel", armv8_pmu_sysctl_table);
+
return 0;
 }
 
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12037): 
https://lists.yoctoproject.org/g/linux-yocto/message/12037
Mute This Topic: https://lists.yoctoproject.org/mt/95765178/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 10/13] perf: Add a counter for number of user access events in context

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 82ff0c022d19c2ad69a472692bb7ee01ac07a40b upstream

On arm64, user space counter access will be controlled differently
compared to x86. On x86, access in the strictest mode is enabled for all
tasks in an MM when any event is mmap'ed. For arm64, access is
explicitly requested for an event and only enabled when the event's
context is active. This avoids hooks into the arch context switch code
and gives better control of when access is enabled.

In order to configure user space access when the PMU is enabled, it is
necessary to know if any event (currently active or not) in the current
context has user space accessed enabled. Add a counter similar to other
counters in the context to avoid walking the event list every time.

Reviewed-by: Mark Rutland 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20211208201124.310740-3-r...@kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Adrian Zaharia 
---
 include/linux/perf_event.h | 1 +
 kernel/events/core.c   | 4 
 2 files changed, 5 insertions(+)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9d2dffddeb2b..23b805d08c58 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -814,6 +814,7 @@ struct perf_event_context {
 
int nr_events;
int nr_active;
+   int nr_user;
int is_active;
int nr_stat;
int nr_freq;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 8ba155a7b59e..fcb84e22f09e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1889,6 +1889,8 @@ list_add_event(struct perf_event *event, struct 
perf_event_context *ctx)
 
list_add_rcu(>event_entry, >event_list);
ctx->nr_events++;
+   if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
+   ctx->nr_user++;
if (event->attr.inherit_stat)
ctx->nr_stat++;
 
@@ -2074,6 +2076,8 @@ list_del_event(struct perf_event *event, struct 
perf_event_context *ctx)
event->attach_state &= ~PERF_ATTACH_CONTEXT;
 
ctx->nr_events--;
+   if (event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT)
+   ctx->nr_user--;
if (event->attr.inherit_stat)
ctx->nr_stat--;
 
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12036): 
https://lists.yoctoproject.org/g/linux-yocto/message/12036
Mute This Topic: https://lists.yoctoproject.org/mt/95765177/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 09/13] x86: perf: Move RDPMC event flag to a common definition

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 369461ce8fb6c8156206c7110d7da48e9fbc41bb upstream

In preparation to enable user counter access on arm64 and to move some
of the user access handling to perf core, create a common event flag for
user counter access and convert x86 to use it.

Since the architecture specific flags start at the LSB, starting at the
MSB for common flags.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Kan Liang 
Cc: Thomas Gleixner 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: linux-perf-us...@vger.kernel.org
Reviewed-by: Mark Rutland 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Rob Herring 
Link: https://lore.kernel.org/r/20211208201124.310740-2-r...@kernel.org
Signed-off-by: Will Deacon 
Signed-off-by: Adrian Zaharia 
---
 arch/x86/events/core.c   | 10 +-
 arch/x86/events/perf_event.h |  2 +-
 include/linux/perf_event.h   |  9 +
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index b79b9f21cbb3..68d3b3461888 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -2289,14 +2289,14 @@ static int x86_pmu_event_init(struct perf_event *event)
 
if (READ_ONCE(x86_pmu.attr_rdpmc) &&
!(event->hw.flags & PERF_X86_EVENT_LARGE_PEBS))
-   event->hw.flags |= PERF_X86_EVENT_RDPMC_ALLOWED;
+   event->hw.flags |= PERF_EVENT_FLAG_USER_READ_CNT;
 
return err;
 }
 
 static void x86_pmu_event_mapped(struct perf_event *event, struct mm_struct 
*mm)
 {
-   if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED))
+   if (!(event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT))
return;
 
/*
@@ -2318,7 +2318,7 @@ static void x86_pmu_event_mapped(struct perf_event 
*event, struct mm_struct *mm)
 static void x86_pmu_event_unmapped(struct perf_event *event, struct mm_struct 
*mm)
 {
 
-   if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED))
+   if (!(event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT))
return;
 
if (atomic_dec_and_test(>context.perf_rdpmc_allowed))
@@ -2329,7 +2329,7 @@ static int x86_pmu_event_idx(struct perf_event *event)
 {
struct hw_perf_event *hwc = >hw;
 
-   if (!(hwc->flags & PERF_X86_EVENT_RDPMC_ALLOWED))
+   if (!(hwc->flags & PERF_EVENT_FLAG_USER_READ_CNT))
return 0;
 
if (is_metric_idx(hwc->idx))
@@ -2502,7 +2502,7 @@ void arch_perf_update_userpage(struct perf_event *event,
userpg->cap_user_time = 0;
userpg->cap_user_time_zero = 0;
userpg->cap_user_rdpmc =
-   !!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED);
+   !!(event->hw.flags & PERF_EVENT_FLAG_USER_READ_CNT);
userpg->pmc_width = x86_pmu.cntval_bits;
 
if (!using_native_sched_clock() || !sched_clock_stable())
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index 0c3b8fa7e532..0070f0d37575 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -72,7 +72,7 @@ static inline bool constraint_match(struct event_constraint 
*c, u64 ecode)
 #define PERF_X86_EVENT_PEBS_NA_HSW 0x0010 /* haswell style datala, unknown 
*/
 #define PERF_X86_EVENT_EXCL0x0020 /* HT exclusivity on counter */
 #define PERF_X86_EVENT_DYNAMIC 0x0040 /* dynamic alloc'd constraint */
-#define PERF_X86_EVENT_RDPMC_ALLOWED   0x0080 /* grant rdpmc permission */
+
 #define PERF_X86_EVENT_EXCL_ACCT   0x0100 /* accounted EXCL event */
 #define PERF_X86_EVENT_AUTO_RELOAD 0x0200 /* use PEBS auto-reload */
 #define PERF_X86_EVENT_LARGE_PEBS  0x0400 /* use large PEBS */
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 67a50c78232f..9d2dffddeb2b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -128,6 +128,15 @@ struct hw_perf_event_extra {
int idx;/* index in shared_regs->regs[] */
 };
 
+/**
+ * hw_perf_event::flag values
+ *
+ * PERF_EVENT_FLAG_ARCH bits are reserved for architecture-specific
+ * usage.
+ */
+#define PERF_EVENT_FLAG_ARCH   0x
+#define PERF_EVENT_FLAG_USER_READ_CNT  0x8000
+
 /**
  * struct hw_perf_event - performance event hardware details:
  */
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12035): 
https://lists.yoctoproject.org/g/linux-yocto/message/12035
Mute This Topic: https://lists.yoctoproject.org/mt/95765176/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 08/13] libperf xyarray: Add bounds checks to xyarray__entry()

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 818869489ba3c4a4ed1360e22b2f66be488ea9f5 upstream

xyarray__entry() is missing any bounds checking yet often the x and y
parameters come from external callers. Add bounds checks and an
unchecked __xyarray__entry().

Committer notes:

Make the 'x' and 'y' arguments to the new xyarray__entry() that does
bounds check to be of type 'size_t', so that we cover also the case
where 'x' and 'y' could be negative, which is needed anyway as having
them as 'int' breaks the build with:

  /home/acme/git/perf/tools/lib/perf/include/internal/xyarray.h: In function 
‘xyarray__entry’:
  /home/acme/git/perf/tools/lib/perf/include/internal/xyarray.h:28:8: error: 
comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ 
{aka ‘long unsigned int’} [-Werror=sign-compare]
 28 |  if (x >= xy->max_x || y >= xy->max_y)
|^~
  /home/acme/git/perf/tools/lib/perf/include/internal/xyarray.h:28:26: error: 
comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ 
{aka ‘long unsigned int’} [-Werror=sign-compare]
 28 |  if (x >= xy->max_x || y >= xy->max_y)
|  ^~
  cc1: all warnings being treated as errors

Signed-off-by: Rob Herring 
Suggested-by: Arnaldo Carvalho de Melo 
Suggested-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20210414195758.4078803-1-r...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/lib/perf/include/internal/xyarray.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tools/lib/perf/include/internal/xyarray.h 
b/tools/lib/perf/include/internal/xyarray.h
index 51e35d6c8ec4..f10af3da7b21 100644
--- a/tools/lib/perf/include/internal/xyarray.h
+++ b/tools/lib/perf/include/internal/xyarray.h
@@ -18,11 +18,18 @@ struct xyarray *xyarray__new(int xlen, int ylen, size_t 
entry_size);
 void xyarray__delete(struct xyarray *xy);
 void xyarray__reset(struct xyarray *xy);
 
-static inline void *xyarray__entry(struct xyarray *xy, int x, int y)
+static inline void *__xyarray__entry(struct xyarray *xy, int x, int y)
 {
return >contents[x * xy->row_size + y * xy->entry_size];
 }
 
+static inline void *xyarray__entry(struct xyarray *xy, size_t x, size_t y)
+{
+   if (x >= xy->max_x || y >= xy->max_y)
+   return NULL;
+   return __xyarray__entry(xy, x, y);
+}
+
 static inline int xyarray__max_y(struct xyarray *xy)
 {
return xy->max_y;
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12034): 
https://lists.yoctoproject.org/g/linux-yocto/message/12034
Mute This Topic: https://lists.yoctoproject.org/mt/95765175/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 07/13] libperf: Add support for user space counter access

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 47d01e7bb9591077a59a1ecec11c6ce570de upstream

x86 and arm64 can both support direct access of event counters in
userspace. The access sequence is less than trivial and currently exists
in perf test code (tools/perf/arch/x86/tests/rdpmc.c) with copies in
projects such as PAPI and libpfm4.

In order to support userspace access, an event must be mmapped first
with perf_evsel__mmap(). Then subsequent calls to perf_evsel__read()
will use the fast path (assuming the arch supports it).

Committer notes:

Added a '__maybe_unused' attribute to the read_perf_counter() argument
to fix the build on arches other than x86_64 and arm.

Committer testing:

  Building and running the libperf tests in verbose mode (V=1) now shows
  those "loop = N, count = N" extra lines, testing user space counter
  access.

  # make V=1 -C tools/lib/perf tests
  make: Entering directory '/home/acme/git/perf/tools/lib/perf'
  make -f /home/acme/git/perf/tools/build/Makefile.build dir=. obj=libperf
  make -C /home/acme/git/perf/tools/lib/api/ O= libapi.a
  make -f /home/acme/git/perf/tools/build/Makefile.build dir=./fd obj=libapi
  make -f /home/acme/git/perf/tools/build/Makefile.build dir=./fs obj=libapi
  make -C tests
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall -o 
test-cpumap-a test-cpumap.c ../libperf.a 
/home/acme/git/perf/tools/lib/api/libapi.a
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall -o 
test-threadmap-a test-threadmap.c ../libperf.a 
/home/acme/git/perf/tools/lib/api/libapi.a
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall -o 
test-evlist-a test-evlist.c ../libperf.a 
/home/acme/git/perf/tools/lib/api/libapi.a
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall -o 
test-evsel-a test-evsel.c ../libperf.a 
/home/acme/git/perf/tools/lib/api/libapi.a
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall 
-L.. -o test-cpumap-so test-cpumap.c /home/acme/git/perf/tools/lib/api/libapi.a 
-lperf
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall 
-L.. -o test-threadmap-so test-threadmap.c 
/home/acme/git/perf/tools/lib/api/libapi.a -lperf
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall 
-L.. -o test-evlist-so test-evlist.c /home/acme/git/perf/tools/lib/api/libapi.a 
-lperf
  gcc -I/home/acme/git/perf/tools/lib/perf/include 
-I/home/acme/git/perf/tools/include -I/home/acme/git/perf/tools/lib -g -Wall 
-L.. -o test-evsel-so test-evsel.c /home/acme/git/perf/tools/lib/api/libapi.a 
-lperf
  make -C tests run
  running static:
  - running test-cpumap.c...OK
  - running test-threadmap.c...OK
  - running test-evlist.c...OK
  - running test-evsel.c...
loop = 65536, count = 333926
loop = 131072, count = 655781
loop = 262144, count = 1311141
loop = 524288, count = 2630126
loop = 1048576, count = 5256955
loop = 65536, count = 524594
loop = 131072, count = 1058916
loop = 262144, count = 2097458
loop = 524288, count = 4205429
loop = 1048576, count = 8406606
  OK
  running dynamic:
  - running test-cpumap.c...OK
  - running test-threadmap.c...OK
  - running test-evlist.c...OK
  - running test-evsel.c...
loop = 65536, count = 328102
loop = 131072, count = 655782
loop = 262144, count = 1317494
loop = 524288, count = 2627851
loop = 1048576, count = 5255187
loop = 65536, count = 524601
loop = 131072, count = 1048923
loop = 262144, count = 2107917
loop = 524288, count = 4194606
loop = 1048576, count = 8409322
  OK
  make: Leaving directory '/home/acme/git/perf/tools/lib/perf'
  #

Signed-off-by: Rob Herring 
Acked-by: Jiri Olsa 
Acked-by: Namhyung Kim 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Catalin Marinas 
Cc: Itaru Kitayama 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: http://lore.kernel.org/lkml/20210414155412.3697605-4-r...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/lib/perf/evsel.c |  4 ++
 tools/lib/perf/include/internal/mmap.h |  3 +
 tools/lib/perf/mmap.c  | 88 ++
 tools/lib/perf/tests/test-evsel.c  | 66 +++
 4 files changed, 161 insertions(+)

diff --git a/tools/lib/perf/evsel.c b/tools/lib/perf/evsel.c
index cd203998e875..bd8c2f19ef74 100644
--- a/tools/lib/perf/evsel.c
+++ b/tools/lib/perf/evsel.c
@@ -267,6 +267,10 @@ int perf_evsel__read(struct perf_evsel

[linux-yocto][v5.10/standard/base][PATCH 04/13] tools include: Add an initial math64.h

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 2fc83c2cd77703cfcfc1ffaa092614fb1f837292 upstream

Add an initial math64.h similar to linux/math64.h with functions
mul_u64_u64_div64() and mul_u64_u32_shr(). This isn't a direct copy of
include/linux/math64.h as that doesn't define mul_u64_u64_div64().

Implementation was written by Peter Zilkstra based on linux/math64.h
and div64.h[1]. The original implementation was not optimal on arm64 as
__int128 division is not optimal with a call out to __udivti3, so I
dropped the __int128 variant of mul_u64_u64_div64().

[1] 
https://lore.kernel.org/lkml/20200322101848.gf2...@worktop.programming.kicks-ass.net/

Signed-off-by: Rob Herring 
Acked-by: Jiri Olsa 
Acked-by: Namhyung Kim 
Cc: Catalin Marinas 
Cc: Itaru Kitayama 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: http://lore.kernel.org/lkml/20210414155412.3697605-2-r...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/include/linux/math64.h | 75 
 1 file changed, 75 insertions(+)
 create mode 100644 tools/include/linux/math64.h

diff --git a/tools/include/linux/math64.h b/tools/include/linux/math64.h
new file mode 100644
index ..4ad45d5943dc
--- /dev/null
+++ b/tools/include/linux/math64.h
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_MATH64_H
+#define _LINUX_MATH64_H
+
+#include 
+
+#ifdef __x86_64__
+static inline u64 mul_u64_u64_div64(u64 a, u64 b, u64 c)
+{
+   u64 q;
+
+   asm ("mulq %2; divq %3" : "=a" (q)
+   : "a" (a), "rm" (b), "rm" (c)
+   : "rdx");
+
+   return q;
+}
+#define mul_u64_u64_div64 mul_u64_u64_div64
+#endif
+
+#ifdef __SIZEOF_INT128__
+static inline u64 mul_u64_u32_shr(u64 a, u32 b, unsigned int shift)
+{
+   return (u64)(((unsigned __int128)a * b) >> shift);
+}
+
+#else
+
+#ifdef __i386__
+static inline u64 mul_u32_u32(u32 a, u32 b)
+{
+   u32 high, low;
+
+   asm ("mull %[b]" : "=a" (low), "=d" (high)
+: [a] "a" (a), [b] "rm" (b) );
+
+   return low | ((u64)high) << 32;
+}
+#else
+static inline u64 mul_u32_u32(u32 a, u32 b)
+{
+   return (u64)a * b;
+}
+#endif
+
+static inline u64 mul_u64_u32_shr(u64 a, u32 b, unsigned int shift)
+{
+   u32 ah, al;
+   u64 ret;
+
+   al = a;
+   ah = a >> 32;
+
+   ret = mul_u32_u32(al, b) >> shift;
+   if (ah)
+   ret += mul_u32_u32(ah, b) << (32 - shift);
+
+   return ret;
+}
+
+#endif /* __SIZEOF_INT128__ */
+
+#ifndef mul_u64_u64_div64
+static inline u64 mul_u64_u64_div64(u64 a, u64 b, u64 c)
+{
+   u64 quot, rem;
+
+   quot = a / c;
+   rem = a % c;
+
+   return quot * b + (rem * b) / c;
+}
+#endif
+
+#endif /* _LINUX_MATH64_H */
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12026): 
https://lists.yoctoproject.org/g/linux-yocto/message/12026
Mute This Topic: https://lists.yoctoproject.org/mt/95765164/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 03/13] perf record: Improve 'Workload failed' message printing events + what was exec'ed

2022-12-19 Thread Adrian Zaharia 
From: Arnaldo Carvalho de Melo 

commit 3535a6967c0d590381c16d6676c6fdfa60f4d733 upstream

Before:

  # perf record -a cycles,instructions,cache-misses
  Workload failed: No such file or directory
  #

After:

  # perf record -a cycles,instructions,cache-misses
  Failed to collect 'cycles' for the 'cycles,instructions,cache-misses' 
workload: No such file or directory
  #

Helps disambiguating other error scenarios:

  # perf record -a -e cycles,instructions,cache-misses bla
  Failed to collect 'cycles,instructions,cache-misses' for the 'bla' workload: 
No such file or directory
  # perf record -a cycles,instructions,cache-misses sleep 1
  Failed to collect 'cycles' for the 'cycles,instructions,cache-misses' 
workload: No such file or directory
  #

When all goes well we're back to the usual:

  # perf record -a -e cycles,instructions,cache-misses sleep 1
  [ perf record: Woken up 3 times to write data ]
  [ perf record: Captured and wrote 3.151 MB perf.data (21242 samples) ]
  #

Acked-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lore.kernel.org/lkml/20210414131628.2064862-3-a...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/perf/builtin-record.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index e5c938d538ee..a28db97b3b8f 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1977,9 +1977,13 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
record__auxtrace_snapshot_exit(rec);
 
if (forks && workload_exec_errno) {
-   char msg[STRERR_BUFSIZE];
+   char msg[STRERR_BUFSIZE], strevsels[2048];
const char *emsg = str_error_r(workload_exec_errno, msg, 
sizeof(msg));
-   pr_err("Workload failed: %s\n", emsg);
+
+   evlist__scnprintf_evsels(rec->evlist, sizeof(strevsels), 
strevsels);
+
+   pr_err("Failed to collect '%s' for the '%s' workload: %s\n",
+   strevsels, argv[0], emsg);
err = -1;
goto out_child;
}
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12031): 
https://lists.yoctoproject.org/g/linux-yocto/message/12031
Mute This Topic: https://lists.yoctoproject.org/mt/95765170/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 06/13] libperf tests: Add support for verbose printing

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit d3003d9e686890a1e9f0cc7c08aa02ef2953b1f0 upstream

Add __T_VERBOSE() so tests can add verbose output. The verbose output is
enabled with the '-v' command line option. Running 'make tests V=1' will
enable the '-v' option when running the tests.

It'll be used in the next patch, for a user space counter access test.

Signed-off-by: Rob Herring 
Acked-by: Jiri Olsa 
Acked-by: Namhyung Kim 
Cc: Catalin Marinas 
Cc: Itaru Kitayama 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: http://lore.kernel.org/lkml/20210414155412.3697605-3-r...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/lib/perf/include/internal/tests.h | 32 +
 tools/lib/perf/tests/Makefile   |  6 +++--
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/tools/lib/perf/include/internal/tests.h 
b/tools/lib/perf/include/internal/tests.h
index 2093e8868a67..29425c2dabe1 100644
--- a/tools/lib/perf/include/internal/tests.h
+++ b/tools/lib/perf/include/internal/tests.h
@@ -3,11 +3,32 @@
 #define __LIBPERF_INTERNAL_TESTS_H
 
 #include 
+#include 
 
 int tests_failed;
+int tests_verbose;
+
+static inline int get_verbose(char **argv, int argc)
+{
+   int c;
+   int verbose = 0;
+
+   while ((c = getopt(argc, argv, "v")) != -1) {
+   switch (c)
+   {
+   case 'v':
+   verbose = 1;
+   break;
+   default:
+   break;
+   }
+   }
+   return verbose;
+}
 
 #define __T_START  \
 do {   \
+   tests_verbose = get_verbose(argv, argc);\
fprintf(stdout, "- running %s...", __FILE__);   \
fflush(NULL);   \
tests_failed = 0;   \
@@ -30,4 +51,15 @@ do {
}   
 \
 } while (0)
 
+#define __T_VERBOSE(...)   \
+do {   \
+   if (tests_verbose) {\
+   if (tests_verbose == 1) {   \
+   fputc('\n', stderr);\
+   tests_verbose++;\
+   }   \
+   fprintf(stderr, ##__VA_ARGS__); \
+   }   \
+} while (0)
+
 #endif /* __LIBPERF_INTERNAL_TESTS_H */
diff --git a/tools/lib/perf/tests/Makefile b/tools/lib/perf/tests/Makefile
index 96841775feaf..b536cc9a26dd 100644
--- a/tools/lib/perf/tests/Makefile
+++ b/tools/lib/perf/tests/Makefile
@@ -5,6 +5,8 @@ TESTS = test-cpumap test-threadmap test-evlist test-evsel
 TESTS_SO := $(addsuffix -so,$(TESTS))
 TESTS_A  := $(addsuffix -a,$(TESTS))
 
+TEST_ARGS := $(if $(V),-v)
+
 # Set compile option CFLAGS
 ifdef EXTRA_CFLAGS
   CFLAGS := $(EXTRA_CFLAGS)
@@ -28,9 +30,9 @@ all: $(TESTS_A) $(TESTS_SO)
 
 run:
@echo "running static:"
-   @for i in $(TESTS_A); do ./$$i; done
+   @for i in $(TESTS_A); do ./$$i $(TEST_ARGS); done
@echo "running dynamic:"
-   @for i in $(TESTS_SO); do LD_LIBRARY_PATH=../ ./$$i; done
+   @for i in $(TESTS_SO); do LD_LIBRARY_PATH=../ ./$$i $(TEST_ARGS); done
 
 clean:
$(call QUIET_CLEAN, tests)$(RM) $(TESTS_A) $(TESTS_SO)
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12032): 
https://lists.yoctoproject.org/g/linux-yocto/message/12032
Mute This Topic: https://lists.yoctoproject.org/mt/95765172/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][PATCH 05/13] libperf: Add evsel mmap support

2022-12-19 Thread Adrian Zaharia 
From: Rob Herring 

commit 6cd70754f262e593febc06a02d7ea637c927ea42 upstream

In order to support usersapce access, an event must be mmapped. While
there's already mmap support for evlist, the usecase is a bit different
than the self monitoring with userspace access. So let's add new
perf_evsel__mmap()/perf_evsel_munmap() functions to mmap/munmap an
evsel. This allows implementing userspace access as a fastpath for
perf_evsel__read().

The mmapped address is returned by perf_evsel__mmap_base() which
primarily for users/tests to check if userspace access is enabled.

Signed-off-by: Rob Herring 
Acked-by: Jiri Olsa 
Acked-by: Namhyung Kim 
Cc: Catalin Marinas 
Cc: Itaru Kitayama 
Cc: Mark Rutland 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Link: http://lore.kernel.org/lkml/20210414155412.3697605-2-r...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/lib/perf/Documentation/libperf.txt |  3 +
 tools/lib/perf/evsel.c   | 76 
 tools/lib/perf/include/internal/evsel.h  |  1 +
 tools/lib/perf/include/perf/evsel.h  |  3 +
 tools/lib/perf/libperf.map   |  3 +
 5 files changed, 86 insertions(+)

diff --git a/tools/lib/perf/Documentation/libperf.txt 
b/tools/lib/perf/Documentation/libperf.txt
index 0c74c30ed23a..63ae5e0195ce 100644
--- a/tools/lib/perf/Documentation/libperf.txt
+++ b/tools/lib/perf/Documentation/libperf.txt
@@ -136,6 +136,9 @@ SYNOPSIS
struct perf_thread_map *threads);
   void perf_evsel__close(struct perf_evsel *evsel);
   void perf_evsel__close_cpu(struct perf_evsel *evsel, int cpu);
+  int perf_evsel__mmap(struct perf_evsel *evsel, int pages);
+  void perf_evsel__munmap(struct perf_evsel *evsel);
+  void *perf_evsel__mmap_base(struct perf_evsel *evsel, int cpu, int thread);
   int perf_evsel__read(struct perf_evsel *evsel, int cpu, int thread,
struct perf_counts_values *count);
   int perf_evsel__enable(struct perf_evsel *evsel);
diff --git a/tools/lib/perf/evsel.c b/tools/lib/perf/evsel.c
index 4dc06289f4c7..cd203998e875 100644
--- a/tools/lib/perf/evsel.c
+++ b/tools/lib/perf/evsel.c
@@ -11,10 +11,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 void perf_evsel__init(struct perf_evsel *evsel, struct perf_event_attr *attr)
 {
@@ -38,6 +40,7 @@ void perf_evsel__delete(struct perf_evsel *evsel)
 }
 
 #define FD(e, x, y) (*(int *) xyarray__entry(e->fd, x, y))
+#define MMAP(e, x, y) (e->mmap ? ((struct perf_mmap *) xyarray__entry(e->mmap, 
x, y)) : NULL)
 
 int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads)
 {
@@ -55,6 +58,13 @@ int perf_evsel__alloc_fd(struct perf_evsel *evsel, int 
ncpus, int nthreads)
return evsel->fd != NULL ? 0 : -ENOMEM;
 }
 
+static int perf_evsel__alloc_mmap(struct perf_evsel *evsel, int ncpus, int 
nthreads)
+{
+   evsel->mmap = xyarray__new(ncpus, nthreads, sizeof(struct perf_mmap));
+
+   return evsel->mmap != NULL ? 0 : -ENOMEM;
+}
+
 static int
 sys_perf_event_open(struct perf_event_attr *attr,
pid_t pid, int cpu, int group_fd,
@@ -156,6 +166,72 @@ void perf_evsel__close_cpu(struct perf_evsel *evsel, int 
cpu)
perf_evsel__close_fd_cpu(evsel, cpu);
 }
 
+void perf_evsel__munmap(struct perf_evsel *evsel)
+{
+   int cpu, thread;
+
+   if (evsel->fd == NULL || evsel->mmap == NULL)
+   return;
+
+   for (cpu = 0; cpu < xyarray__max_x(evsel->fd); cpu++) {
+   for (thread = 0; thread < xyarray__max_y(evsel->fd); thread++) {
+   int fd = FD(evsel, cpu, thread);
+   struct perf_mmap *map = MMAP(evsel, cpu, thread);
+
+   if (fd < 0)
+   continue;
+
+   perf_mmap__munmap(map);
+   }
+   }
+
+   xyarray__delete(evsel->mmap);
+   evsel->mmap = NULL;
+}
+
+int perf_evsel__mmap(struct perf_evsel *evsel, int pages)
+{
+   int ret, cpu, thread;
+   struct perf_mmap_param mp = {
+   .prot = PROT_READ | PROT_WRITE,
+   .mask = (pages * page_size) - 1,
+   };
+
+   if (evsel->fd == NULL || evsel->mmap)
+   return -EINVAL;
+
+   if (perf_evsel__alloc_mmap(evsel, xyarray__max_x(evsel->fd), 
xyarray__max_y(evsel->fd)) < 0)
+   return -ENOMEM;
+
+   for (cpu = 0; cpu < xyarray__max_x(evsel->fd); cpu++) {
+   for (thread = 0; thread < xyarray__max_y(evsel->fd); thread++) {
+   int fd = FD(evsel, cpu, thread);
+   struct perf_mmap *map = MMAP(evsel, cpu, thread);
+
+   if (fd < 0)
+   continue;
+
+   perf_mmap__init(map, NULL, false, NULL);
+
+   ret = perf_mmap__mmap(map, , fd, cpu);
+   if (ret) {
+

[linux-yocto][v5.10/standard/base][PATCH 01/13] perf annotate: Fix sample events lost in stdio mode

2022-12-19 Thread Adrian Zaharia 
From: Yang Jihong 

commit 5676dba708bbb1fc94a9d3b2e9c114db9e4c6699 upstream

In hist__find_annotations(), since different 'struct hist_entry' entries
may point to same symbol, we free notes->src to signal already processed
this symbol in stdio mode; when annotate, entry will skipped if
notes->src is NULL to avoid repeated output.

However, there is a problem, for example, run the following command:

 # perf record -e branch-misses -e branch-instructions -a sleep 1

perf.data file contains different types of sample event.

If the same IP sample event exists in branch-misses and branch-instructions,
this event uses the same symbol. When annotate branch-misses events, notes->src
corresponding to this event is set to null, as a result, when annotate
branch-instructions events, this event is skipped and no annotate is output.

Solution of this patch is to remove zfree in hists__find_annotations and
change sort order to "dso,symbol" to avoid duplicate output when different
processes correspond to the same symbol.

Signed-off-by: Yang Jihong 
Acked-by: Namhyung Kim 
Cc: Alexander Shishkin 
Cc: Gustavo A. R. Silva 
Cc: Jin Yao 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Martin Liška 
Cc: Peter Zijlstra 
Cc: zhangjinh...@huawei.com
Link: http://lore.kernel.org/lkml/20210319123527.173883-1-yangjiho...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/perf/builtin-annotate.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 4940d10074c3..6ed22143c094 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct hists *hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
-   /*
-* Since we have a hist_entry per IP for the same
-* symbol, free he->ms.sym->src to signal we already
-* processed this symbol.
-*/
-   zfree(>src->cycles_hist);
-   zfree(>src);
}
}
 }
@@ -619,14 +612,22 @@ int cmd_annotate(int argc, const char **argv)
 
setup_browser(true);
 
-   if ((use_browser == 1 || annotate.use_stdio2) && annotate.has_br_stack) 
{
+   /*
+* Events of different processes may correspond to the same
+* symbol, we do not care about the processes in annotate,
+* set sort order to avoid repeated output.
+*/
+   sort_order = "dso,symbol";
+
+   /*
+* Set SORT_MODE__BRANCH so that annotate display IPC/Cycle
+* if branch info is in perf data in TUI mode.
+*/
+   if ((use_browser == 1 || annotate.use_stdio2) && annotate.has_br_stack)
sort__mode = SORT_MODE__BRANCH;
-   if (setup_sorting(annotate.session->evlist) < 0)
-   usage_with_options(annotate_usage, options);
-   } else {
-   if (setup_sorting(NULL) < 0)
-   usage_with_options(annotate_usage, options);
-   }
+
+   if (setup_sorting(NULL) < 0)
+   usage_with_options(annotate_usage, options);
 
ret = __cmd_annotate();
 
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12029): 
https://lists.yoctoproject.org/g/linux-yocto/message/12029
Mute This Topic: https://lists.yoctoproject.org/mt/95765168/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base][linux-yocto][v5.10/standard/base][PATCH 02/13] perf evlist: Add a method to return the list of evsels as a string

2022-12-19 Thread Adrian Zaharia 
From: Arnaldo Carvalho de Melo 

commit 9865ea8ab31f2e56be59125099ee251ce573f293 upstream

Add a 'scnprintf' method to obtain the list of evsels in a evlist as a
string, excluding the "dummy" event used for things like receiving
metadata events (PERF_RECORD_FORK, MMAP, etc) when synthesizing
preexisting threads.

Will be used to improve the error message for workload failure in 'perf
record.

Acked-by: Ian Rogers 
Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lore.kernel.org/lkml/20210414131628.2064862-2-a...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Adrian Zaharia 
---
 tools/perf/util/evlist.c | 19 +++
 tools/perf/util/evlist.h |  2 ++
 2 files changed, 21 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 98ae432470cd..9ffeeca4724f 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1988,3 +1988,22 @@ struct evsel *evlist__find_evsel(struct evlist *evlist, 
int idx)
}
return NULL;
 }
+
+int evlist__scnprintf_evsels(struct evlist *evlist, size_t size, char *bf)
+{
+   struct evsel *evsel;
+   int printed = 0;
+
+   evlist__for_each_entry(evlist, evsel) {
+   if (evsel__is_dummy_event(evsel))
+   continue;
+   if (size > (strlen(evsel__name(evsel)) + (printed ? 2 : 1))) {
+   printed += scnprintf(bf + printed, size - printed, 
"%s%s", printed ? "," : "", evsel__name(evsel));
+   } else {
+   printed += scnprintf(bf + printed, size - printed, 
"%s...", printed ? "," : "");
+   break;
+   }
+   }
+
+   return printed;
+}
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 9298fce53ea3..84f745d4ef72 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -391,4 +391,6 @@ int evlist__ctlfd_ack(struct evlist *evlist);
 #define EVLIST_DISABLED_MSG "Events disabled\n"
 
 struct evsel *evlist__find_evsel(struct evlist *evlist, int idx);
+
+int evlist__scnprintf_evsels(struct evlist *evlist, size_t size, char *bf);
 #endif /* __PERF_EVLIST_H */
-- 
2.36.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12030): 
https://lists.yoctoproject.org/g/linux-yocto/message/12030
Mute This Topic: https://lists.yoctoproject.org/mt/95765169/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][v5.10/standard/base] enable PMU counter userspace access for perf event

2022-12-19 Thread Adrian Zaharia 
Hi Bruce,

Please help to merge this patchset into linux-yocto repo.

repo:
linux-yocto
branch:
v5.10/standard/base

Thanks,
Adrian

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12028): 
https://lists.yoctoproject.org/g/linux-yocto/message/12028
Mute This Topic: https://lists.yoctoproject.org/mt/95765167/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Issue with accessing network from a recipe

2022-12-19 Thread Gärding Antti via lists . yoctoproject . org 
Hi,

I am having an issue with a recipe whose do_configure requires network 
connections and I wonder if this issue could be related to Yocto so that this 
list would be the correct place to ask for ideas.

The problem appears when trying to build dotnet-hello-world which comes with 
meta-dotnet (https://github.com/jeremy-prater/meta-dotnet). I am not the only 
one having this issue, but many people, including the layer's author, also 
report having no problems. Googling gives a lot of suggestions, but as this is 
related to .NET, all of them are related to Windows / Visual Studio environment 
and I don't know how to apply them using Yocto.

In short, do_configure for dotnet-hello-world invokes the .NET SDK's tool 
dotnet as a host tool to fetch what is needed to build and run the program. As 
a part of that, it uses NuGet, the package manager for .NET, which says "error 
NU1301: Unable to load the service index for source 
https://api.nuget.org/v3/index.json;.

If I modify the recipe so that it tries to curl that file, I get "Could not 
resolve host: api.nuget.org". If I do the same but use numeric address, I get 
"Couldn't connect to server".

If I run the commands in the recipe manually in the same environment I use for 
Yocto builds, using .NET SDK I have installed manually, they work.

My build environment is Ubuntu 20.04 run inside a Docker container.


Best regards,
Antti Gärding

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58831): https://lists.yoctoproject.org/g/yocto/message/58831
Mute This Topic: https://lists.yoctoproject.org/mt/95764092/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-