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