From: sashiko-bot@kernel.org
To: "Ravi Jonnalagadda" <ravis.opensrc@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH v4 3/9] mm/damon: add perf-event overflow handler feeding the report ring
Date: Mon, 05 Oct 2026 08:58:40 +0000 [thread overview]
Message-ID: <20261005085841.66DAB1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261005-damon-perf-rfc-v3-send-2026-10-03-v4-3-b03452e137f3@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] mm: damon-perf drops valid memory accesses at physical or virtual page 0
- [Medium] mm: damon-perf setup silently succeeds even if PMU event creation fails on all CPUs
--
commit 8f5b12d04ef4011765be3438258e3b2a5a8d8eb7
Author: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
mm/damon: add perf-event overflow handler feeding the report ring
This patch adds a PMU-agnostic perf-event overflow handler for DAMON. It
routes physical and virtual address access samples from a perf-event into
a per-context report ring.
> diff --git a/mm/damon/perf_source.c b/mm/damon/perf_source.c
> new file mode 100644
> index 0000000000000..65bbfe850e708
> --- /dev/null
> +++ b/mm/damon/perf_source.c
[ ... ]
> +static void damon_perf_overflow(struct perf_event *perf_event,
> + struct perf_sample_data *data,
> + struct pt_regs *regs)
> +{
[ ... ]
> + if (data->sample_flags & PERF_SAMPLE_PHYS_ADDR)
> + report.paddr = data->phys_addr & PAGE_MASK;
> + if (data->sample_flags & PERF_SAMPLE_ADDR)
> + report.vaddr = data->addr & PAGE_MASK;
> +
> + if (!report.paddr && !report.vaddr)
> + return;
[Severity: High]
Does this check mistakenly drop legitimate accesses to physical or virtual
page 0? If only PERF_SAMPLE_PHYS_ADDR is requested, accesses to the first
physical page will have report.paddr == 0 and report.vaddr == 0, causing
this logic to silently discard valid memory accesses.
> +
> + if (data->sample_flags & PERF_SAMPLE_DATA_SRC)
[ ... ]
> +static int damon_perf_cpu_online(unsigned int cpu, struct hlist_node *node)
> +{
[ ... ]
> + perf_event = perf_event_create_kernel_counter(&attr, cpu, NULL,
> + damon_perf_overflow,
> + event);
> + if (IS_ERR(perf_event)) {
> + pr_warn_ratelimited("damon-perf: cpu %u event create failed: %ld\n",
> + cpu, PTR_ERR(perf_event));
> + return 0;
> + }
> + per_cpu(*perf->event, cpu) = perf_event;
> +
> + perf_event_enable(perf_event);
> + return 0;
> +}
[ ... ]
> +int damon_perf_probe_setup(struct damon_ctx *ctx,
> + struct damon_probe *probe,
> + struct damon_perf_probe_event *event)
> +{
[ ... ]
> + err = cpuhp_state_add_instance(damon_perf_cpuhp_state,
> + &event->hlist_node);
> + if (err)
> + goto free_event;
> +
> + return 0;
[Severity: Medium]
Could this setup silently succeed even if PMU event creation fails on all
CPUs?
In damon_perf_cpu_online(), when perf_event_create_kernel_counter() returns
an error, it rightly returns 0 to avoid breaking CPU hotplug. However,
damon_perf_probe_setup() relies on the return value of
cpuhp_state_add_instance().
If a user provides an invalid PMU configuration, event creation will fail
everywhere, but the setup will succeed without error, leaving DAMON running
without any armed counters. Should there be a check to verify that at least
one counter was successfully created?
> +
> +free_event:
> + free_percpu(perf->event);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261005-damon-perf-rfc-v3-send-2026-10-03-v4-0-b03452e137f3@gmail.com?part=3
next prev parent reply other threads:[~2026-10-05 8:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 8:46 [RFC PATCH v4 0/9] mm/damon: hardware-sampled access reports Ravi Jonnalagadda
2026-10-05 8:46 ` [RFC PATCH v4 1/9] mm/damon/paddr: remove page_fault access check primitive Ravi Jonnalagadda
2026-10-05 8:53 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 2/9] mm/damon/core: replace the access report buffer with per-context rings Ravi Jonnalagadda
2026-10-05 8:54 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 3/9] mm/damon: add perf-event overflow handler feeding the report ring Ravi Jonnalagadda
2026-10-05 8:58 ` sashiko-bot [this message]
2026-10-05 8:46 ` [RFC PATCH v4 4/9] mm/damon/ops-common: use probe-weighted score when probe weights are set Ravi Jonnalagadda
2026-10-05 8:54 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 5/9] mm/damon: add perf_event prep type, core lifecycle, and PMU arm/disarm Ravi Jonnalagadda
2026-10-05 9:02 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 6/9] mm/damon/sysfs: expose perf_event prep attributes Ravi Jonnalagadda
2026-10-05 8:56 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 7/9] mm/damon/tests/drain-kunit: kunit for report rings and ring drain Ravi Jonnalagadda
2026-10-05 8:59 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 8/9] mm/damon/core: cap the region merge threshold per target Ravi Jonnalagadda
2026-10-05 8:58 ` sashiko-bot
2026-10-05 8:46 ` [RFC PATCH v4 9/9] mm/damon/core: apply probe_hits_wsum filters to node_eligible_mem_bp Ravi Jonnalagadda
2026-10-05 8:59 ` sashiko-bot
2026-10-05 9:24 ` [RFC PATCH v4 0/9] mm/damon: hardware-sampled access reports SJ Park
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=20261005085841.66DAB1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=ravis.opensrc@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.