From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69CDD35F18F for ; Tue, 7 Apr 2026 15:08:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775574488; cv=none; b=Cp9/nv7ghHsMBMS/tpMj6YrXPoo7wy4XxbHZZDbPQoFRr2BfWopUFTQC9t/BDwB0s439KM75fJt931hZycw+fAS/saJCRx0Alc/NZoqVqxU9+AYF0OLAfgDPqYLFXggOUJTe/qqL0cNgqob3oYRj84BwHfJQ8Z8tutQp+x6EihQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775574488; c=relaxed/simple; bh=ty0KOjKQyTnZaKdoshASSXSZqQBi5bCYN1Ysfs56ZTo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=d7moHkB4Fmkg5l0NnsLhitPLc9IPO9KwY/zeidWXfdedq0O8s+Uo23uRrW241HbkUE+eCdVgHGl57Row4sY5QiHwRaWoelT4ecvBhlNN92mREwQ2m+izrs9144j6WvjtBv3iRifKyjxLkEVrkZiXG5wMSkb1kIlYJaeGaRtWN6U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Fdh61hJ2; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Fdh61hJ2" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-488c21c636dso3058845e9.2 for ; Tue, 07 Apr 2026 08:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1775574485; x=1776179285; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=iGjzV8IRrkdKa9tu7b5Wnqj/M+3GwqIJMX4TAs0mafs=; b=Fdh61hJ2egMuHDvAbE6gAEG/65sTZblgScVS+1N3Vj1HG+HKR43vGkI0SxB6dluWUn onOkN9rBRgcJ9rtrNZijPd0J19K4tq4AU9Q9ZqTQHWaw4ZvLTGUIaawaWSmzHKF1emy+ N947KqfTVR1hijj1VCrVR6wrLIhVNr6MUmUD+7EPTpCv7eSEskkIFRo1shKkZkTuNCzD wdrqhes8jYnbjdBPzU1ryaGArly3DhzaQbWX9Q5IrvkW61ZJQAHL1RhTZkWITIV8nwEb DuhMeFtjHXFc+FqRGPjhR8r4LbRXvwMQHHcCZyEEyQjyfRv1fgrB9B7PHNXHYqo6Gem6 ZJkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775574485; x=1776179285; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iGjzV8IRrkdKa9tu7b5Wnqj/M+3GwqIJMX4TAs0mafs=; b=soT4P4FcVYdbXgm4byiPebYohlEHde9TVC+0LKpWx2QX1KNr9pqeCLQk7jZ5rn++pe +2Lh+C0FosMkS0+0jo2LgWzVsXsMXvKQS0Z1c1Oqz2cFH+uNcThaIYRGuKmdYdhUOAjN Xa7o9K7UZuwY3tx3QPD8Ha7q9d0GF0Xv/wGoCjiH4Z35KeOqvIvtIgFISi8D77XlLJKn wxucX/1hvoKynUKMEl0wNuvjnRi5HXw4UuasdFJEd+oNdbUD5klApfJYtfFUlqzZ6hGn ClynskqgO6SQqaiAqCHmZ0WlGNuwhix/2E/kvxBG3mYriW6ojaJJjyJy57Vy3/VDFY+d 9esA== X-Forwarded-Encrypted: i=1; AJvYcCX5nQJS6M9gqNlr4y7bLrDQQqGUVSBQiXvZzmKcnhwZNfNRem7MjlOsstTbi3+5WaU8dHFjEwg6NiE1GW8=@vger.kernel.org X-Gm-Message-State: AOJu0Yzkq1GydeuuvajnVQNQ8Xyh2EdVZtGiWsR65TL58ukJAjfd5nOU SYfSOwvtrc5Dg0wHoSq/GsxrGNulBHXm/XzpuAtrAuouOF7oICexxAKnJHASmtwT050= X-Gm-Gg: AeBDiev32LIFoDZsLWZl6bQlRVGBP2C0mmSzC+4jhwmgxP7Xa//bPg4GsHl89AssL3q gmD+dkAmoRcKvxIiIP3hLdESh3tHZlOR0NcgEME4tAQ1PsJBC+bwSs6GWZ+ho1o7Ccj2RDX5s06 HgJzkEzrbJibNvDIqMFgVVHvvQNdD7oJRZfSaXS9w2TXOXF/aucHtFaec9BheSaU5CGf2IGxC4f tg5zRDysYKBG4ApyDS/nZ3hp5BD+nUGfPN/zyLOvNVjns6KklI49oRwp2pW16fT2EBLCjyAG7cZ +CFGp0V2t4/592CBmme9G+amhra8201RB8xRt0urF17XOwmg2Xvyg51fv6YV9ubj+jZ2MTLWzSK qhufJQC6fj+F6LS1RNkmmCnu2DlcQPsK1yAtfZsXroy/3z+ELSjs6n1UuAjjUAySv6LvknGBtIm QzqO/wpETkWg4FMO68kRHd0AdbYaSBh/8Cv/BRiMm7lLQXKpBjrIg= X-Received: by 2002:a05:600c:138f:b0:47e:e076:c7a5 with SMTP id 5b1f17b1804b1-4889970e3c4mr239821275e9.11.1775574484681; Tue, 07 Apr 2026 08:08:04 -0700 (PDT) Received: from pathway.suse.cz (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4888a7165aasm555642275e9.14.2026.04.07.08.08.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2026 08:08:03 -0700 (PDT) Date: Tue, 7 Apr 2026 17:08:00 +0200 From: Petr Mladek To: Yafang Shao Cc: Song Liu , Joe Lawrence , Dylan Hatch , jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz, rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, kpsingh@kernel.org, mattbobrowski@google.com, jolsa@kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com, memxor@gmail.com, yonghong.song@linux.dev, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [RFC PATCH 3/4] livepatch: Add "replaceable" attribute to klp_patch Message-ID: References: <20260402092607.96430-4-laoar.shao@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue 2026-04-07 17:45:31, Yafang Shao wrote: > On Tue, Apr 7, 2026 at 11:16 AM Yafang Shao wrote: > > > > On Tue, Apr 7, 2026 at 10:54 AM Song Liu wrote: > > > > > > On Mon, Apr 6, 2026 at 2:12 PM Joe Lawrence wrote: > > > [...] > > > > > > > - The regular livepatches are cumulative, have the replace flag; and > > > > > > > are replaceable. > > > > > > > - The occasional "off-band" livepatches do not have the replace flag, > > > > > > > and are not replaceable. > > > > > > > > > > > > > > With this setup, for systems with off-band livepatches loaded, we can > > > > > > > still release a cumulative livepatch to replace the previous cumulative > > > > > > > livepatch. Is this the expected use case? > > > > > > > > > > > > That matches our expected use case. > > > > > > > > > > If we really want to serve use cases like this, I think we can introduce > > > > > some replace tag concept: Each livepatch will have a tag, u32 number. > > > > > Newly loaded livepatch will only replace existing livepatch with the > > > > > same tag. We can even reuse the existing "bool replace" in klp_patch, > > > > > and make it u32: replace=0 means no replace; replace > 0 are the > > > > > replace tag. > > > > > > > > > > For current users of cumulative patches, all the livepatch will have the > > > > > same tag, say 1. For your use case, you can assign each user a > > > > > unique tag. Then all these users can do atomic upgrades of their > > > > > own livepatches. > > > > > > > > > > We may also need to check whether two livepatches of different tags > > > > > touch the same kernel function. When that happens, the later > > > > > livepatch should fail to load. I still think how to make the hybrid mode more secure: + The isolated sets of livepatched functions look like a good rule. + What about isolating the shadow variables/states as well? > > That sounds like a viable solution. I'll look into it and see how we > > can implement it. > > Does the following change look good to you ? > > Subject: [PATCH] livepatch: Support scoped atomic replace using replace tags > > Extend the replace attribute from a boolean to a u32 to act as a replace > tag. This introduces the following semantics: > > replace = 0: Atomic replace is disabled. However, this patch remains > eligible to be superseded by others. > replace > 0: Enables tagged replace (default is 1). A newly loaded > livepatch will only replace existing patches that share the > same tag. > > To maintain backward compatibility, a patch with replace == 0 does not > trigger an outgoing atomic replace, but remains eligible to be superseded > by any incoming patch with a valid replace tag. > > diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h > index ba9e3988c07c..417c67a17b99 100644 > --- a/include/linux/livepatch.h > +++ b/include/linux/livepatch.h > @@ -123,7 +123,11 @@ struct klp_state { > * @mod: reference to the live patch module > * @objs: object entries for kernel objects to be patched > * @states: system states that can get modified > - * @replace: replace all actively used patches > + * @replace: replace tag: > + * = 0: Atomic replace is disabled; however, this patch remains > + * eligible to be superseded by others. This is weird semantic. Which livepatch tag would be allowed to supersede it, please? Do we still need this category? > + * > 0: Atomic replace is enabled. Only existing patches with a > + * matching replace tag will be superseded. > * @list: list node for global list of actively used patches > * @kobj: kobject for sysfs resources > * @obj_list: dynamic list of the object entries > @@ -137,7 +141,7 @@ struct klp_patch { > struct module *mod; > struct klp_object *objs; > struct klp_state *states; > - bool replace; > + unsigned int replace; This already breaks the backward compatibility by changing the type and semantic of this field. I would also change the name to better match the new semantic. What about using: * @replace_set: Livepatch using the same @replace_set will get atomically replaced, see also conflicts[*]. unsigned int replace_set; [*] A livepatch module, livepatching an already livepatches function, can be loaded only when it has the same @replace_set number. By other words, two livepatches conflict when they have a different @replace_set number and have at least one livepatched version in common. > > /* internal */ > struct list_head list; > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > index 28d15ba58a26..e4e5c03b0724 100644 > --- a/kernel/livepatch/core.c > +++ b/kernel/livepatch/core.c > @@ -793,6 +793,8 @@ void klp_free_replaced_patches_async(struct > klp_patch *new_patch) > klp_for_each_patch_safe(old_patch, tmp_patch) { > if (old_patch == new_patch) > return; > + if (old_patch->replace && old_patch->replace != > new_patch->replace) > + continue; > klp_free_patch_async(old_patch); > } > } > @@ -1194,6 +1196,8 @@ void klp_unpatch_replaced_patches(struct > klp_patch *new_patch) > klp_for_each_patch(old_patch) { > if (old_patch == new_patch) > return; > + if (old_patch->replace && old_patch->replace != > new_patch->replace) > + continue; > > old_patch->enabled = false; > klp_unpatch_objects(old_patch); This handles only the freeing part. More changes will be necessary: + klp_is_patch_compatible() must check also conflicts between livepatches with different @replace_set. The conflicts might be in the lists of: + livepatched functions + state IDs (aka callbacks and shadow variables IDs) + klp_add_nops() must skip livepatches with another @replace_set + klp_unpatch_replaced_patches() should unpatch only patches with the same @replace_set Finally, we would need to update existing selftests plus add new selftests. It is possible that I have missed something. Anyway, you should wait for more feedback before you do too much coding, especially the selftests are not needed at RFC stage. Best Regards, Petr