Live Patching
 help / color / mirror / Atom feed
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

  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