archive mirror
 help / color / mirror / Atom feed
From: Thomas Werschlein <>
To: Paulo Alcantara <>
Subject: Re: Kernel lockup upon dfs_cache_update
Date: Fri, 27 Aug 2021 14:37:08 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> On Tue, Aug 10, 2021 at 5:02 PM Paulo Alcantara <> wrote:
> Thomas Werschlein <> 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/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 (
>> 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.

Thanks for your (possible) confirmation.

>> 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.

I wasn't aware of Ubuntu's "LTS enablement stack" (
A simple 'sudo apt install --install-recommends linux-generic-hwe-20.04' brings the latest LTS to Kernel 5.11.0-27 and cifs.ko to 2.30.

Strange enough (but gratefully so) this did solve my problem - the lockups don't manifest anymore.
I wouldn't have expected this, since your patches from June 4 brought cifs.ko to 2.31. Must be some earlier change then?

Anyway, our problem is gone. Thanks again.

Best regards

      reply	other threads:[~2021-08-27 12:37 UTC|newest]

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

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:

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

  git send-email \ \ \ \ \
    --subject='Re: Kernel lockup upon dfs_cache_update' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).