From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 02FE6344030 for ; Fri, 20 Mar 2026 11:33:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774006413; cv=none; b=osWZnMCMFASpdzfxp8ixHieEZksmQ9ckXOjHc/2RUaHTgd682uarBC3XM7JodGlF9pDUeegqlsjHVsFOwy8WTg5eeuF9YceNo4LTh/5/1cXMTRsM8ZrcXla5S+Zx60y/b8aRjSckTINSbu+x6quZyuwEEmdQWe5fjpz2AaH2lrM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774006413; c=relaxed/simple; bh=ZlmFijkHDWcuZv/ee3JFBOPSYSxx5p0eNtkud6YlakI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hYHy7Our2LDdFjhA5qGNR78gjb9pwn3eB0VcC+XhVDYpW/cy9Y45QsiR2U6I5tcbOYzFeL4XVMpZJlRYj/RZypSuI/jA8PAMwpaap86SittO+1B/hEQ/OzdwFYgJy2aIpiXjbYvpLqPlLjpOfcpNPvJjmfDwgsQ+k4fWjXWzXUQ= 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=byhVwfbH; arc=none smtp.client-ip=209.85.221.43 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="byhVwfbH" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-439cd6b0aedso1232208f8f.1 for ; Fri, 20 Mar 2026 04:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1774006410; x=1774611210; 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=3S86zsIMdrfTwxyiohbEf4eM7eTcf7P9TI7z+BHhdfE=; b=byhVwfbHXPf5P7OwGS+TG0esceb9hcFhU0D0mqG3czZLr4+tCAy/AXSLLuZWWiT4d7 USqaFl36l0+IOCXbgCTXfWLK1VwKJupErFr3+H2pb2ESFAalSbtxISh8R2C51xUMFLZH 7Ujtoka11JoBA1aEGpkYknYzLosAgctEkLwIkM3YK6evOSuecM84ZdaKSmmFkxHOa82v P0NWXhJtB6AMIfFQkL0cpC88dslaDb4Iha0rjJ8ujfxQWGKqpcfYMyubTuPbszAU5e2V ChT08bLtIpjcbQz45sV+JuA5v8qvA2cRe0Gwz5/bzxiZ1MuF38sXjTrpTd7E1DVxaH+A aX9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774006410; x=1774611210; 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=3S86zsIMdrfTwxyiohbEf4eM7eTcf7P9TI7z+BHhdfE=; b=S4Qr5NROfVkHX4OBMdMU0ygvr9RkfYBm5kN1BxVI/T3IZllaGw9EUza5NhbKaJRO0n 3mJyvrkwMe70U9+o1AjyC82LnT1EzO6AM7dNaE/2cF1t2j6975IJQNXxcUUFqq4cQ5Jd XxQ0uzZBwW3pPNpQHc+zFWz/NzCnMu0+aSZMYAdMScF716M0EzTHHixRyLDfU4WsmJvA sD+XB4pyieYYWUVfr6/sZib/XY879WKJz8Q0goYAUEWniNjFbC+9CBUeOyHDKFPY8/qr xoJnyGP5knrTVKVK65DfCu8sXdpVnkftbLv8R7I1fYZV77Pf6yluj868lI14zwWJPwE/ y7jA== X-Forwarded-Encrypted: i=1; AJvYcCXzLN/AZNEP9JTSjfeEv1TPXBNxlHxauHj8fybs2w5noTlaOASTdwTGz7jWTWftGVdy8gZvG2Zd6wlm9T8=@vger.kernel.org X-Gm-Message-State: AOJu0YwNk+r733RYnjfOmuDqdgyJM6o9WKj+bnLJmNJi1SG8Id72hFMO BB/A7qmFiacyOKJnbbNzJ2xwRFloiZJJ88UXNuw4Q33DSl3n8RX26IiCzx6qRTeOG+4= X-Gm-Gg: ATEYQzzRJyEb3wSC60y5bZM2p/T/Bu79lLTtnCxPs5n3g5Bwb6k2ZKUMOqBvVdHJbfc /3Uu6RIynOOgpqtDN5aPsT9YQRyzJ2AQFshYFaCqNH+nQH7XGqxbEvdazjb0T47NCSA5d0IDY4t bzQ9tp6LGieMfX6pKqXkXoSIZyhRhEWZXr42IHFimrcfH/rqr6yd2m5yUWSCEVuOJ1Pew25pdVJ Gm19mh1yiJ5FZhBmN8SkT5fDami+K86R1auHyXjLYtBjEvS3X58oGWmE07SezyNRXZ1nvSNmeeF 8ks2T8rFmWsd46fSgy2JESlbMwnI+xxI2gt+Yq3hIU+6/3pVVYmWSwAza0445hXZgLgsQA9QpzG Lc4AIm3CHxGFPY7PKtkDaM7YHX5YAbYutvOwTKz8sVPLOOXwN2R7KEQ725PIkWuJlfgrVhj2MhG StvJqeQgR/siBw+TybCH9rxTWzNg== X-Received: by 2002:a05:600c:8b61:b0:483:78c5:d743 with SMTP id 5b1f17b1804b1-486fee25f53mr38809955e9.28.1774006410163; Fri, 20 Mar 2026 04:33:30 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-486fe7dc4a2sm61221255e9.5.2026.03.20.04.33.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2026 04:33:29 -0700 (PDT) Date: Fri, 20 Mar 2026 12:33:28 +0100 From: Petr Mladek To: Marcos Paulo de Souza Cc: Joe Lawrence , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Shuah Khan , live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/8] selftests: livepatch: test-kprobe: Check if kprobes can work with livepatches Message-ID: References: <20260313-lp-tests-old-fixes-v1-0-71ac6dfb3253@suse.com> <20260313-lp-tests-old-fixes-v1-3-71ac6dfb3253@suse.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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu 2026-03-19 11:35:16, Marcos Paulo de Souza wrote: > On Mon, 2026-03-16 at 16:38 -0400, Joe Lawrence wrote: > > On Fri, Mar 13, 2026 at 05:58:34PM -0300, Marcos Paulo de Souza > > wrote: > > > Running the upstream selftests on older kernels can presente some > > > issues > > > regarding features being not present. One of such issues if the > > > missing > > > capability of having both kprobes and livepatches on the same > > > function. > > > > > > > nit picking, but slightly reworded for clarity and spelling: > > > > Running upstream selftests on older kernels can be problematic when > > features or fixes from newer versions are not present. For example, > > older kernels may lack the capability to support kprobes and > > livepatches > > on the same function simultaneously. > > Much better, I'll pick your description for v2. > > > > > > The support was introduced in commit 0bc11ed5ab60c > > > ("kprobes: Allow kprobes coexist with livepatch"), which means that > > > older > > > kernels may lack this change. > > > > > > The lack of this feature can be checked when a kprobe without a > > > post_handler is loaded and checking that the enabled_function's > > > file > > > shows the flag "I". A kernel with the proper support for kprobes > > > and > > > livepatches would presente the flag only when a post_handler is > > > > nit: s/presente/present > > > > --- a/tools/testing/selftests/livepatch/test-kprobe.sh > > > +++ b/tools/testing/selftests/livepatch/test-kprobe.sh > > > @@ -16,30 +16,19 @@ setup_config > > >  # when it uses a post_handler since only one IPMODIFY maybe be > > > registered > > >  # to any given function at a time. > > >   > > > -start_test "livepatch interaction with kprobed function with > > > post_handler" > > > - > > > -echo 1 > "$SYSFS_KPROBES_DIR/enabled" > > > - > > > -load_mod $MOD_KPROBE has_post_handler=1 > > > -load_failing_mod $MOD_LIVEPATCH > > > -unload_mod $MOD_KPROBE > > > - > > > -check_result "% insmod test_modules/test_klp_kprobe.ko > > > has_post_handler=1 > > > -% insmod test_modules/$MOD_LIVEPATCH.ko > > > -livepatch: enabling patch '$MOD_LIVEPATCH' > > > -livepatch: '$MOD_LIVEPATCH': initializing patching transition > > > -livepatch: failed to register ftrace handler for function > > > 'cmdline_proc_show' (-16) > > > -livepatch: failed to patch object 'vmlinux' > > > -livepatch: failed to enable patch '$MOD_LIVEPATCH' > > > -livepatch: '$MOD_LIVEPATCH': canceling patching transition, going > > > to unpatch > > > -livepatch: '$MOD_LIVEPATCH': completing unpatching transition > > > -livepatch: '$MOD_LIVEPATCH': unpatching complete > > > -insmod: ERROR: could not insert module > > > test_modules/$MOD_LIVEPATCH.ko: Device or resource busy > > > -% rmmod test_klp_kprobe" > > > - > > >  start_test "livepatch interaction with kprobed function without > > > post_handler" > > >   > > >  load_mod $MOD_KPROBE has_post_handler=0 > > > + > > > +# Check if commit 0bc11ed5ab60c ("kprobes: Allow kprobes coexist > > > with livepatch") > > > +# is missing, meaning that livepatches and kprobes can't be used > > > together. > > > +# When the commit is missing, kprobes always set IPMODIFY (the I > > > flag), even > > > +# when the post handler is missing. > > > +if grep --quiet ") R I" > > > "$SYSFS_DEBUG_DIR/tracing/enabled_functions"; then > > > > Will flags R I always be in this order? > > seq_printf(m, " (%ld)%s%s%s%s%s", > ftrace_rec_count(rec), > rec->flags & FTRACE_FL_REGS ? " R" : " ", > rec->flags & FTRACE_FL_IPMODIFY ? " I" : " > ", > > So this is safe. I'll add a comment in the patch to explain why this is > safe too. Thanks for the comment! I would personally check also "cmdline_proc_show" to make sure that the line is about this function. Something like: grep --quiet ") "cmdline_proc_show.*([0-9]\+) R" But I am afraid that this approach is not good. It breaks the test. It won't longer be able to catch regressions when the kprobe sets "FTRACE_FL_IPMODIFY" by mistake again. We could add a version check. But it would break users who backport the fix into older kernels. IMHO, the best solution would be to keep the test as is. Whoever is running the test with older kernels should mark it as "failure-expected". The test is pointing out an existing problem in the old kernel. IMHO, it should not hide it. Best Regards, Petr