public inbox for live-patching@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Lawrence <joe.lawrence@redhat.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: live-patching@vger.kernel.org, Song Liu <song@kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH v2 2/5] livepatch/klp-build: handle patches that add/remove files
Date: Tue, 10 Feb 2026 14:54:59 -0500	[thread overview]
Message-ID: <aYuNEwWoByiw0KDc@redhat.com> (raw)
In-Reply-To: <uy6a5xdp7e6cp6xj2r5zavb2ujtkapsjp2hixtgga4vwywkslv@6uhrgvb2hvo3>

On Thu, Feb 05, 2026 at 08:53:42AM -0800, Josh Poimboeuf wrote:
> On Thu, Feb 05, 2026 at 11:35:00AM -0500, Joe Lawrence wrote:
> > On Wed, Feb 04, 2026 at 10:02:38AM -0800, Josh Poimboeuf wrote:
> > > On Tue, Feb 03, 2026 at 09:51:37PM -0500, Joe Lawrence wrote:
> > > > The klp-build script prepares a clean patch by populating two temporary
> > > > directories ('a' and 'b') with source files and diffing the result.
> > > > However, this process currently fails when a patch introduces a new
> > > > source file as the script attempts to copy files that do not yet exist
> > > > in the original source tree.  Likewise, there is a similar limitation
> > > > when a patch removes a source file and the script tries to copy files
> > > > that no longer exist.
> > > > 
> > > > Refactor the file-gathering logic to distinguish between original input
> > > > files and patched output files:
> > > > 
> > > > - Split get_patch_files() into get_patch_input_files() and
> > > >   get_patch_output_files() to identify which files exist before and
> > > >   after patch application.
> > > > - Filter out "/dev/null" from both to handle file creation/deletion
> > > > - Update refresh_patch() to only copy existing input files to the 'a'
> > > >   directory and the resulting output files to the 'b' directory.
> > > > 
> > > > This allows klp-build to successfully process patches that add or remove
> > > > source files.
> > > > 
> > > > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> > > > ---
> > > >  scripts/livepatch/klp-build | 34 +++++++++++++++++++++++++++-------
> > > >  1 file changed, 27 insertions(+), 7 deletions(-)
> > > > 
> > > > Lightly tested with patches that added or removed a source file, as
> > > > generated by `git diff`, `git format-patch`, and `diff -Nupr`.
> > > > 
> > > > diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> > > > index 9f1b77c2b2b7..5a99ff4c4729 100755
> > > > --- a/scripts/livepatch/klp-build
> > > > +++ b/scripts/livepatch/klp-build
> > > > @@ -299,15 +299,33 @@ set_kernelversion() {
> > > >  	sed -i "2i echo $localversion; exit 0" scripts/setlocalversion
> > > >  }
> > > >  
> > > > -get_patch_files() {
> > > > +get_patch_input_files() {
> > > > +	local patch="$1"
> > > > +
> > > > +	grep0 -E '^--- ' "$patch"				\
> > > > +		| gawk '{print $2}'				\
> > > > +		| grep -v '^/dev/null$'				\
> > > 
> > > Because pipefail is enabled, the grep0 helper should be used instead of
> > > grep, otherwise a failed match can propagate to an error.  Maybe we need
> > > a "make check" or something which enforces that and runs shellcheck.
> > > 

How about defining our own grep in the script that intercepts the call
and throws an error:

  grep() {
  	echo "error: $SCRIPT: use grep0 or 'command grep' instead of bare grep" >&2
  	exit 1
  }

That seems easier than trying to externally parse the script to figure
out what's a command, comment, word-match, legit grep, etc.

--
Joe


  reply	other threads:[~2026-02-10 19:55 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-04  2:51 [PATCH v2 0/5] livepatch-klp-build: small fixups and enhancements Joe Lawrence
2026-02-04  2:51 ` [PATCH v2 1/5] objtool/klp: Fix mkstemp() failure with long paths Joe Lawrence
2026-02-04 16:47   ` Josh Poimboeuf
2026-02-05 15:53     ` Joe Lawrence
2026-02-04  2:51 ` [PATCH v2 2/5] livepatch/klp-build: handle patches that add/remove files Joe Lawrence
2026-02-04 18:02   ` Josh Poimboeuf
2026-02-05 16:35     ` Joe Lawrence
2026-02-05 16:53       ` Josh Poimboeuf
2026-02-10 19:54         ` Joe Lawrence [this message]
2026-02-10 20:57           ` Josh Poimboeuf
2026-02-04  2:51 ` [PATCH v2 3/5] livepatch/klp-build: switch to GNU patch and recountdiff Joe Lawrence
2026-02-04  2:58   ` Joe Lawrence
2026-02-04 18:35   ` Josh Poimboeuf
2026-02-05 17:27     ` Joe Lawrence
2026-02-05 17:49       ` Josh Poimboeuf
2026-02-04  2:51 ` [PATCH v2 4/5] livepatch/klp-build: minor short-circuiting tweaks Joe Lawrence
2026-02-04 18:40   ` Josh Poimboeuf
2026-02-05 17:47     ` Joe Lawrence
2026-02-04  2:51 ` [PATCH v2 5/5] livepatch/klp-build: provide friendlier error messages Joe Lawrence

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=aYuNEwWoByiw0KDc@redhat.com \
    --to=joe.lawrence@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.com \
    --cc=song@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