All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Norbert Manthey <nmanthey@amazon.de>
Cc: stable@vger.kernel.org, "Amir Goldstein" <amir73il@gmail.com>,
	syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com,
	"Dmitry Safonov" <dima@arista.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Ömer Erdinç Yağmurlu" <oeygmrl@amazon.de>
Subject: Re: [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles
Date: Mon, 1 Sep 2025 21:54:03 +0200	[thread overview]
Message-ID: <2025090114-bodacious-daffodil-2f2e@gregkh> (raw)
In-Reply-To: <20250901153559.14799-2-nmanthey@amazon.de>

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

  parent reply	other threads:[~2025-09-01 19:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-11 16:19 FAILED: patch "[PATCH] fs: relax assertions on failure to encode file handles" failed to apply to 6.1-stable tree gregkh
2025-09-01 15:35 ` [PATCH 6.1.y 0/1] Backporting patches with git-llm-pick Norbert Manthey
2025-09-01 15:35   ` [PATCH 6.1.y 1/1] fs: relax assertions on failure to encode file handles Norbert Manthey
2025-09-01 15:51     ` Amir Goldstein
2025-09-01 19:54     ` Greg Kroah-Hartman [this message]
2025-09-01 20:00       ` Greg Kroah-Hartman
2025-09-02  7:20         ` Manthey, Norbert
2025-09-02  7:29           ` Amir Goldstein
2025-09-02  8:58             ` gregkh
2025-09-02  9:02           ` gregkh
2025-09-02 11:48   ` [PATCH 6.1.y 0/1] Backporting patches with git-llm-pick Sasha Levin
2025-09-02 16:22     ` Manthey, Norbert
2025-09-02 17:11       ` Sasha Levin
2025-09-04  9:21 ` [PATCH 6.1.y v2] fs: relax assertions on failure to encode file handles Norbert Manthey
2025-09-07  8:00   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2025090114-bodacious-daffodil-2f2e@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=dima@arista.com \
    --cc=nmanthey@amazon.de \
    --cc=oeygmrl@amazon.de \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+ec07f6f5ce62b858579f@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.