From: Miroslav Benes <mbenes@suse.cz>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
Song Liu <song@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, petr.pavlu@suse.com
Subject: Re: [PATCH] livepatch: Fix races between stack check and module load/unload
Date: Wed, 14 Oct 2026 14:23:50 +0200 (CEST) [thread overview]
Message-ID: <alpine.LSU.2.21.2610141410370.16733@pobox.suse.cz> (raw)
In-Reply-To: <20261012140546.154730-1-parri.andrea@gmail.com>
Hi Andrea,
Cc+ Petr Pavlu (you can find the whole thread at
https://lore.kernel.org/live-patching/20261012150758.207983-1-parri.andrea@gmail.com/T/#t)
On Mon, 12 Oct 2026, Andrea Parri wrote:
> Unloading a patched module while a livepatch transition is in progress
> can crash the kernel in klp_find_ops(), called from the scheduler.
> KCSAN reports
>
> BUG: KCSAN: data-race in klp_find_ops / klp_unpatch_func
>
> write (marked) to 0xffff9094c09ece10 of 8 bytes by task 381 on cpu 2:
> klp_unpatch_func+0x1bd/0x280
> klp_unpatch_object+0x6a/0x90
> klp_cleanup_module_patches_limited.cold+0x4a/0xd4
> klp_module_going+0x54/0x80
> __do_sys_delete_module+0x247/0x380
> __x64_sys_delete_module+0x39/0x50
> ...
>
> read to 0xffff9094c09ece10 of 8 bytes by task 146 on cpu 1:
> klp_find_ops+0x55/0x90
> klp_check_and_switch_task+0x228/0x320
> klp_try_switch_task+0xb4/0xc0
> __klp_sched_try_switch+0x9a/0xb0
> __schedule+0x60a/0x1450
> schedule+0x3b/0x100
> schedule_timeout+0xc0/0x160
> ra_target_a_loop+0x97/0xa0 [klp_race_target_a]
> ...
>
> followed by
>
> Oops: general protection fault, probably for non-canonical address
> 0xdead000000000110: 0000 [#2] SMP NOPTI
> RIP: 0010:klp_find_ops+0x55/0x90
> ...
> klp_check_and_switch_task+0x228/0x320
> klp_try_switch_task+0xb4/0xc0
> __klp_sched_try_switch+0x9a/0xb0
> __schedule+0x60a/0x1450
Interesting. So to sum it up... you load a live patch which contains a fix
for a module and while the transition is on, you remove the module and it
crashes (btw, I do not think that those traces are necessary here. More
btw, it would be nice to have a human readable changelog instead of what
looks like AI generated description of the patch itself).
How did you find the issue? Is it a real problem in production?
I wonder whether we could just decline delete_module() in this case and
return -EBUSY. It should be a rare operation anyway. Alternatively we
could increase refcounts of all patched modules during a transition and
decrease them after. Petr P., what do you think?
I am not saying we should not do the RCU protection but it feels like a
can of worms a bit so if there is an easier way...
Regards
Miroslav
next prev parent reply other threads:[~2026-10-14 12:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 14:05 [PATCH] livepatch: Fix races between stack check and module load/unload Andrea Parri
2026-10-12 14:49 ` Peter Zijlstra
2026-10-12 15:07 ` Andrea Parri
2026-10-14 12:23 ` Miroslav Benes [this message]
2026-10-14 13:35 ` Andrea Parri
2026-10-14 14:30 ` Petr Mladek
2026-10-14 20:36 ` Andrea Parri
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=alpine.LSU.2.21.2610141410370.16733@pobox.suse.cz \
--to=mbenes@suse.cz \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=parri.andrea@gmail.com \
--cc=peterz@infradead.org \
--cc=petr.pavlu@suse.com \
--cc=pmladek@suse.com \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
/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