FAILED: patch "[PATCH] fs: relax assertions on failure to encode file handles" failed to apply to 6.1-stable tree
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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;
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(-)
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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;
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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
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@googl... 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
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@googl... 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.
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@googl... 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
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@googl... 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
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 :)
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
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
From: Amir Goldstein amir73il@gmail.com
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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 [ git-llm-picked from commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 ] Signed-off-by: Norbert Manthey nmanthey@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;
On Thu, Sep 04, 2025 at 09:21:38AM +0000, Norbert Manthey wrote:
From: Amir Goldstein amir73il@gmail.com
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@googl... Reported-by: Dmitry Safonov dima@arista.com Closes: https://lore.kernel.org/linux-fsdevel/CAGrbwDTLt6drB9eaUagnQVgdPBmhLfqqxAf3F... 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 [ git-llm-picked from commit 974e3fe0ac61de85015bbe5a4990cf4127b304b2 ]
Please don't make up new strings for a simple 'cherry-pick' line, as our tools don't know how to find this commit id :(
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Amir Goldstein -
Greg KH -
Greg Kroah-Hartman
-
gregkh＠linuxfoundation.org
-
Manthey, Norbert -
Norbert Manthey
-
Sasha Levin