From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Andrey Konovalov <andreyknvl@gmail.com>,
Andrey Konovalov <andreyknvl@google.com>,
Clark Williams <williams@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Marco Elver <elver@google.com>
Subject: Re: [PATCH v4] kcov: move kcov_remote_data to task_struct and remove local_lock
Date: Fri, 22 May 2026 15:27:09 +0200 [thread overview]
Message-ID: <20260522132709.PHTrk7UJ@linutronix.de> (raw)
In-Reply-To: <7aff4d71-a6a0-4898-9491-2a3973e9d0cc@I-love.SAKURA.ne.jp>
On 2026-05-22 20:10:47 [+0900], Tetsuo Handa wrote:
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -86,21 +86,8 @@ struct kcov_remote {
>
> static DEFINE_SPINLOCK(kcov_remote_lock);
> static DEFINE_HASHTABLE(kcov_remote_map, 4);
> -static struct list_head kcov_remote_areas = LIST_HEAD_INIT(kcov_remote_areas);
> -
> -struct kcov_percpu_data {
> - void *irq_area;
> - local_lock_t lock;
> -
> - unsigned int saved_mode;
> - unsigned int saved_size;
> - void *saved_area;
> - struct kcov *saved_kcov;
> - int saved_sequence;
> -};
> -
> -static DEFINE_PER_CPU(struct kcov_percpu_data, kcov_percpu_data) = {
> - .lock = INIT_LOCAL_LOCK(lock),
> +static struct list_head kcov_remote_areas[2] = {
> + LIST_HEAD_INIT(kcov_remote_areas[0]), LIST_HEAD_INIT(kcov_remote_areas[1])
> };
>
> /* Must be called with kcov_remote_lock locked. */
> @@ -136,8 +123,9 @@ static struct kcov_remote_area *kcov_remote_area_get(unsigned int size)
> {
> struct kcov_remote_area *area;
> struct list_head *pos;
> + struct list_head *list = &kcov_remote_areas[size == CONFIG_KCOV_IRQ_AREA_SIZE];
This gets probably the job done but the two lists and check condition
looks a bit hackish. The size is not really important, it is user-sized
buffer vs softirq-buffer. Having an explicit might not be bad.
> @@ -1119,14 +1083,19 @@ static void __init selftest(void)
>
> static int __init kcov_init(void)
> {
> - int cpu;
> + int cpu = num_possible_cpus();
>
> - for_each_possible_cpu(cpu) {
> - void *area = vmalloc_node(CONFIG_KCOV_IRQ_AREA_SIZE *
> - sizeof(unsigned long), cpu_to_node(cpu));
> - if (!area)
> - return -ENOMEM;
> - per_cpu_ptr(&kcov_percpu_data, cpu)->irq_area = area;
> +#ifdef CONFIG_PREEMPT_RT
> + /* Allocate some extra buffers in order to prepare for softirq preemption. */
> + cpu = cpu >= 4 ? cpu * 2 : cpu + 4;
> +#endif
Maybe IS_ENABLED(). This assumes that we have twice as many tasks in
softirq context as we have CPUs. Is probably good enough.
Are the sizes somehow important? Any reason why there should not be a
"sane" lower size and then fallback to the user-buffer if it runs out of
softirqs buffers?
The user may request multiple sized buffers via KCOV_REMOTE_ENABLE, are
they cleaned up? The question would could the softirq use the user sized
buffers if any.
> + while (cpu--) {
> + void *area = vmalloc(CONFIG_KCOV_IRQ_AREA_SIZE * sizeof(unsigned long));
> + unsigned long flags;
> +
> + spin_lock_irqsave(&kcov_remote_lock, flags);
> + kcov_remote_area_put(area, CONFIG_KCOV_IRQ_AREA_SIZE);
> + spin_unlock_irqrestore(&kcov_remote_lock, flags);
> }
>
> /*
Sebastian
next prev parent reply other threads:[~2026-05-22 13:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 15:30 [PATCH (draft)] kcov: fix potential kcov_mode corruption under CONFIG_PREEMPT_RT Tetsuo Handa
2026-05-04 15:39 ` Tetsuo Handa
2026-05-05 8:15 ` [PATCH] " Tetsuo Handa
2026-05-06 11:55 ` [PATCH v2] kcov: fix state corruption under CONFIG_PREEMPT_RT by eliminating per-cpu data Tetsuo Handa
2026-05-09 8:09 ` [PATCH v3] kcov: move kcov_remote_data to task_struct for RT and remove local_lock Tetsuo Handa
2026-05-15 7:10 ` Dmitry Vyukov
2026-05-20 10:33 ` Tetsuo Handa
2026-05-20 15:12 ` Sebastian Andrzej Siewior
2026-05-21 8:38 ` Sebastian Andrzej Siewior
2026-05-21 15:28 ` Tetsuo Handa
2026-05-21 18:14 ` Sebastian Andrzej Siewior
2026-05-22 2:39 ` Tetsuo Handa
2026-05-22 11:10 ` [PATCH v4] kcov: move kcov_remote_data to task_struct " Tetsuo Handa
2026-05-22 13:27 ` Sebastian Andrzej Siewior [this message]
2026-05-29 6:35 ` Tetsuo Handa
2026-06-27 9:58 ` [PATCH v5] kcov: fix data corruption and race conditions on PREEMPT_RT by moving saved remote state to task_struct Tetsuo Handa
2026-07-07 13:36 ` Tetsuo Handa
2026-07-07 15:00 ` Alexander Potapenko
2026-07-07 22:07 ` Tetsuo Handa
2026-07-08 15:28 ` Alexander Potapenko
2026-07-09 13:35 ` Tetsuo Handa
2026-07-10 10:43 ` Alexander Potapenko
2026-07-10 11:32 ` [PATCH v6] " Tetsuo Handa
2026-07-10 12:16 ` Alexander Potapenko
2026-07-15 23:01 ` [PATCH v7] kcov: fix data corruption and race conditions on PREEMPT_RT Tetsuo Handa
2026-07-16 9:12 ` Alexander Potapenko
2026-07-10 14:24 ` [PATCH v6] kcov: fix data corruption and race conditions on PREEMPT_RT by moving saved remote state to task_struct Sebastian Andrzej Siewior
2026-05-21 13:06 ` [PATCH v3] kcov: move kcov_remote_data to task_struct for RT and remove local_lock Alexander Potapenko
2026-05-21 14:39 ` Tetsuo Handa
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=20260522132709.PHTrk7UJ@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=stern@rowland.harvard.edu \
--cc=williams@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox