From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 15212368957 for ; Fri, 20 Mar 2026 11:33:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774006413; cv=none; b=ifX75DjAbBZfBsUb8vCX0zpvsbmipiAF1XIkujXsskX06zDksmGW5vHHeWAwIfr/uwlnR0a22Aghpbldxj2AzmLvQ36xwcqAekjS5XSBx4cSZCZGkBLTkS3LaEvLUDJwRSXsL+Z85iXC9h5oSgxLpedfR7sVcBkNXgHzeixDGWg= 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.128.42 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-wm1-f42.google.com with SMTP id 5b1f17b1804b1-486ff201041so4907355e9.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=L60seULLU/qKBK15A+qc1cjr2eHR/AljxhuRDEzhv6UOXvtR0PBx7OoH7FcPcOMVR0 692dYFiGNhc4/NwHT0+zBX0mpxkmdQHzXie9F+SDkPWWfkuhwLNUZzUOjxr4EsouxhcY dbcj4mzLRfLxkIA3pXZuO5A7jphE31HSx6nvMMtxlBwD0N97QVaLLQGlGZjCK+21Cwwg 8iIRpMP0UUqWQNEsbSosMZUzVM61JdjBjtmj5T89hqk/QrvPZ70KcroRruqTbJzeMdrM o5W35Tvvq4kO8XbNzhVFdSOsvMNyYqzGwEx07P7oUgMP0Qbdu3HIJvtWlgXBs8W5q/lg e4+w== X-Forwarded-Encrypted: i=1; AJvYcCWt7fYiocaLlrW/OmX01h1/lpPWIE8GxluiSDFFY0zm8wCXvR36yzka7LoUUJy2zaUXPr/+IKgjdy4vYXo0z7Q=@vger.kernel.org X-Gm-Message-State: AOJu0YyhyMSbUEwc8axqf/kZ+F5NuRP6DrIi2XL//OlBm3y88k5dgPaA 92gqMJrSHfqlHSIA+oTUJdLXCzIOfor+TSpzp4Ktq2bnPdLSftIO6/Nn/6YgP+Lj9os= X-Gm-Gg: ATEYQzz6xpFRfcSIhXDm8+VDNcbtXapqktBUNPi8CfnPxWUXPqW7JMILstLeaKZ+acG pcy97B4wwNFLhRkSv6M+jgVDiXotiFhmGNXPVnWUF8a/T+SLbAAcf6/4sNNFG9fGy67xUPDxMjb pNjL/dFEhtFyLvVU3sBze9LLxGXklXfm06JbyLx8cBKkNW5yGC6Hj5JjaY9aClKkYxde4Nn+Svb 2AlL136xN1GEv+i0cM9F4rdIgdnbkgNy7UdOWBHEFUFfanw5N+XPPs/zPsGK0lyIo3CLfVWofVL +bPpnMUyUZFZdxeEdbtrdjBAEBj5ausiTlwoSP+R32GPEUYQMqbJQ+F7Ze6AVV58nLCnx09bUji 4NelCT8V0+wBooH10gA8A9m2dTrnc/MUiSnipKWoZ/S11Aw+q5uoBU2+hdAK8ncQmxxo0ULjY2j VqFjNOQvZNHEBeGDP/HXMMbP6jUg== 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-kselftest@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