From: Paulo Alcantara <pc@cjr.nz>
Cc: dhowells@redhat.com, Steve French <smfrench@gmail.com>,
linux-nfs <linux-nfs@vger.kernel.org>,
CIFS <linux-cifs@vger.kernel.org>,
linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org,
keyrings@vger.kernel.org,
Network Development <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
fweimer@redhat.com
Subject: Re: What's a good default TTL for DNS keys in the kernel
Date: Mon, 20 Apr 2020 18:21:23 +0000 [thread overview]
Message-ID: <878siq587w.fsf@cjr.nz> (raw)
In-Reply-To: <1136024.1587388420@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Paulo Alcantara <pc@cjr.nz> wrote:
>
>> >> For SMB3/CIFS mounts, Paulo added support last year for automatic
>> >> reconnect if the IP address of the server changes. It also is helpful
>> >> when DFS (global name space) addresses change.
>> >
>> > What happens if the IP address the superblock is going to changes, then
>> > another mount is made back to the original IP address? Does the second mount
>> > just pick the original superblock?
>>
>> It is going to transparently reconnect to the new ip address, SMB share,
>> and cifs superblock is kept unchanged. We, however, update internal
>> TCP_Server_Info structure to reflect new destination ip address.
>>
>> For the second mount, since the hostname (extracted out of the UNC path
>> at mount time) resolves to a new ip address and that address was saved earlier
>> in TCP_Server_Info structure during reconnect, we will end up
>> reusing same cifs superblock as per fs/cifs/connect.c:cifs_match_super().
>
> Would that be a bug?
Probably.
I'm not sure how that code is supposed to work, TBH.
WARNING: multiple messages have this Message-ID (diff)
From: Paulo Alcantara <pc@cjr.nz>
To: David Howells <dhowells@redhat.com>
Cc: dhowells@redhat.com, Steve French <smfrench@gmail.com>,
linux-nfs <linux-nfs@vger.kernel.org>,
CIFS <linux-cifs@vger.kernel.org>,
linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org,
keyrings@vger.kernel.org,
Network Development <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
fweimer@redhat.com
Subject: Re: What's a good default TTL for DNS keys in the kernel
Date: Mon, 20 Apr 2020 15:21:23 -0300 [thread overview]
Message-ID: <878siq587w.fsf@cjr.nz> (raw)
In-Reply-To: <1136024.1587388420@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Paulo Alcantara <pc@cjr.nz> wrote:
>
>> >> For SMB3/CIFS mounts, Paulo added support last year for automatic
>> >> reconnect if the IP address of the server changes. It also is helpful
>> >> when DFS (global name space) addresses change.
>> >
>> > What happens if the IP address the superblock is going to changes, then
>> > another mount is made back to the original IP address? Does the second mount
>> > just pick the original superblock?
>>
>> It is going to transparently reconnect to the new ip address, SMB share,
>> and cifs superblock is kept unchanged. We, however, update internal
>> TCP_Server_Info structure to reflect new destination ip address.
>>
>> For the second mount, since the hostname (extracted out of the UNC path
>> at mount time) resolves to a new ip address and that address was saved earlier
>> in TCP_Server_Info structure during reconnect, we will end up
>> reusing same cifs superblock as per fs/cifs/connect.c:cifs_match_super().
>
> Would that be a bug?
Probably.
I'm not sure how that code is supposed to work, TBH.
WARNING: multiple messages have this Message-ID (diff)
From: Paulo Alcantara <pc@cjr.nz>
Cc: dhowells@redhat.com, Steve French <smfrench@gmail.com>,
linux-nfs <linux-nfs@vger.kernel.org>,
CIFS <linux-cifs@vger.kernel.org>,
linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org,
keyrings@vger.kernel.org,
Network Development <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
fweimer@redhat.com
Subject: Re: What's a good default TTL for DNS keys in the kernel
Date: Mon, 20 Apr 2020 15:21:23 -0300 [thread overview]
Message-ID: <878siq587w.fsf@cjr.nz> (raw)
In-Reply-To: <1136024.1587388420@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Paulo Alcantara <pc@cjr.nz> wrote:
>
>> >> For SMB3/CIFS mounts, Paulo added support last year for automatic
>> >> reconnect if the IP address of the server changes. It also is helpful
>> >> when DFS (global name space) addresses change.
>> >
>> > What happens if the IP address the superblock is going to changes, then
>> > another mount is made back to the original IP address? Does the second mount
>> > just pick the original superblock?
>>
>> It is going to transparently reconnect to the new ip address, SMB share,
>> and cifs superblock is kept unchanged. We, however, update internal
>> TCP_Server_Info structure to reflect new destination ip address.
>>
>> For the second mount, since the hostname (extracted out of the UNC path
>> at mount time) resolves to a new ip address and that address was saved earlier
>> in TCP_Server_Info structure during reconnect, we will end up
>> reusing same cifs superblock as per fs/cifs/connect.c:cifs_match_super().
>
> Would that be a bug?
Probably.
I'm not sure how that code is supposed to work, TBH.
next prev parent reply other threads:[~2020-04-20 18:21 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 14:20 What's a good default TTL for DNS keys in the kernel David Howells
2020-04-14 14:20 ` David Howells
2020-04-14 14:20 ` David Howells
2020-04-14 20:16 ` Jeff Layton
2020-04-14 20:16 ` Jeff Layton
[not found] ` <e751977dac616d93806d98f4ad3ce144bb1eb244.camel-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2020-04-15 17:07 ` Steve French
2020-04-15 17:07 ` Steve French
2020-04-15 17:07 ` Steve French
2020-04-16 10:15 ` David Howells
2020-04-16 10:15 ` David Howells
2020-04-15 9:44 ` Florian Weimer
2020-04-15 9:44 ` Florian Weimer
2020-04-16 10:27 ` David Howells
2020-04-16 10:27 ` David Howells
2020-04-16 10:33 ` Florian Weimer
2020-04-16 10:33 ` Florian Weimer
2020-04-16 13:01 ` David Howells
2020-04-16 13:01 ` David Howells
[not found] ` <128769.1587032833-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2020-04-16 13:40 ` Chuck Lever
2020-04-16 13:40 ` Chuck Lever
2020-04-16 13:40 ` Chuck Lever
2020-04-17 11:31 ` Aurélien Aptel
2020-04-17 11:31 ` Aurélien Aptel
2020-04-17 23:23 ` Steve French
2020-04-17 23:23 ` Steve French
[not found] ` <CAH2r5mv5p=WJQu2SbTn53FeTsXyN6ke_CgEjVARQ3fX8QAtK_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-04-18 18:10 ` Florian Weimer
2020-04-18 18:10 ` Florian Weimer
2020-04-18 18:10 ` Florian Weimer
2020-04-19 4:53 ` Steve French
2020-04-19 4:53 ` Steve French
2020-04-19 8:37 ` David Howells
2020-04-19 8:37 ` David Howells
[not found] ` <927453.1587285472-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2020-04-20 0:58 ` Paulo Alcantara
2020-04-20 0:58 ` Paulo Alcantara
2020-04-20 0:58 ` Paulo Alcantara
[not found] ` <87imhvj7m6.fsf-jNnf+gw1pmM@public.gmane.org>
2020-04-20 13:13 ` David Howells
2020-04-20 13:13 ` David Howells
2020-04-20 13:13 ` David Howells
2020-04-20 18:21 ` Paulo Alcantara [this message]
2020-04-20 18:21 ` Paulo Alcantara
2020-04-20 18:21 ` Paulo Alcantara
2020-04-20 22:14 ` cifs - Race between IP address change and sget()? David Howells
2020-04-20 22:14 ` David Howells
2020-04-20 22:30 ` Jeff Layton
2020-04-20 22:30 ` Jeff Layton
2020-04-21 1:29 ` Ronnie Sahlberg
2020-04-21 1:29 ` Ronnie Sahlberg
2020-04-21 2:26 ` Steve French
2020-04-21 2:26 ` Steve French
2020-04-21 2:29 ` Steve French
2020-04-21 2:29 ` Steve French
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=878siq587w.fsf@cjr.nz \
--to=pc@cjr.nz \
--cc=ceph-devel@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=fweimer@redhat.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-afs@lists.infradead.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=smfrench@gmail.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.