linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paulo Alcantara <pc@cjr.nz>
To: Thomas Werschlein <thomas.werschlein@geo.uzh.ch>,
	linux-cifs@vger.kernel.org
Subject: Re: Kernel lockup upon dfs_cache_update
Date: Tue, 10 Aug 2021 12:02:21 -0300	[thread overview]
Message-ID: <87wnotmjgi.fsf@cjr.nz> (raw)
In-Reply-To: <C36709C4-A89B-40A8-819B-F54828F8788D@geo.uzh.ch>

Thomas Werschlein <thomas.werschlein@geo.uzh.ch> writes:

> Hi
>
> We are mounting SMB shares from Windows and FreeBSD servers to AD-joined (Ubuntu) Linux clients, using DFS and Kerberos.
>
> A sample /etc/fstab entry looks like this:
> //files.d.example.com/shared /files/shared cifs defaults,sec=krb5i,vers=3,seal,multiuser,noserverino,username=LINUXCLIENT$ 0 0
>
> The machine account LINUXCLIENT$ is able to browse the DFS tree and mount the shares.
> The credentials for the principal LINUXCLIENT$@D.EXAMPLE.COM are stored in the default keytab (/etc/krb5.keytab).
> In order to access a share a user needs a personal KRB ticket (either through kinit or GSSAPI delegated credentials upon ssh login).
>
> This works fine on Ubuntu 18.04 (4.15.0-153-generic Kernel, 2.10 cifs.ko), but doesn't on Ubuntu 20.04 (5.4.0-80-generic, 2.23).
> To be precise: it works for the first 10 hours (the ticket lifetime) even on Ubuntu 20.04.
>
> My findings so far:
> - this lockup (after 10h) *only* occurs when DFS is involved. Mounting a target share directly "survives" the ticket expiry
> - this problem does *not* manifest with the newest kernel/cifs.ko combo (5.14.0-051400rc5-generic/2.33)
>
> Therefore:
> Could it be, that the DFS patches contributed by Paulo Alcantara on June 4 2021 (https://www.spinics.net/lists/linux-cifs/msg21999.html)
> fixed this problem?

Yes, that is possible.  We found out some deadlock and race scenarios
but couldn't remember if the above was one of them.  Still worth having
those commits backported.

>
> Two of his comments point into that direction: 
>   [...]
>   - keep SMB sessions alive as long as dfs mounts are actives in order
>     to refresh cached entries by using IPC tcons.
>   [...]
>   - skip unnecessary tree disconnect of IPCs when shutting down SMB
>     sessions (it didn't even work before).
>
> Am I on the right track here? And if so: are there any plans to backport Paulo's patches to current kernels?

Yes.  I don't know if there any plans, but the only tricky part is
changing the commits to work with the old mount api on <5.11 kernels.

  reply	other threads:[~2021-08-10 15:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10 13:56 Kernel lockup upon dfs_cache_update Thomas Werschlein
2021-08-10 15:02 ` Paulo Alcantara [this message]
2021-08-27 12:37   ` Thomas Werschlein

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=87wnotmjgi.fsf@cjr.nz \
    --to=pc@cjr.nz \
    --cc=linux-cifs@vger.kernel.org \
    --cc=thomas.werschlein@geo.uzh.ch \
    /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).