FAILED: patch "[PATCH] fs: relax assertions on failure to encode file handles" failed to apply to 6.1-stable tree

FAILED: patch "[PATCH] fs: relax assertions on failure to encode file handles" failed to apply to 6.1-stable tree

[gregkh]

The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

To reproduce the conflict and resubmit, you may use the following commands:

git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 974e3fe0ac61de85015bbe5a4990cf4127b304b2
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2025011112-racing-handbrake-a317@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..

Possible dependencies:



thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 974e3fe0ac61de85015bbe5a4990cf4127b304b2 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il@gmail.com>
Date: Thu, 19 Dec 2024 12:53:01 +0100
Subject: [PATCH] fs: relax assertions on failure to encode file handles

Encoding file handles is usually performed by a filesystem >encode_fh()
method that may fail for various reasons.

The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.

There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when ->encode_fh() fails.
Relax those assertions because they are wrong.

The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
encoding non-decodable file handles") in v6.6 as the regressing commit,
but this is not accurate.

The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.

Triggering this assertion was always possible with other filesystems and
other reasons of ->encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlayfs that is
mounted with options index=on,nfs_export=on also on kernels < v6.6.
Therefore, I am not listing the aforementioned commit as a Fixes commit.

Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
Reported-by: Dmitry Safonov <dima@arista.com>
Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>

diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index dec553034027..e933f9c65d90 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -47,10 +47,8 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
 	size = f->handle_bytes >> 2;
 
 	ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size);
-	if ((ret == FILEID_INVALID) || (ret < 0)) {
-		WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
+	if ((ret == FILEID_INVALID) || (ret < 0))
 		return;
-	}
 
 	f->handle_type = ret;
 	f->handle_bytes = size * sizeof(u32);
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 3601ddfeddc2..56eee9f23ea9 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -442,9 +442,8 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
 	buflen = (dwords << 2);
 
 	err = -EIO;
-	if (WARN_ON(fh_type < 0) ||
-	    WARN_ON(buflen > MAX_HANDLE_SZ) ||
-	    WARN_ON(fh_type == FILEID_INVALID))
+	if (fh_type < 0 || fh_type == FILEID_INVALID ||
+	    WARN_ON(buflen > MAX_HANDLE_SZ))
 		goto out_err;
 
 	fh->fb.version = OVL_FH_VERSION;

[PATCH 6.1.y 0/1] Backporting patches with git-llm-pick

[Norbert Manthey]

Dear all,

we looked into improving commit backporting workflows. This specific commit in
this series caught our attention, as it states that backporting will not be
trivial. The commit message has this part: 

Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

We want to automate backporting commits with a similar property. Therefore, we
build a tool git-llm-pick that simplifies the backporting commit. After
cherry-picking, we try to automatically detect dependency-commits. In case of
failure, we then try to use the patch tool. If this process fails, we then take
the rejected patch files, and feed their content with other context and a task
description to backport to an LLM. The resulting code modification is then
applied. In case validation is passed, a commit is created. The commit message
is always extended by a description of the adapted code change, and with which
technique a commit was applied.

We made the tool available on github: https://github.com/awslabs/Git_llm_pick/
We currently use LLMs via the AWS Bedrock service, and default to the Nova Pro
model. The patch in this series uses the vanilla version of the tool's current
output when running git-llm-pick in its virtual test environment:

SKIP_VENV_GLP_TESTING=1 $GLP_PATH/test/test-in-venv.sh \
    git-llm-pick \
    --validation-command $GLP_PATH/bin/glp-compile-test-changed-kernel-file.sh \
    -x f47c834a9131ae64bee3c462f4e610c67b0a000f

Best,
Norbert

Amir Goldstein (1):
  fs: relax assertions on failure to encode file handles

 fs/notify/fdinfo.c     | 4 +---
 fs/overlayfs/copy_up.c | 5 ++---
 2 files changed, 3 insertions(+), 6 deletions(-)

-- 
2.34.1




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

[PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[Norbert Manthey]

From: Amir Goldstein <amir73il@gmail.com>

commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.

Encoding file handles is usually performed by a filesystem >encode_fh()
method that may fail for various reasons.

The legacy users of exportfs_encode_fh(), namely, nfsd and
name_to_handle_at(2) syscall are ready to cope with the possibility
of failure to encode a file handle.

There are a few other users of exportfs_encode_{fh,fid}() that
currently have a WARN_ON() assertion when ->encode_fh() fails.
Relax those assertions because they are wrong.

The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
encoding non-decodable file handles") in v6.6 as the regressing commit,
but this is not accurate.

The aforementioned commit only increases the chances of the assertion
and allows triggering the assertion with the reproducer using overlayfs,
inotify and drop_caches.

Triggering this assertion was always possible with other filesystems and
other reasons of ->encode_fh() failures and more particularly, it was
also possible with the exact same reproducer using overlayfs that is
mounted with options index=on,nfs_export=on also on kernels < v6.6.
Therefore, I am not listing the aforementioned commit as a Fixes commit.

Backport hint: this patch will have a trivial conflict applying to
v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
Reported-by: Dmitry Safonov <dima@arista.com>
Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
- Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match the destination code.
- Removed the warning message as per the patch.

Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
Tested-by: Ömer Erdinç Yağmurlu <oeygmrl@amazon.de>
---
 fs/notify/fdinfo.c     | 4 +---
 fs/overlayfs/copy_up.c | 5 ++---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 55081ae3a6ec0..dd5bc6ffae858 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -51,10 +51,8 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
 	size = f.handle.handle_bytes >> 2;
 
 	ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, &size, NULL);
-	if ((ret == FILEID_INVALID) || (ret < 0)) {
-		WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
+	if ((ret == FILEID_INVALID) || (ret < 0))
 		return;
-	}
 
 	f.handle.handle_type = ret;
 	f.handle.handle_bytes = size * sizeof(u32);
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 203b88293f6bb..ced56696beeb3 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -361,9 +361,8 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
 	buflen = (dwords << 2);
 
 	err = -EIO;
-	if (WARN_ON(fh_type < 0) ||
-	    WARN_ON(buflen > MAX_HANDLE_SZ) ||
-	    WARN_ON(fh_type == FILEID_INVALID))
+	if (fh_type < 0 || fh_type == FILEID_INVALID ||
+	    WARN_ON(buflen > MAX_HANDLE_SZ))
 		goto out_err;
 
 	fh->fb.version = OVL_FH_VERSION;
-- 
2.34.1




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[Amir Goldstein]

On Mon, Sep 1, 2025 at 5:36 PM Norbert Manthey <nmanthey@amazon.de> wrote:
>
> From: Amir Goldstein <amir73il@gmail.com>
>
> commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
>
> Encoding file handles is usually performed by a filesystem >encode_fh()
> method that may fail for various reasons.
>
> The legacy users of exportfs_encode_fh(), namely, nfsd and
> name_to_handle_at(2) syscall are ready to cope with the possibility
> of failure to encode a file handle.
>
> There are a few other users of exportfs_encode_{fh,fid}() that
> currently have a WARN_ON() assertion when ->encode_fh() fails.
> Relax those assertions because they are wrong.
>
> The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> encoding non-decodable file handles") in v6.6 as the regressing commit,
> but this is not accurate.
>
> The aforementioned commit only increases the chances of the assertion
> and allows triggering the assertion with the reproducer using overlayfs,
> inotify and drop_caches.
>
> Triggering this assertion was always possible with other filesystems and
> other reasons of ->encode_fh() failures and more particularly, it was
> also possible with the exact same reproducer using overlayfs that is
> mounted with options index=on,nfs_export=on also on kernels < v6.6.
> Therefore, I am not listing the aforementioned commit as a Fixes commit.
>
> Backport hint: this patch will have a trivial conflict applying to
> v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
>
> Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> Reported-by: Dmitry Safonov <dima@arista.com>
> Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> Signed-off-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match the destination code.
> - Removed the warning message as per the patch.
>
> Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
> Tested-by: Ömer Erdinç Yağmurlu <oeygmrl@amazon.de>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>

> ---
>  fs/notify/fdinfo.c     | 4 +---
>  fs/overlayfs/copy_up.c | 5 ++---
>  2 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
> index 55081ae3a6ec0..dd5bc6ffae858 100644
> --- a/fs/notify/fdinfo.c
> +++ b/fs/notify/fdinfo.c
> @@ -51,10 +51,8 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
>         size = f.handle.handle_bytes >> 2;
>
>         ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, &size, NULL);
> -       if ((ret == FILEID_INVALID) || (ret < 0)) {
> -               WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
> +       if ((ret == FILEID_INVALID) || (ret < 0))
>                 return;
> -       }
>
>         f.handle.handle_type = ret;
>         f.handle.handle_bytes = size * sizeof(u32);
> diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> index 203b88293f6bb..ced56696beeb3 100644
> --- a/fs/overlayfs/copy_up.c
> +++ b/fs/overlayfs/copy_up.c
> @@ -361,9 +361,8 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
>         buflen = (dwords << 2);
>
>         err = -EIO;
> -       if (WARN_ON(fh_type < 0) ||
> -           WARN_ON(buflen > MAX_HANDLE_SZ) ||
> -           WARN_ON(fh_type == FILEID_INVALID))
> +       if (fh_type < 0 || fh_type == FILEID_INVALID ||
> +           WARN_ON(buflen > MAX_HANDLE_SZ))
>                 goto out_err;
>
>         fh->fb.version = OVL_FH_VERSION;
> --
> 2.34.1
>
>
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[Greg Kroah-Hartman]

On Mon, Sep 01, 2025 at 03:35:59PM +0000, Norbert Manthey wrote:
> From: Amir Goldstein <amir73il@gmail.com>
> 
> commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
> 
> Encoding file handles is usually performed by a filesystem >encode_fh()
> method that may fail for various reasons.
> 
> The legacy users of exportfs_encode_fh(), namely, nfsd and
> name_to_handle_at(2) syscall are ready to cope with the possibility
> of failure to encode a file handle.
> 
> There are a few other users of exportfs_encode_{fh,fid}() that
> currently have a WARN_ON() assertion when ->encode_fh() fails.
> Relax those assertions because they are wrong.
> 
> The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> encoding non-decodable file handles") in v6.6 as the regressing commit,
> but this is not accurate.
> 
> The aforementioned commit only increases the chances of the assertion
> and allows triggering the assertion with the reproducer using overlayfs,
> inotify and drop_caches.
> 
> Triggering this assertion was always possible with other filesystems and
> other reasons of ->encode_fh() failures and more particularly, it was
> also possible with the exact same reproducer using overlayfs that is
> mounted with options index=on,nfs_export=on also on kernels < v6.6.
> Therefore, I am not listing the aforementioned commit as a Fixes commit.
> 
> Backport hint: this patch will have a trivial conflict applying to
> v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> 
> Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> Reported-by: Dmitry Safonov <dima@arista.com>
> Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> Signed-off-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I never signed off on the original commit, so why was this added?

> 
> (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match the destination code.
> - Removed the warning message as per the patch.

Please put this in the proper place, and in the proper format, if you
want to add "notes" to the backport.

But really, it took a LLM to determine an abi change?  That feels like
total overkill as you then had to actually manually check it as well.
But hey, it's your cpu cycles to burn, not mine...

> Signed-off-by: Norbert Manthey <nmanthey@amazon.de>
> Tested-by: Ömer Erdinç Yağmurlu <oeygmrl@amazon.de>

Your signed-off-by has to come last, right?

thanks,

greg k-h

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[Greg Kroah-Hartman]

On Mon, Sep 01, 2025 at 09:54:03PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Sep 01, 2025 at 03:35:59PM +0000, Norbert Manthey wrote:
> > From: Amir Goldstein <amir73il@gmail.com>
> > 
> > commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
> > 
> > Encoding file handles is usually performed by a filesystem >encode_fh()
> > method that may fail for various reasons.
> > 
> > The legacy users of exportfs_encode_fh(), namely, nfsd and
> > name_to_handle_at(2) syscall are ready to cope with the possibility
> > of failure to encode a file handle.
> > 
> > There are a few other users of exportfs_encode_{fh,fid}() that
> > currently have a WARN_ON() assertion when ->encode_fh() fails.
> > Relax those assertions because they are wrong.
> > 
> > The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> > encoding non-decodable file handles") in v6.6 as the regressing commit,
> > but this is not accurate.
> > 
> > The aforementioned commit only increases the chances of the assertion
> > and allows triggering the assertion with the reproducer using overlayfs,
> > inotify and drop_caches.
> > 
> > Triggering this assertion was always possible with other filesystems and
> > other reasons of ->encode_fh() failures and more particularly, it was
> > also possible with the exact same reproducer using overlayfs that is
> > mounted with options index=on,nfs_export=on also on kernels < v6.6.
> > Therefore, I am not listing the aforementioned commit as a Fixes commit.
> > 
> > Backport hint: this patch will have a trivial conflict applying to
> > v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> > 
> > Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> > Reported-by: Dmitry Safonov <dima@arista.com>
> > Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> I never signed off on the original commit, so why was this added?
> 
> > 
> > (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> > Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> > - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match the destination code.

Wait, that was just fuzz matching, the real body didn't even change.

> > - Removed the warning message as per the patch.

I do not understand this change, what exactly was this?

> Please put this in the proper place, and in the proper format, if you
> want to add "notes" to the backport.
> 
> But really, it took a LLM to determine an abi change?  That feels like
> total overkill as you then had to actually manually check it as well.
> But hey, it's your cpu cycles to burn, not mine...

Again, total overkill, 1 minute doing a simple git merge resolution
would have done the same thing, right?

confused as to why this took a whole new tool?  We have good merge
resolution tools for git these days, what's wrong with using one of the
many ones out there?

thanks,

greg k-h

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[Manthey, Norbert]

On Mon, 2025-09-01 at 22:00 +0200, Greg Kroah-Hartman wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On Mon, Sep 01, 2025 at 09:54:03PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Sep 01, 2025 at 03:35:59PM +0000, Norbert Manthey wrote:
> > > From: Amir Goldstein <amir73il@gmail.com>
> > > 
> > > commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
> > > 
> > > Encoding file handles is usually performed by a filesystem >encode_fh()
> > > method that may fail for various reasons.
> > > 
> > > The legacy users of exportfs_encode_fh(), namely, nfsd and
> > > name_to_handle_at(2) syscall are ready to cope with the possibility
> > > of failure to encode a file handle.
> > > 
> > > There are a few other users of exportfs_encode_{fh,fid}() that
> > > currently have a WARN_ON() assertion when ->encode_fh() fails.
> > > Relax those assertions because they are wrong.
> > > 
> > > The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> > > encoding non-decodable file handles") in v6.6 as the regressing commit,
> > > but this is not accurate.
> > > 
> > > The aforementioned commit only increases the chances of the assertion
> > > and allows triggering the assertion with the reproducer using overlayfs,
> > > inotify and drop_caches.
> > > 
> > > Triggering this assertion was always possible with other filesystems and
> > > other reasons of ->encode_fh() failures and more particularly, it was
> > > also possible with the exact same reproducer using overlayfs that is
> > > mounted with options index=on,nfs_export=on also on kernels < v6.6.
> > > Therefore, I am not listing the aforementioned commit as a Fixes commit.
> > > 
> > > Backport hint: this patch will have a trivial conflict applying to
> > > v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> > > 
> > > Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> > > Reported-by: Dmitry Safonov <dima@arista.com>
> > > Closes: https://lore.kernel.org/linux-
> > > fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > I never signed off on the original commit, so why was this added?

This cherry-pick is not for the upstream commit, but for the backport on the 6.6 tree. The
respective commit hash is given in the backport line. Is this additional information you would like
to have in the commit message?

> > 
> > > 
> > > (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> > > Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> > > - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match
> > > the destination code.
> 
> Wait, that was just fuzz matching, the real body didn't even change.
> 
> > > - Removed the warning message as per the patch.
> 
> I do not understand this change, what exactly was this?

I need to rewrite (here: drop) this manually. The LLM was also describing the content of the
original patch, not only the diff it created. 

> 
> > Please put this in the proper place, and in the proper format, if you
> > want to add "notes" to the backport.

IIUC, the changes applied to the patch so that it applies should come above my SOB, no? What's the
format requirement (except the 80-100 char limit)?

I am aware of the discussions about AI generated code. I wanted to explicitly mention the AI use, if
it was used as backporting helper. Do you suggest to still move this into the notes section of the
commit and sent patch, instead of having this in the commit itself?

> > 
> > But really, it took a LLM to determine an abi change?  That feels like
> > total overkill as you then had to actually manually check it as well.
> > But hey, it's your cpu cycles to burn, not mine...

I prefer reviewing the code instead of writing/massaging all of it, and on success have the change
tested/validated automatically before I reviewing.

> 
> 
> Again, total overkill, 1 minute doing a simple git merge resolution
> would have done the same thing, right?

For this example, yes, I agree. There are more complex commits where this works as well.

> 
> confused as to why this took a whole new tool?  We have good merge
> resolution tools for git these days, what's wrong with using one of the
> many ones out there?

There is nothing wrong using any other tool. The git-llm-pick tool allows to automatically backport
more commits and supports user specified validation for the changes. The LLM is only the last
attempt. A human needs to review the output either way, and eventually do the
backport interactively.

Best,
Norbert

> 
> thanks,
> 
> greg k-h





Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[Amir Goldstein]

On Tue, Sep 2, 2025 at 9:20 AM Manthey, Norbert <nmanthey@amazon.de> wrote:
>
> On Mon, 2025-09-01 at 22:00 +0200, Greg Kroah-Hartman wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open
> > attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > On Mon, Sep 01, 2025 at 09:54:03PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 01, 2025 at 03:35:59PM +0000, Norbert Manthey wrote:
> > > > From: Amir Goldstein <amir73il@gmail.com>
> > > >
> > > > commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
> > > >
> > > > Encoding file handles is usually performed by a filesystem >encode_fh()
> > > > method that may fail for various reasons.
> > > >
> > > > The legacy users of exportfs_encode_fh(), namely, nfsd and
> > > > name_to_handle_at(2) syscall are ready to cope with the possibility
> > > > of failure to encode a file handle.
> > > >
> > > > There are a few other users of exportfs_encode_{fh,fid}() that
> > > > currently have a WARN_ON() assertion when ->encode_fh() fails.
> > > > Relax those assertions because they are wrong.
> > > >
> > > > The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> > > > encoding non-decodable file handles") in v6.6 as the regressing commit,
> > > > but this is not accurate.
> > > >
> > > > The aforementioned commit only increases the chances of the assertion
> > > > and allows triggering the assertion with the reproducer using overlayfs,
> > > > inotify and drop_caches.
> > > >
> > > > Triggering this assertion was always possible with other filesystems and
> > > > other reasons of ->encode_fh() failures and more particularly, it was
> > > > also possible with the exact same reproducer using overlayfs that is
> > > > mounted with options index=on,nfs_export=on also on kernels < v6.6.
> > > > Therefore, I am not listing the aforementioned commit as a Fixes commit.
> > > >
> > > > Backport hint: this patch will have a trivial conflict applying to
> > > > v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> > > >
> > > > Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > > Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > > Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> > > > Reported-by: Dmitry Safonov <dima@arista.com>
> > > > Closes: https://lore.kernel.org/linux-
> > > > fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> > > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > I never signed off on the original commit, so why was this added?
>
> This cherry-pick is not for the upstream commit, but for the backport on the 6.6 tree. The
> respective commit hash is given in the backport line. Is this additional information you would like
> to have in the commit message?
>
> > >
> > > >
> > > > (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> > > > Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> > > > - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match
> > > > the destination code.
> >
> > Wait, that was just fuzz matching, the real body didn't even change.
> >
> > > > - Removed the warning message as per the patch.
> >
> > I do not understand this change, what exactly was this?
>
> I need to rewrite (here: drop) this manually. The LLM was also describing the content of the
> original patch, not only the diff it created.
>
> >
> > > Please put this in the proper place, and in the proper format, if you
> > > want to add "notes" to the backport.
>
> IIUC, the changes applied to the patch so that it applies should come above my SOB, no? What's the
> format requirement (except the 80-100 char limit)?
>
> I am aware of the discussions about AI generated code. I wanted to explicitly mention the AI use, if
> it was used as backporting helper. Do you suggest to still move this into the notes section of the
> commit and sent patch, instead of having this in the commit itself?
>
> > >
> > > But really, it took a LLM to determine an abi change?  That feels like
> > > total overkill as you then had to actually manually check it as well.
> > > But hey, it's your cpu cycles to burn, not mine...
>
> I prefer reviewing the code instead of writing/massaging all of it, and on success have the change
> tested/validated automatically before I reviewing.
>
> >
> >
> > Again, total overkill, 1 minute doing a simple git merge resolution
> > would have done the same thing, right?
>

1 minute is a lot of time when multiplied by the number of "almost
cleanly applied"
backports ;)

> For this example, yes, I agree. There are more complex commits where this works as well.
>
> >
> > confused as to why this took a whole new tool?  We have good merge
> > resolution tools for git these days, what's wrong with using one of the
> > many ones out there?
>
> There is nothing wrong using any other tool. The git-llm-pick tool allows to automatically backport
> more commits and supports user specified validation for the changes. The LLM is only the last
> attempt. A human needs to review the output either way, and eventually do the
> backport interactively.
>

First of all, this is not the first project that attempts to apply
"semantic" patches
that can deal with a lot more fuzz than git apply can. Long before the LLM buzz.

I personally find LLM to be quite useful for some of the more boring
of my tasks.
Translation and understanding semantics is what LLM does best, so deploying
it for stable backports could be very productive IMO, as long as the
result is tested
reviewed and signed off by a human developer who understands what the patch
is doing.

Thanks,
Amir.

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[gregkh]

On Tue, Sep 02, 2025 at 09:29:50AM +0200, Amir Goldstein wrote:
> On Tue, Sep 2, 2025 at 9:20 AM Manthey, Norbert <nmanthey@amazon.de> wrote:
> >
> > On Mon, 2025-09-01 at 22:00 +0200, Greg Kroah-Hartman wrote:
> > > CAUTION: This email originated from outside of the organization. Do not click links or open
> > > attachments unless you can confirm the sender and know the content is safe.
> > >
> > >
> > >
> > > On Mon, Sep 01, 2025 at 09:54:03PM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Sep 01, 2025 at 03:35:59PM +0000, Norbert Manthey wrote:
> > > > > From: Amir Goldstein <amir73il@gmail.com>
> > > > >
> > > > > commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
> > > > >
> > > > > Encoding file handles is usually performed by a filesystem >encode_fh()
> > > > > method that may fail for various reasons.
> > > > >
> > > > > The legacy users of exportfs_encode_fh(), namely, nfsd and
> > > > > name_to_handle_at(2) syscall are ready to cope with the possibility
> > > > > of failure to encode a file handle.
> > > > >
> > > > > There are a few other users of exportfs_encode_{fh,fid}() that
> > > > > currently have a WARN_ON() assertion when ->encode_fh() fails.
> > > > > Relax those assertions because they are wrong.
> > > > >
> > > > > The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> > > > > encoding non-decodable file handles") in v6.6 as the regressing commit,
> > > > > but this is not accurate.
> > > > >
> > > > > The aforementioned commit only increases the chances of the assertion
> > > > > and allows triggering the assertion with the reproducer using overlayfs,
> > > > > inotify and drop_caches.
> > > > >
> > > > > Triggering this assertion was always possible with other filesystems and
> > > > > other reasons of ->encode_fh() failures and more particularly, it was
> > > > > also possible with the exact same reproducer using overlayfs that is
> > > > > mounted with options index=on,nfs_export=on also on kernels < v6.6.
> > > > > Therefore, I am not listing the aforementioned commit as a Fixes commit.
> > > > >
> > > > > Backport hint: this patch will have a trivial conflict applying to
> > > > > v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> > > > >
> > > > > Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > > > Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > > > Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> > > > > Reported-by: Dmitry Safonov <dima@arista.com>
> > > > > Closes: https://lore.kernel.org/linux-
> > > > > fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > > Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> > > > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > >
> > > > I never signed off on the original commit, so why was this added?
> >
> > This cherry-pick is not for the upstream commit, but for the backport on the 6.6 tree. The
> > respective commit hash is given in the backport line. Is this additional information you would like
> > to have in the commit message?
> >
> > > >
> > > > >
> > > > > (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> > > > > Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> > > > > - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match
> > > > > the destination code.
> > >
> > > Wait, that was just fuzz matching, the real body didn't even change.
> > >
> > > > > - Removed the warning message as per the patch.
> > >
> > > I do not understand this change, what exactly was this?
> >
> > I need to rewrite (here: drop) this manually. The LLM was also describing the content of the
> > original patch, not only the diff it created.
> >
> > >
> > > > Please put this in the proper place, and in the proper format, if you
> > > > want to add "notes" to the backport.
> >
> > IIUC, the changes applied to the patch so that it applies should come above my SOB, no? What's the
> > format requirement (except the 80-100 char limit)?
> >
> > I am aware of the discussions about AI generated code. I wanted to explicitly mention the AI use, if
> > it was used as backporting helper. Do you suggest to still move this into the notes section of the
> > commit and sent patch, instead of having this in the commit itself?
> >
> > > >
> > > > But really, it took a LLM to determine an abi change?  That feels like
> > > > total overkill as you then had to actually manually check it as well.
> > > > But hey, it's your cpu cycles to burn, not mine...
> >
> > I prefer reviewing the code instead of writing/massaging all of it, and on success have the change
> > tested/validated automatically before I reviewing.
> >
> > >
> > >
> > > Again, total overkill, 1 minute doing a simple git merge resolution
> > > would have done the same thing, right?
> >
> 
> 1 minute is a lot of time when multiplied by the number of "almost
> cleanly applied"
> backports ;)

In that 1 minute you will "know" you got it right.  Otherwise you will
have to spend more than 1 minute reviewing the result of an automated
too.

Again, your waste of cpu cycles and review cycles, not mine :)

have fun!

greg k-h

Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles

[gregkh]

On Tue, Sep 02, 2025 at 07:20:46AM +0000, Manthey, Norbert wrote:
> On Mon, 2025-09-01 at 22:00 +0200, Greg Kroah-Hartman wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open
> > attachments unless you can confirm the sender and know the content is safe.
> > 
> > 
> > 
> > On Mon, Sep 01, 2025 at 09:54:03PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Sep 01, 2025 at 03:35:59PM +0000, Norbert Manthey wrote:
> > > > From: Amir Goldstein <amir73il@gmail.com>
> > > > 
> > > > commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 upstream.
> > > > 
> > > > Encoding file handles is usually performed by a filesystem >encode_fh()
> > > > method that may fail for various reasons.
> > > > 
> > > > The legacy users of exportfs_encode_fh(), namely, nfsd and
> > > > name_to_handle_at(2) syscall are ready to cope with the possibility
> > > > of failure to encode a file handle.
> > > > 
> > > > There are a few other users of exportfs_encode_{fh,fid}() that
> > > > currently have a WARN_ON() assertion when ->encode_fh() fails.
> > > > Relax those assertions because they are wrong.
> > > > 
> > > > The second linked bug report states commit 16aac5ad1fa9 ("ovl: support
> > > > encoding non-decodable file handles") in v6.6 as the regressing commit,
> > > > but this is not accurate.
> > > > 
> > > > The aforementioned commit only increases the chances of the assertion
> > > > and allows triggering the assertion with the reproducer using overlayfs,
> > > > inotify and drop_caches.
> > > > 
> > > > Triggering this assertion was always possible with other filesystems and
> > > > other reasons of ->encode_fh() failures and more particularly, it was
> > > > also possible with the exact same reproducer using overlayfs that is
> > > > mounted with options index=on,nfs_export=on also on kernels < v6.6.
> > > > Therefore, I am not listing the aforementioned commit as a Fixes commit.
> > > > 
> > > > Backport hint: this patch will have a trivial conflict applying to
> > > > v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> > > > 
> > > > Reported-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > > Tested-by: syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com
> > > > Closes: https://lore.kernel.org/linux-unionfs/671fd40c.050a0220.4735a.024f.GAE@google.com/
> > > > Reported-by: Dmitry Safonov <dima@arista.com>
> > > > Closes: https://lore.kernel.org/linux-
> > > > fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F+Juqy_o6oP8uw@mail.gmail.com/
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > Link: https://lore.kernel.org/r/20241219115301.465396-1-amir73il@gmail.com
> > > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > 
> > > I never signed off on the original commit, so why was this added?
> 
> This cherry-pick is not for the upstream commit, but for the backport on the 6.6 tree. The
> respective commit hash is given in the backport line. Is this additional information you would like
> to have in the commit message?

You should be backporting the original commit (which is what you said
you did), and for that use the original signed-off-by lines.  Otherwise
adding mine here seems very odd as there is no "hint" anywhere that this
is what happened.




> 
> > > 
> > > > 
> > > > (fuzzy picked from commit f47c834a9131ae64bee3c462f4e610c67b0a000f)
> > > > Applied with LLM-adjusted hunks for 1 functions from us.amazon.nova
> > > > - Changed the function call from `exportfs_encode_fid` to `exportfs_encode_inode_fh` to match
> > > > the destination code.
> > 
> > Wait, that was just fuzz matching, the real body didn't even change.
> > 
> > > > - Removed the warning message as per the patch.
> > 
> > I do not understand this change, what exactly was this?
> 
> I need to rewrite (here: drop) this manually. The LLM was also describing the content of the
> original patch, not only the diff it created. 

I still do not understand, sorry.  What exactly should I do with this?

> > > Please put this in the proper place, and in the proper format, if you
> > > want to add "notes" to the backport.
> 
> IIUC, the changes applied to the patch so that it applies should come above my SOB, no? What's the
> format requirement (except the 80-100 char limit)?

See the many backported patches that have comments in the signed-off-by
area for where changes were made.  We have thousands of examples in the
tree and email archives today.

> I am aware of the discussions about AI generated code. I wanted to explicitly mention the AI use, if
> it was used as backporting helper. Do you suggest to still move this into the notes section of the
> commit and sent patch, instead of having this in the commit itself?

I have no objection for it being in the commit itself, just put it in a
way we can follow and that follows the ways others have done so in the
past.

And make it something that is useful.  That line up above about fuzz
makes no sense.

> > > But really, it took a LLM to determine an abi change?  That feels like
> > > total overkill as you then had to actually manually check it as well.
> > > But hey, it's your cpu cycles to burn, not mine...
> 
> I prefer reviewing the code instead of writing/massaging all of it, and on success have the change
> tested/validated automatically before I reviewing.

Sure, you do you :)

> > Again, total overkill, 1 minute doing a simple git merge resolution
> > would have done the same thing, right?
> 
> For this example, yes, I agree. There are more complex commits where this works as well.

Doing complex things for simple examples seems odd, I suggest you pick a
more complex example to show how it actually works well :)

> > confused as to why this took a whole new tool?  We have good merge
> > resolution tools for git these days, what's wrong with using one of the
> > many ones out there?
> 
> There is nothing wrong using any other tool. The git-llm-pick tool allows to automatically backport
> more commits and supports user specified validation for the changes. The LLM is only the last
> attempt. A human needs to review the output either way, and eventually do the
> backport interactively.

Yes they do, and hopefully you will actually measure your productivity
here to see if the LLM is helping you do more work or not :)

thanks,

greg k-h

Re: [PATCH 6.1.y 0/1] Backporting patches with git-llm-pick

[Sasha Levin]

On Mon, Sep 01, 2025 at 03:35:58PM +0000, Norbert Manthey wrote:
>Dear all,
>
>we looked into improving commit backporting workflows. This specific commit in
>this series caught our attention, as it states that backporting will not be
>trivial. The commit message has this part:
>
>Backport hint: this patch will have a trivial conflict applying to
>v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
>
>We want to automate backporting commits with a similar property. Therefore, we
>build a tool git-llm-pick that simplifies the backporting commit. After
>cherry-picking, we try to automatically detect dependency-commits. In case of
>failure, we then try to use the patch tool. If this process fails, we then take
>the rejected patch files, and feed their content with other context and a task
>description to backport to an LLM. The resulting code modification is then
>applied. In case validation is passed, a commit is created. The commit message
>is always extended by a description of the adapted code change, and with which
>technique a commit was applied.

Very nice!

I have a similar workflow, but it does a slightly different thing. My main
issue with having LLM just fix up conflicts and commit them is that it becomes
really hard to understand what the LLM actually did.

If you look at the generated commit text in your example message, it states
"Removed the warning message as per the patch" which is really confusing: does
this refer to something that the LLM changed? Is this different from what the
original commit was trying to do? Why is this explicitly called out?

The way I do it on my end, is that I create a "merge triangle" which contains:

  - The original commit, as is
  - The fixup
  - An explanation to the fixup

So using this commit as an example, it would generate:

$ git log --oneline --graph -5
*   5d59fa7c4b981 (HEAD) Explanation
|\  
| * 46beb491ffff2 fs/notify: fix merge conflict in fdinfo.c
| * b5031eb894d34 fs: relax assertions on failure to encode file handles
|/  
* f89b6e15694c1 (tag: v6.1.149, stable/linux-6.1.y) Linux 6.1.149
* 46643021596a6 alloc_fdtable(): change calling conventions.

Which gives me "atomic" git units to work with, but still allowing for easy review.

The original patch will be committed with the merge conflict:

diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 55081ae3a6ec0..22adbf533855b 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -50,11 +50,15 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
         f.handle.handle_bytes = sizeof(f.pad);
         size = f.handle.handle_bytes >> 2;
  
+<<<<<<< HEAD
         ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, &size, NULL);
         if ((ret == FILEID_INVALID) || (ret < 0)) {
                 WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
+=======
+       ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size);
+       if ((ret == FILEID_INVALID) || (ret < 0))
+>>>>>>> 974e3fe0ac61d (fs: relax assertions on failure to encode file handles)
                 return;
-       }
  
         f.handle.handle_type = ret;
         f.handle.handle_bytes = size * sizeof(u32);

And then the following commit will address that:

diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 22adbf533855b..dd5bc6ffae858 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -50,14 +50,8 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
         f.handle.handle_bytes = sizeof(f.pad);
         size = f.handle.handle_bytes >> 2;
  
-<<<<<<< HEAD
         ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, &size, NULL);
-       if ((ret == FILEID_INVALID) || (ret < 0)) {
-               WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
-=======
-       ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size);
         if ((ret == FILEID_INVALID) || (ret < 0))
->>>>>>> 974e3fe0ac61d (fs: relax assertions on failure to encode file handles)
                 return;
  
         f.handle.handle_type = ret;

In this way, it's easy for me to see what exactly the LLM changed, making for
way easier review of "fuzzy" backports.

And finally, the merge commit will contain a longer LLM generated explanation
that I can also validate. This way, I validate two things: the actual code
change, and the LLM's reasoning. If both are sane, then it helps be build trust
in the backport. Here's the explanation for this commit:

commit 5d59fa7c4b981ec18ac730b4d8629ec33619de6f (HEAD)
Merge: f89b6e15694c1 46beb491ffff2
Author: Sasha Levin <sashal@kernel.org>
Date:   Tue Sep 2 07:28:10 2025 -0400

     Explanation
     
     The Problem
     
     The HEAD commit (b5031eb894d3) contained an improperly resolved merge conflict
     in fs/notify/fdinfo.c.
     
     The conflict markers showed:
     
     - HEAD version: Used exportfs_encode_inode_fh() with a WARN_ONCE() assertion
     - Incoming change: Incorrectly used exportfs_encode_fid() (non-existent
       function) with wrong syntax
     
     The Resolution
     
     I fixed it by:
     
     1. Keeping the correct function: exportfs_encode_inode_fh() (not the
     non-existent exportfs_encode_fid())
     2. Removing the WARN_ONCE assertion: As intended by the original commit to
     "relax assertions"
     3. Preserving correct syntax: Using f.handle.f_handle (not f->f_handle)
     
     Why This is Correct
     
     The original commit's purpose was to relax assertions when file handle encoding
     fails, because these assertions were incorrect and could trigger in valid
     scenarios.
     
     The fix:
     
     - Removes the problematic WARN_ONCE() that could trigger incorrectly
     - Keeps the proper API function that actually exists in the kernel
     - Maintains clean error handling without warnings for legitimate failures
     
     The code now silently returns on encoding failures instead of triggering
     warnings, which aligns with the commit's stated goal of relaxing assertions for
     file handle encoding failures

At this point in my workflow, I can just squash the fix into the original
commit and decorate the new resulting commit as needed for -stable.

>We made the tool available on github: https://github.com/awslabs/Git_llm_pick/
>We currently use LLMs via the AWS Bedrock service, and default to the Nova Pro
>model. The patch in this series uses the vanilla version of the tool's current
>output when running git-llm-pick in its virtual test environment:

One note about the tool: in my experience, unless the tool can also act as an
agent and investigate the relevant git repo (and attempt builds and run tests)
on it's own, the results used to be very lackluster.

Without agentic access to more context/tooling, the LLM was guessing way too
much :)

-- 
Thanks,
Sasha

Re: [PATCH 6.1.y 0/1] Backporting patches with git-llm-pick

[Manthey, Norbert]

On Tue, 2025-09-02 at 07:48 -0400, Sasha Levin wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On Mon, Sep 01, 2025 at 03:35:58PM +0000, Norbert Manthey wrote:
> > Dear all,
> > 
> > we looked into improving commit backporting workflows. This specific commit in
> > this series caught our attention, as it states that backporting will not be
> > trivial. The commit message has this part:
> > 
> > Backport hint: this patch will have a trivial conflict applying to
> > v6.6.y, and other trivial conflicts applying to stable kernels < v6.6.
> > 
> > We want to automate backporting commits with a similar property. Therefore, we
> > build a tool git-llm-pick that simplifies the backporting commit. After
> > cherry-picking, we try to automatically detect dependency-commits. In case of
> > failure, we then try to use the patch tool. If this process fails, we then take
> > the rejected patch files, and feed their content with other context and a task
> > description to backport to an LLM. The resulting code modification is then
> > applied. In case validation is passed, a commit is created. The commit message
> > is always extended by a description of the adapted code change, and with which
> > technique a commit was applied.
> 
> Very nice!

Thanks.

> 
> I have a similar workflow, but it does a slightly different thing. My main
> issue with having LLM just fix up conflicts and commit them is that it becomes
> really hard to understand what the LLM actually did.
> 
> If you look at the generated commit text in your example message, it states
> "Removed the warning message as per the patch" which is really confusing: does
> this refer to something that the LLM changed? Is this different from what the
> original commit was trying to do? Why is this explicitly called out?

Yes, this part needs an iteration on our side. We need to at least diff the two
versions of the backport, and get the explanation for that difference.

> 
> The way I do it on my end, is that I create a "merge triangle" which contains:
> 
>   - The original commit, as is
>   - The fixup
>   - An explanation to the fixup

Thanks for sharing. We are thinking about extending the tool with another stage
to use agents. While that might work for us, other users might have access to
LLMs directly only. To get feedback early, we started there.

> 
> So using this commit as an example, it would generate:
> 
> $ git log --oneline --graph -5
> *   5d59fa7c4b981 (HEAD) Explanation
> > \
> > * 46beb491ffff2 fs/notify: fix merge conflict in fdinfo.c
> > * b5031eb894d34 fs: relax assertions on failure to encode file handles
> > /
> * f89b6e15694c1 (tag: v6.1.149, stable/linux-6.1.y) Linux 6.1.149
> * 46643021596a6 alloc_fdtable(): change calling conventions.
> 
> Which gives me "atomic" git units to work with, but still allowing for easy review.
> 
> The original patch will be committed with the merge conflict:
> 
> diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
> index 55081ae3a6ec0..22adbf533855b 100644
> --- a/fs/notify/fdinfo.c
> +++ b/fs/notify/fdinfo.c
> @@ -50,11 +50,15 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
>          f.handle.handle_bytes = sizeof(f.pad);
>          size = f.handle.handle_bytes >> 2;
> 
> +<<<<<<< HEAD
>          ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, &size, NULL);
>          if ((ret == FILEID_INVALID) || (ret < 0)) {
>                  WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
> +=======
> +       ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size);
> +       if ((ret == FILEID_INVALID) || (ret < 0))
> +>>>>>>> 974e3fe0ac61d (fs: relax assertions on failure to encode file handles)
>                  return;
> -       }
> 
>          f.handle.handle_type = ret;
>          f.handle.handle_bytes = size * sizeof(u32);
> 
> And then the following commit will address that:
> 
> diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
> index 22adbf533855b..dd5bc6ffae858 100644
> --- a/fs/notify/fdinfo.c
> +++ b/fs/notify/fdinfo.c
> @@ -50,14 +50,8 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode)
>          f.handle.handle_bytes = sizeof(f.pad);
>          size = f.handle.handle_bytes >> 2;
> 
> -<<<<<<< HEAD
>          ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle, &size, NULL);
> -       if ((ret == FILEID_INVALID) || (ret < 0)) {
> -               WARN_ONCE(1, "Can't encode file handler for inotify: %d\n", ret);
> -=======
> -       ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size);
>          if ((ret == FILEID_INVALID) || (ret < 0))
> ->>>>>>> 974e3fe0ac61d (fs: relax assertions on failure to encode file handles)
>                  return;
> 
>          f.handle.handle_type = ret;
> 
> In this way, it's easy for me to see what exactly the LLM changed, making for
> way easier review of "fuzzy" backports.
> 
> And finally, the merge commit will contain a longer LLM generated explanation
> that I can also validate. This way, I validate two things: the actual code
> change, and the LLM's reasoning. If both are sane, then it helps be build trust
> in the backport. Here's the explanation for this commit:
> 
> commit 5d59fa7c4b981ec18ac730b4d8629ec33619de6f (HEAD)
> Merge: f89b6e15694c1 46beb491ffff2
> Author: Sasha Levin <sashal@kernel.org>
> Date:   Tue Sep 2 07:28:10 2025 -0400
> 
>      Explanation
> 
>      The Problem
> 
>      The HEAD commit (b5031eb894d3) contained an improperly resolved merge conflict
>      in fs/notify/fdinfo.c.
> 
>      The conflict markers showed:
> 
>      - HEAD version: Used exportfs_encode_inode_fh() with a WARN_ONCE() assertion
>      - Incoming change: Incorrectly used exportfs_encode_fid() (non-existent
>        function) with wrong syntax
> 
>      The Resolution
> 
>      I fixed it by:
> 
>      1. Keeping the correct function: exportfs_encode_inode_fh() (not the
>      non-existent exportfs_encode_fid())
>      2. Removing the WARN_ONCE assertion: As intended by the original commit to
>      "relax assertions"
>      3. Preserving correct syntax: Using f.handle.f_handle (not f->f_handle)
> 
>      Why This is Correct
> 
>      The original commit's purpose was to relax assertions when file handle encoding
>      fails, because these assertions were incorrect and could trigger in valid
>      scenarios.
> 
>      The fix:
> 
>      - Removes the problematic WARN_ONCE() that could trigger incorrectly
>      - Keeps the proper API function that actually exists in the kernel
>      - Maintains clean error handling without warnings for legitimate failures
> 
>      The code now silently returns on encoding failures instead of triggering
>      warnings, which aligns with the commit's stated goal of relaxing assertions for
>      file handle encoding failures
> 
> At this point in my workflow, I can just squash the fix into the original
> commit and decorate the new resulting commit as needed for -stable.
> 
> > We made the tool available on github: https://github.com/awslabs/Git_llm_pick/
> > We currently use LLMs via the AWS Bedrock service, and default to the Nova Pro
> > model. The patch in this series uses the vanilla version of the tool's current
> > output when running git-llm-pick in its virtual test environment:
> 
> One note about the tool: in my experience, unless the tool can also act as an
> agent and investigate the relevant git repo (and attempt builds and run tests)
> on it's own, the results used to be very lackluster.

I agree in general. On the other hand, we want to keep the amount of work done by
the LLM or agent small. For now, we only submit a bit of context and the commit
messages. The validation is executed by the application independently of the
agent. There is no feedback loop yet, or similar -- that could all be done in the
agent-stage. We have a few more filters and limits to only process commits that
are likely to be finished successfully by an LLM.

Best,
Norbert

> 
> Without agentic access to more context/tooling, the LLM was guessing way too
> much :)
> 
> --
> Thanks,
> Sasha




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Re: [PATCH 6.1.y 0/1] Backporting patches with git-llm-pick

[Sasha Levin]

On Tue, Sep 02, 2025 at 04:22:40PM +0000, Manthey, Norbert wrote:
>On Tue, 2025-09-02 at 07:48 -0400, Sasha Levin wrote:
>> One note about the tool: in my experience, unless the tool can also act as an
>> agent and investigate the relevant git repo (and attempt builds and run tests)
>> on it's own, the results used to be very lackluster.
>
>I agree in general. On the other hand, we want to keep the amount of work done by
>the LLM or agent small. For now, we only submit a bit of context and the commit
>messages. The validation is executed by the application independently of the
>agent. There is no feedback loop yet, or similar -- that could all be done in the
>agent-stage. We have a few more filters and limits to only process commits that
>are likely to be finished successfully by an LLM.

Consider a simple backport example: let's say that upstream we see a patch that
does something like:

   mutex_lock(&m);
- old_func();
+ new_func();
   mutex_unlock(&m);

But when we look at an older tree, we see:

   spin_lock(&l);
   old_func();
   spin_unlock(&l);

If you don't pass massive amounts of context in, there's no way for an LLM to
know if it's safe to simply replace old_func() with new_func() in the old code.
Most LLMs I played with will just go ahead and do that.

A human backporter (and most likely, an AI agent) would have a lightbulb moment
where they go look at new_func() to see if it's safe to be called under a
spinlock.

I guess that my point is that at this level for this usecase, LLMs don't end up
being much better than using something like wiggle[1].


[1] https://github.com/neilbrown/wiggle

-- 
Thanks,
Sasha