uses spinlocks to serialize
enabling/disabling link devices.
Fixes: a06ae8609b3d ("coresight: add CoreSight core layer framework")
Signed-off-by: Yabin Cui
---
v3 -> v4: moved lock from coresight_enable/disable_link() to
enable/disable functions of each link device.
I also removed
> Can I add your Tested-by ?
Yes. I just sent a tested-by reply, but not sure if it works. I am not very
familar
with linux kernel review system.
Tested-by: Yabin Cui
Thanks for fixing this problem. I didn't realize it because I usually use a
buffer size >= the default ETR buffer size, which is harder to reproduce the
problem.
The patches LGTM, maybe you also want to fix the problem commented by Leo Yan.
I tested the patches by recording etm data with a buffer s
instead of etr_perf_buffer.
Also move the code setting and clearing perf_buf to more suitable
places.
Fixes: 3147da92a8a8 ("coresight: tmc-etr: Allocate and free ETR memory buffers
for CPU-wide scenarios")
Signed-off-by: Yabin Cui
---
v2 -> v3:
moved place of setting drvdata->p
> Did you actually see the check fail or is this a theoretical thing?
> I'm really perplex here has I have tested this scenario many times
> without issues.
>
I have seen this warning in dmesg output, that's how I find the problem.
> In CPU wide scenarios each perf event (one per CPU) is associate
> The patch isn't difficult to do but does go deeper in each link
> drivers (ETF, funnel, replicator). Let me know if you are not
> comfortable with the idea and I will see what I can do on my side.
I am comfortable with the idea. I chose to add lock in coresight_enable_link()
just because it
is
ess data than the reality.
So change to only copy the latest data fitting the available space in
perf aux buffer.
Signed-off-by: Yabin Cui
---
v1 -> v2: copy the latest data instead of the earliest data.
---
.../hwtracing/coresight/coresight-tmc-etr.c| 18 +++---
1 file
adds a spinlock to serialize
enabling/disabling a link device.
Fixes: a06ae8609b3d ("coresight: add CoreSight core layer framework")
Signed-off-by: Yabin Cui
---
v2 -> v3: extend lock range to protect csdev->enable for link devices.
Add fixes tag.
---
driver
instead of etr_perf_buffer.
Fixes: 3147da92a8a8 ("coresight: tmc-etr: Allocate and free ETR memory buffers
for CPU-wide scenarios")
Signed-off-by: Yabin Cui
---
v1 -> v2: rename perf_data to perf_buf. Add fixes tag.
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 6 +++---
driv
>You may also want to protect the refcount checks below with the same lock, just
>to be consistent.
Good suggestion! I didn't protect it because I found other places using refcnt.
But it turns out they are not link devices.
I have uploaded patch v2.
From: Yabin Cui
Subject: Re: [PATCH] coresight: Serialize enabling/disabling a link device.
>You may also want to protect the refcount checks below with the same lock, just
>to be consistent.
Good suggestion! I didn't protect it because I found other places using refcnt.
But it tur
adds a spinlock to serialize
enabling/disabling a link device.
Signed-off-by: Yabin Cui
---
v1 -> v2: extend lock range to protect read of refcnt in
coresight_disable_link().
---
drivers/hwtracing/coresight/coresight.c | 12 +++-
include/linux/coresight.h | 3 +++
instead of etr_perf_buffer.
Signed-off-by: Yabin Cui
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 17006705287a
I totally agree that checking etr_buf is a better way.
It solves my problem.
I will upload a new patch soon.
When tracing etm data of multiple threads on multiple cpus through
perf interface, each cpu has a unique etr_perf_buffer while sharing
the same etr device. There is no guarantee that the last cpu starts
etm tracing also stops last. So the perf_data check is no longer valid.
Signed-off-by: Yabin
adds a spinlock to serialize
enabling/disabling a link device.
Signed-off-by: Yabin Cui
---
drivers/hwtracing/coresight/coresight.c | 8
include/linux/coresight.h | 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/hwtracing/coresight/coresight.c
b/dr
ess data than the reality.
Signed-off-by: Yabin Cui
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c
b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 1700
Commit-ID: 1b038c6e05ff70a1e66e3e571c2e6106bdb75f53
Gitweb: https://git.kernel.org/tip/1b038c6e05ff70a1e66e3e571c2e6106bdb75f53
Author: Yabin Cui
AuthorDate: Fri, 17 May 2019 13:52:31 +0200
Committer: Ingo Molnar
CommitDate: Fri, 24 May 2019 09:00:10 +0200
perf/ring_buffer: Fix
> > - local_inc(&rb->nest);
> > + rb->nest++;
> > + barrier();
> Urgh; almost but not quite. You just lost the 'volatile' qualifier and
> now the compiler can mess things up for you.
I thought the barriers added could force the compiler to forget what it knows
about rb->nest, and do the wri
ected behaviors.
This can be fixed by moving dec(&rb->nest) to after updating data_head,
which prevents the IRQ/NMI above from updating data_head.
Signed-off-by: Yabin Cui
---
v1 -> v2: change rb->nest from local_t to unsigned int, and add barriers.
---
kernel/events/internal.h|
>Indeed, good catch! Have you observed this, or is this patch due to code
inspection?
I observed this. I was using perf_event_open instead of linux tools perf
to monitor a process continuously forking new processes, generating a lot
of mmap records. And a sample record happens while generating a m
ected behaviors.
This can be fixed by moving dec(&rb->nest) to after updating data_head,
which prevents the IRQ/NMI above from updating data_head.
Signed-off-by: Yabin Cui
---
kernel/events/ring_buffer.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/
Commit-ID: 02e184476eff848273826c1d6617bb37e5bcc7ad
Gitweb: https://git.kernel.org/tip/02e184476eff848273826c1d6617bb37e5bcc7ad
Author: Yabin Cui
AuthorDate: Thu, 23 Aug 2018 15:59:35 -0700
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 14:01:46 +0200
perf/core: Force USER_DS
(KERNEL_DS). And it is explicitly forbidden by hardware on ARM64
when both CONFIG_ARM64_UAO and CONFIG_ARM64_PAN are used.
So fix this by forcing USER_DS when recording user stack data.
Signed-off-by: Yabin Cui
---
kernel/events/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel
25 matches
Mail list logo
