From: Yunseong Kim <ysk@kzalloc.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dmitry Vyukov <dvyukov@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Byungchul Park <byungchul@sk.com>,
max.byungchul.park@gmail.com,
"ppbuk5246 @ gmail . com" <ppbuk5246@gmail.com>,
linux-kernel@vger.kernel.org,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Alan Stern <stern@rowland.harvard.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
stable@vger.kernel.org, kasan-dev@googlegroups.com,
syzkaller@googlegroups.com, linux-usb@vger.kernel.org,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v2] kcov, usb: Fix invalid context sleep in softirq path on PREEMPT_RT
Date: Sun, 3 Aug 2025 07:01:40 +0900 [thread overview]
Message-ID: <4a505533-b725-4e3f-94db-3d261937ea25@kzalloc.com> (raw)
In-Reply-To: <2025080212-expediter-sinless-4d9c@gregkh>
Hi Greg,
On 8/3/25 6:30 오전, Greg Kroah-Hartman wrote:
> On Sat, Aug 02, 2025 at 02:26:49PM +0000, Yunseong Kim wrote:
>> The KCOV subsystem currently utilizes standard spinlock_t and local_lock_t
>> for synchronization. In PREEMPT_RT configurations, these locks can be
>> implemented via rtmutexes and may therefore sleep. This behavior is
>> problematic as kcov locks are sometimes used in atomic contexts or protect
>> data accessed during critical instrumentation paths where sleeping is not
>> permissible.
>>
>> Address these issues to make kcov PREEMPT_RT friendly:
>>
>> 1. Convert kcov->lock and kcov_remote_lock from spinlock_t to
>> raw_spinlock_t. This ensures they remain true, non-sleeping
>> spinlocks even on PREEMPT_RT kernels.
>>
>> 2. Refactor the KCOV_REMOTE_ENABLE path to move memory allocations
>> out of the critical section. All necessary struct kcov_remote
>> structures are now pre-allocated individually in kcov_ioctl()
>> using GFP_KERNEL (allowing sleep) before acquiring the raw
>> spinlocks.
>>
>> 3. Modify the ioctl handling logic to utilize these pre-allocated
>> structures within the critical section. kcov_remote_add() is
>> modified to accept a pre-allocated structure instead of allocating
>> one internally.
>>
>> 4. Remove the local_lock_t protection for kcov_percpu_data in
>> kcov_remote_start/stop(). Since local_lock_t can also sleep under
>> RT, and the required protection is against local interrupts when
>> accessing per-CPU data, it is replaced with explicit
>> local_irq_save/restore().
>
> why isn't this 4 different patches?
Thank you for your feedback on the patch. I’ll split it into four separate
patches for v3 to improve clarity.
Best regards,
Yunseong Kim
prev parent reply other threads:[~2025-08-02 22:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-02 14:26 [PATCH v2] kcov, usb: Fix invalid context sleep in softirq path on PREEMPT_RT Yunseong Kim
2025-08-02 21:30 ` Greg Kroah-Hartman
2025-08-02 21:30 ` Greg Kroah-Hartman
2025-08-02 22:01 ` Yunseong Kim [this message]
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=4a505533-b725-4e3f-94db-3d261937ea25@kzalloc.com \
--to=ysk@kzalloc.com \
--cc=andreyknvl@gmail.com \
--cc=bigeasy@linutronix.de \
--cc=byungchul@sk.com \
--cc=dvyukov@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=linux-usb@vger.kernel.org \
--cc=max.byungchul.park@gmail.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=ppbuk5246@gmail.com \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=syzkaller@googlegroups.com \
--cc=tglx@linutronix.de \
/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