From: Amir Goldstein <amir73il@gmail.com>
To: trondmy@kernel.org
Cc: Chuck Lever <chuck.lever@oracle.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] knfsd: fix the fallback implementation of the get_name export operation
Date: Fri, 29 Dec 2023 07:46:54 +0200 [thread overview]
Message-ID: <CAOQ4uxiCf=FWtZWw2uLRmfPvgSxsnmqZC6A+FQgQs=MBQwA30w@mail.gmail.com> (raw)
In-Reply-To: <20231228201510.985235-1-trondmy@kernel.org>
[CC: fsdevel, viro]
On Thu, Dec 28, 2023 at 10:22 PM <trondmy@kernel.org> wrote:
>
> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>
> The fallback implementation for the get_name export operation uses
> readdir() to try to match the inode number to a filename. That filename
> is then used together with lookup_one() to produce a dentry.
> A problem arises when we match the '.' or '..' entries, since that
> causes lookup_one() to fail. This has sometimes been seen to occur for
> filesystems that violate POSIX requirements around uniqueness of inode
> numbers, something that is common for snapshot directories.
Ouch. Nasty.
Looks to me like the root cause is "filesystems that violate POSIX
requirements around uniqueness of inode numbers".
This violation can cause any of the parent's children to wrongly match
get_name() not only '.' and '..' and fail the d_inode sanity check after
lookup_one().
I understand why this would be common with parent of snapshot dir,
but the only fs that support snapshots that I know of (btrfs, bcachefs)
do implement ->get_name(), so which filesystem did you encounter
this behavior with? can it be fixed by implementing a snapshot
aware ->get_name()?
>
> This patch just ensures that we skip '.' and '..' rather than allowing a
> match.
I agree that skipping '.' and '..' makes sense, but...
>
> Fixes: 21d8a15ac333 ("lookup_one_len: don't accept . and ..")
...This Fixes is a bit odd to me.
Does the problem go away if the Fixes patch is reverted?
I don't think so, I think you would just hit the d_inode sanity check
after lookup_one() succeeds.
Maybe I did not understand the problem then.
> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> ---
> fs/exportfs/expfs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
> index 3ae0154c5680..84af58eaf2ca 100644
> --- a/fs/exportfs/expfs.c
> +++ b/fs/exportfs/expfs.c
> @@ -255,7 +255,9 @@ static bool filldir_one(struct dir_context *ctx, const char *name, int len,
> container_of(ctx, struct getdents_callback, ctx);
>
> buf->sequence++;
> - if (buf->ino == ino && len <= NAME_MAX) {
> + /* Ignore the '.' and '..' entries */
> + if ((len > 2 || name[0] != '.' || (len == 2 && name[1] != '.')) &&
I wish I did not have to review that this condition is correct.
I wish there was a common helper is_dot_or_dotdot() that would be
used here as !is_dot_dotdot(name, len).
I found 3 copies of is_dot_dotdot().
I didn't even try to find how many places have open coded this.
Thanks,
Amir.
next parent reply other threads:[~2023-12-29 5:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231228201510.985235-1-trondmy@kernel.org>
2023-12-29 5:46 ` Amir Goldstein [this message]
2023-12-29 14:34 ` [PATCH] knfsd: fix the fallback implementation of the get_name export operation Chuck Lever
2023-12-29 17:44 ` Amir Goldstein
2023-12-29 23:29 ` Chuck Lever
2023-12-29 23:49 ` Trond Myklebust
2023-12-30 6:23 ` Amir Goldstein
2023-12-30 19:36 ` Trond Myklebust
2023-12-31 10:44 ` Amir Goldstein
2023-12-29 15:21 ` Trond Myklebust
2023-12-29 17:54 ` Amir Goldstein
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='CAOQ4uxiCf=FWtZWw2uLRmfPvgSxsnmqZC6A+FQgQs=MBQwA30w@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=chuck.lever@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).