From: Paulo Alcantara <pc@manguebit.com>
To: Eduard Bachmakov <e.bachmakov@gmail.com>, linux-cifs@vger.kernel.org
Subject: Re: Unexpected additional umh-based DNS lookup in 6.6.0
Date: Thu, 09 Nov 2023 00:43:23 -0300 [thread overview]
Message-ID: <d2c0c53db617b6d2f9b71e734b165b4b.pc@manguebit.com> (raw)
In-Reply-To: <CADCRUiNvZuiUZ0VGZZO9HRyPyw6x92kiA7o7Q4tsX5FkZqUkKg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]
Eduard Bachmakov <e.bachmakov@gmail.com> writes:
> When attempting to mount (mount.cifs version 7.0) a share using
>
> $ mount -t cifs -o
> vers=3.1.1,cred=/home/u/.secret.txt,uid=1000,gid=100
> //smb.server.example.com/scans /home/u/mnt
>
> it succeeds on 6.5.9:
>
> mount("//smb.server.example.com/scans", ".", "cifs", 0,
> "ip=192.168.5.43,unc=\\\\smb.server.example.com\\scans,vers=3.1.1,uid=1000,gid=100,user=u,pass=mypassword")
> = 0
>
> but fails on 6.0.0:
>
> mount("//smb.server.example.com/scans", ".", "cifs", 0,
> "ip=192.168.5.43,unc=\\\\smb.server.example.com\\scans,vers=3.1.1,uid=1000,gid=100,user=u,pass=mypassword")
> = -1 ENOKEY (Required key not available)
>
> (or ENOENT) though it still works with using the IP instead of the domain:
>
> mount("//192.168.5.43/scans", ".", "cifs", 0,
> "ip=192.168.5.43,unc=\\\\192.168.5.43\\scans,vers=3.1.1,uid=1000,gid=100,user=u,pass=mypassword")
> = 0
>
> Based on my reading ever since 348a04a ("smb: client: get rid of dfs
> code dep in namespace.c") dfs_mount_share() is now calling
> dns_resolve_server_name_to_ip() early and unconditionally. This can be
> verified on a running system by enabling dns_resolver logging (echo 1
> | sudo tee /sys/module/dns_resolver/parameters/debug + watch dmesg).
> An additional DNS lookup is attempted in 6.0.0 that previously wasn't.
> My best guess is that ENOENT is "didn't work" and ENOKEY means "didn't
> work but cached".
Yes, this is a regression. Commit assumed that there would be always a
dns_resolver key set up on kernels built with CONFIG_CIFS_DFS_UPCALL=y
so that cifs.ko could safely upcall to resolve UNC hostname regardless
whether mounting a DFS share or a regular share.
Could you please try attached patch?
Thanks.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 2715 bytes --]
diff --git a/fs/smb/client/dfs.c b/fs/smb/client/dfs.c
index 81b84151450d..a8a1d386da65 100644
--- a/fs/smb/client/dfs.c
+++ b/fs/smb/client/dfs.c
@@ -263,15 +263,23 @@ static int __dfs_mount_share(struct cifs_mount_ctx *mnt_ctx)
return rc;
}
-/* Resolve UNC hostname in @ctx->source and set ip addr in @ctx->dstaddr */
+/*
+ * If @ctx->dfs_automount, then update @ctx->dstaddr earlier with the DFS root
+ * server from where we'll start following any referrals. Otherwise rely on the
+ * value provided by mount(2) as the user might not have dns_resolver key set up
+ * and therefore failing to upcall to resolve UNC hostname under @ctx->source.
+ */
static int update_fs_context_dstaddr(struct smb3_fs_context *ctx)
{
struct sockaddr *addr = (struct sockaddr *)&ctx->dstaddr;
- int rc;
+ int rc = 0;
- rc = dns_resolve_server_name_to_ip(ctx->source, addr, NULL);
- if (!rc)
- cifs_set_port(addr, ctx->port);
+ if (!ctx->nodfs && ctx->dfs_automount) {
+ rc = dns_resolve_server_name_to_ip(ctx->source, addr, NULL);
+ if (!rc)
+ cifs_set_port(addr, ctx->port);
+ ctx->dfs_automount = false;
+ }
return rc;
}
diff --git a/fs/smb/client/fs_context.h b/fs/smb/client/fs_context.h
index 9d8d34af0211..cf46916286d0 100644
--- a/fs/smb/client/fs_context.h
+++ b/fs/smb/client/fs_context.h
@@ -268,6 +268,7 @@ struct smb3_fs_context {
bool witness:1; /* use witness protocol */
char *leaf_fullpath;
struct cifs_ses *dfs_root_ses;
+ bool dfs_automount:1; /* set for dfs automount only */
};
extern const struct fs_parameter_spec smb3_fs_parameters[];
diff --git a/fs/smb/client/namespace.c b/fs/smb/client/namespace.c
index c8f5ed8a69f1..a6968573b775 100644
--- a/fs/smb/client/namespace.c
+++ b/fs/smb/client/namespace.c
@@ -117,6 +117,18 @@ cifs_build_devname(char *nodename, const char *prepath)
return dev;
}
+static bool is_dfs_mount(struct dentry *dentry)
+{
+ struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb);
+ struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb);
+ bool ret;
+
+ spin_lock(&tcon->tc_lock);
+ ret = !!tcon->origin_fullpath;
+ spin_unlock(&tcon->tc_lock);
+ return ret;
+}
+
/* Return full path out of a dentry set for automount */
static char *automount_fullpath(struct dentry *dentry, void *page)
{
@@ -212,8 +224,9 @@ static struct vfsmount *cifs_do_automount(struct path *path)
ctx->source = NULL;
goto out;
}
- cifs_dbg(FYI, "%s: ctx: source=%s UNC=%s prepath=%s\n",
- __func__, ctx->source, ctx->UNC, ctx->prepath);
+ ctx->dfs_automount = is_dfs_mount(mntpt);
+ cifs_dbg(FYI, "%s: ctx: source=%s UNC=%s prepath=%s dfs_automount=%d\n",
+ __func__, ctx->source, ctx->UNC, ctx->prepath, ctx->dfs_automount);
mnt = fc_mount(fc);
out:
next prev parent reply other threads:[~2023-11-09 3:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 21:23 Unexpected additional umh-based DNS lookup in 6.6.0 Eduard Bachmakov
2023-11-09 3:43 ` Paulo Alcantara [this message]
2023-11-09 9:55 ` Eduard Bachmakov
2023-11-09 17:29 ` Paulo Alcantara
2023-11-14 21:59 ` Eduard Bachmakov
2023-11-14 22:06 ` Steve French
2023-11-24 1:56 ` Paulo Alcantara
2023-11-24 11:53 ` Greg KH
2023-11-09 15:01 ` [PATCH] smb: client: fix mount when dns_resolver key is not available Paulo Alcantara
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=d2c0c53db617b6d2f9b71e734b165b4b.pc@manguebit.com \
--to=pc@manguebit.com \
--cc=e.bachmakov@gmail.com \
--cc=linux-cifs@vger.kernel.org \
/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.