From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 7C4903A4524 for ; Tue, 21 Apr 2026 09:19:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776763174; cv=none; b=HDpTIsCwTCAHBzqO5HppcnpnTo5GLmQGvayuuiYel8nMCBoGr+JDf7/7COjwbOt0OJu3Xo9dWvD+/EbCA7gRr0PC1KGp7Ib30useXAxJh/tI5FhOJYgLBhzYqU/bx1Azw3v1MSDUbtqKGIusTEYaIB6Nq+i+M2ebZBxCazlrlFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776763174; c=relaxed/simple; bh=hqjjierdnK8tvLKU75m7iQooxG9Jq1+vcj806CxQ1fY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UUGEKet7O5ldTMoz/8cq/2n+bj9uWRYP3IOf3kICpFjM/F7XaVGR17zynnnAB5AOzPafLjsCODjmFmx5QDoHAJ1ywSTEMidXc9A8gm/VJF7w4EBKjyurpyDlDGHA8cyU7Rsmt05K8MbqFEyPyyTaRKkOfXBllw9IOrGpnQTGNhw= 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=O2t699Tj; arc=none smtp.client-ip=209.85.221.51 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="O2t699Tj" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-43d7650202fso3149738f8f.2 for ; Tue, 21 Apr 2026 02:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1776763171; x=1777367971; 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=lB/lqGejdq32Wkl/DU7VEtSFz/Euk52yRw6vT31OnNE=; b=O2t699Tj9FK7jfkmiFzV9OWp4Y12g4FucSX1Gzj6WSnxhwJz/xqFBN/ocSNwVBoyiD GE4D98zVQ9Zx8fXmBx6ibFM4A3Hb2d3e25D92Xcxxch09e+Ii9nMfmT4A9w3YEgdNjpj rn4NKt1W6Eo4+VTtTTr/gh706EKbRqz+Nbl5G/j7c9raNLYpNTLI9GWbKgjkxey+RD1W bQN2/fKF4EJIri0TMmdFcmxshPbUA/tqFbGccjSfbynTSperHQ/tFLAkBHpcm88eVOxf RBOp9f1Dgo3bCHymHtS2EN1jUSJDmFuImUS/t/+SYSK5PKk+dSnoiu2kQAIoLu0k4AWG zW+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776763171; x=1777367971; 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=lB/lqGejdq32Wkl/DU7VEtSFz/Euk52yRw6vT31OnNE=; b=mE2Djfq0CsaQTMjYiqhWgvNNdGtzQZyAALMRfruznYCItK0NtYsvf6S2cxQRVJO9SV PHLO/vsJnhixTucStnq3dfMIwXpraxeriBamR5DI5e3MjQOE9FzH02J70NfRCOpKt53Z FCfUwsWffUcpfuorhYQ4o55OQcr7cAGLe3OnHuJ/+wtKfvFz+zXHcy2P02jV5Hsaind4 L22A1pbsDAUVQcGI2Ry6/0IABzAjjh3g9qsXrwH6703ie4RES9jvGiWZR2R2aEcL4BMb P1O+0eQsc/9BhmOOvl50FP5384DaZihaGz5jhDIAiGAfUQgOogJCPUmSol4ezHIFkSKR IPxQ== X-Forwarded-Encrypted: i=1; AFNElJ8EPvYDEJrcBu5mgXsNKjs6hL8CydkFm9xoKYhtCsI6JjuJW1m7FieCN5LCRstyGV6UVBfiXrnTRsoVVIU=@vger.kernel.org X-Gm-Message-State: AOJu0YyD2iRRRyQ0DoVsfw06Zzi3vX7i5IwmKL5HsqMsm/ZLV7YmDn9R /ssp29XOhhcXxiLjrULganJE08s3vafbiR6Rdx1vOUpU8d16pQe5OAw9M825A2kyufdtHXJPxz0 RS5nSFvU= X-Gm-Gg: AeBDieseHf9WpU0oUqmt6xrgnj4OvOnm+dHSVhwRRewJOl8W8E4aGLndOMAteEzMhIa +8IRYfEFNZwjbEmVO9lQv8v2efJyzKqOP7l8Eo4OCgaYRGKWAOM9sZyuiv3PeNORNqACSrd89Ct PODOxfn2/Pb9bRRgZH4sdAwR7OiVOc6YYYZ8cjrx9OpQf8k92c1l03ihotTNwtvCiAN1jiI+zBp YAlSwskCbWWa2zCDwd80AMtkV6IZE4OKBy42zRhW540Zqj0c9OwpPI1utoMdWds6h3Pn9yLT+UX rSNlXcbTxRjYcliPAxOBmS3Xtw0d1gOFdVxlSA8tloxLEPT84xmzH60iizw0U6sX4TjnFXcKz3k nH/LI7PGKaljK6wlCKlsghqGnHODrrpNKMYQAOA0g3MWBMtzXJTRy6dWmHEURsPzvO7WvvCLXnF em/cOyctgxjNSL+AeoNDsW1ciAajJ2Tky5GNd/8+lwbk8911IFu2Q= X-Received: by 2002:a05:6000:24c3:b0:43d:dd:8ca4 with SMTP id ffacd0b85a97d-43fe3dd33d4mr27397358f8f.14.1776763170663; Tue, 21 Apr 2026 02:19:30 -0700 (PDT) Received: from pathway.suse.cz (nat2.prg.suse.com. [195.250.132.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4cc0d51sm35517843f8f.10.2026.04.21.02.19.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 02:19:29 -0700 (PDT) Date: Tue, 21 Apr 2026 11:19:26 +0200 From: Petr Mladek To: Yafang Shao Cc: Song Liu , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz, joe.lawrence@redhat.com, kernel-team@meta.com Subject: Re: [PATCH] samples/livepatch: Add BPF struct_ops integration sample Message-ID: References: <20260416001628.2062468-1-song@kernel.org> 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 Sun 2026-04-19 11:19:19, Yafang Shao wrote: > On Fri, Apr 17, 2026 at 11:52 PM Song Liu wrote: > > > > On Fri, Apr 17, 2026 at 6:20 AM Petr Mladek wrote: > > > > > > On Thu 2026-04-16 09:32:46, Song Liu wrote: > > [...] > > > Let' use the code from this patch: > > > > > > static int __init livepatch_bpf_init(void) > > > { > > > int ret; > > > > > > ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS, > > > &klp_bpf_kfunc_set); > > > ret = ret ?: register_bpf_struct_ops(&bpf_klp_bpf_cmdline_ops, > > > klp_bpf_cmdline_ops); > > > if (ret) > > > return ret; > > > > > > ---> /* > > > ---> * We would need to wait here until the BPF program gets loaded. > > > ---> * for the new bpf_struct_ops in this new livepatch. > > > ---> */ > > No waiting is necessary. If the BPF program is not attached, the > default logic can be executed instead. But it means a regression. I guess that you need the BPF program for a reason. The default logic is not good enough indeed. > Consider Song's test case: we can handle it as follows. > > static int livepatch_cmdline_proc_show(struct seq_file *m, void *v) > { > struct klp_bpf_cmdline_ops *ops = READ_ONCE(active_ops); > > if (ops && ops->set_cmdline) > return ops->set_cmdline(m); > > // If no BPF program is attached, the default kernel function runs. > return cmdline_proc_show(m, v); > } > > However, as Song explained below, if we want atomic replace to work, > we may need to wait for the new BPF program here. But that would make > the combination of livepatch and BPF more complex. > > Currently, on our production servers, we handle this through a user > script, such as: > > stop_traffic_relying_on_livepatch_bpf > kpatch load new-livepatch-bpf-module.ko > reattach_the_bpf_program > start_the_traffic_again > > Although this approach requires restarting the affected traffic, other > services running on the same server remain unaffected. We put a lot of effort to make livepatching as less disruptive as possible. The atomic replace is supposed to work without any disruption. > > > return klp_enable_patch(&patch); > > > } > > > > Yes, something in this direction is needed to make atomic replace work. > > We have no plan to use this in production. I will let Yafang figure out > > his plan. > > > > > Or maybe, the bpf_struct_ops can be _allocated dynamically_ and > > > the pointer might be _passed via shadow variables_. > > > > > > One problem is that shadow variables would add another overhead > > > and need not be suitable for hot paths. > > > > > > > > > Anyway, I think that I have similar feelings as Miroslav. > > > The combination of livepatches and BPF programs increases > > > the complexity for all involved parties: core kernel maintainers, > > > livepatch and BPF program authors, and system maintainers. > > > > > > Do we really want to propagate it? > > > Is there any significant advantage in combining these two, please? > > > Is it significantly easier to write BPF program then a livepatch? > > > Is it significantly easier to update BPF programs then livepatches? > > This is an important feature for avoiding server restarts, > particularly in a VM host environment. Since only one VM on the host > may be affected by this feature, we can deploy it rapidly without > impacting other VMs on the same host. This does not answer the question why you need the combination of livepatch + BPF. Why a livepatch is not enough? Let me repeat the questions: Is it significantly easier to write BPF program then a livepatch? Is it significantly easier to install BPF programs then livepatches? > > > Would the support of different replace tags help? > > > They would allow to replace only livepatches with the same tag. > > Right, it will help. Would this make a rapid update of livepatches easy enough so that you won't need the BPF part? Best Regards, Petr