Re: Failure to access cifs mount of samba share after resume from sleep with 5.17-rc5

[Satadru Pramanik <satadru@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8357 bytes --]

Here is also the dmesg as promised. (After resuming from suspend/sleep
this morning, when I again had the same issue.)

On Wed, Mar 2, 2022 at 2:57 AM Shyam Prasad N <nspmangalore@gmail.com> wrote:
>
> On Wed, Mar 2, 2022 at 3:51 AM Satadru Pramanik <satadru@gmail.com> wrote:
> >
> > I have put the trace.dat and other debug files here since I can not
> > attach the files to a message to the list. (Apparently the trace.dat
> > file is too large.)
> >
> > https://drive.google.com/drive/folders/1wEi968RbXxivXMMH8J7XUsHhrxu9OWDX?usp=sharing
> >
> > On Mon, Feb 28, 2022 at 11:12 PM Satadru Pramanik <satadru@gmail.com> wrote:
> > >
> > > The trace.dat file is attached, covering the period before suspend,
> > > and through wake several hours later, when the mount no longer worked,
> > > and showed the CIFS: VFS: cifs_tree_connect: could not find
> > > superblock: -22 message, and through when I unmounted and remounted
> > > the share, which then started working.
> > >
> > > On Mon, Feb 28, 2022 at 9:31 AM Satadru Pramanik <satadru@gmail.com> wrote:
> > > >
> > > > Here is the DebugData from before and after from the system with the
> > > > failed mount.
> > > > Both systems are now running 5.17-rc6.
> > > >
> > > > Working on the trace-cmd now.
> > > >
> > > > On Sun, Feb 27, 2022 at 9:37 PM Steve French <smfrench@gmail.com> wrote:
> > > > >
> > > > > I would like to see the output of:
> > > > >
> > > > > /proc/fs/cifs/DebugData before and after the failure if possible.
> > > > >
> > > > > In addition, there would be some value in seeing trace information
> > > > > (e.g start tracing by
> > > > > "trace-cmd record -e cifs" before the failure and then forward the
> > > > > debug information displayed by "trace-cmd show" after the failure)
> > > > >
> > > > > On Sun, Feb 27, 2022 at 7:55 AM Thorsten Leemhuis
> > > > > <regressions@leemhuis.info> wrote:
> > > > > >
> > > > > > [TLDR: I'm adding the regression report below to regzbot, the Linux
> > > > > > kernel regression tracking bot; all text you find below is compiled from
> > > > > > a few templates paragraphs you might have encountered already already
> > > > > > from similar mails.]
> > > > > >
> > > > > > Hi, this is your Linux kernel regression tracker. Top-posting for once,
> > > > > > to make this easily accessible to everyone.
> > > > > >
> > > > > > CCing the regression mailing list, as it should be in the loop for all
> > > > > > regressions, as explained here:
> > > > > > https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
> > > > > >
> > > > > > To be sure below issue doesn't fall through the cracks unnoticed, I'm
> > > > > > adding it to regzbot, my Linux kernel regression tracking bot:
> > > > > >
> > > > > > #regzbot ^introduced v5.16.11..v5.17-rc5
> > > > > > #regzbot title cifs: Failure to access cifs mount of samba share after
> > > > > > resume from sleep
> > > > > > #regzbot ignore-activity
> > > > > >
> > > > > > Reminder for developers: when fixing the issue, please add a 'Link:'
> > > > > > tags pointing to the report (the mail quoted above) using
> > > > > > lore.kernel.org/r/, as explained in
> > > > > > 'Documentation/process/submitting-patches.rst' and
> > > > > > 'Documentation/process/5.Posting.rst'. This allows the bot to connect
> > > > > > the report with any patches posted or committed to fix the issue; this
> > > > > > again allows the bot to show the current status of regressions and
> > > > > > automatically resolve the issue when the fix hits the right tree.
> > > > > >
> > > > > > I'm sending this to everyone that got the initial report, to make them
> > > > > > aware of the tracking. I also hope that messages like this motivate
> > > > > > people to directly get at least the regression mailing list and ideally
> > > > > > even regzbot involved when dealing with regressions, as messages like
> > > > > > this wouldn't be needed then. And don't worry, if I need to send other
> > > > > > mails regarding this regression only relevant for regzbot I'll send them
> > > > > > to the regressions lists only (with a tag in the subject so people can
> > > > > > filter them away). With a bit of luck no such messages will be needed
> > > > > > anyway.
> > > > > >
> > > > > > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> > > > > >
> > > > > > P.S.: As the Linux kernel's regression tracker I'm getting a lot of
> > > > > > reports on my table. I can only look briefly into most of them and lack
> > > > > > knowledge about most of the areas they concern. I thus unfortunately
> > > > > > will sometimes get things wrong or miss something important. I hope
> > > > > > that's not the case here; if you think it is, don't hesitate to tell me
> > > > > > in a public reply, it's in everyone's interest to set the public record
> > > > > > straight.
> > > > > >
> > > > > >
> > > > > > On 27.02.22 03:36, Satadru Pramanik wrote:
> > > > > > > I'm on a x86_64 ubuntu 22.04 system accessing a similar system running
> > > > > > > samba Version 4.13.14-Ubuntu. Both systems are on ubuntu mainline
> > > > > > > kernel 5.17-rc5.
> > > > > > >
> > > > > > > I have a samba share mounted from my fstab, and file access works fine.
> > > > > > > Upon suspending my system and resuming though, the mounted samba share
> > > > > > > is inaccessible, and my dmesg has many "CIFS: VFS: cifs_tree_connect:
> > > > > > > could not find superblock: -22" messages.
> > > > > > >
> > > > > > > Unmounting and remounting the share restores access.
> > > > > > >
> > > > > > > When I boot into kernel 5.16.11, I do not have this issue. The cifs
> > > > > > > share is accessible just fine after a suspend/resume cycle.
> > > > > > >
> > > > > > > I assume this is a regression with 5.17? Is there any information
> > > > > > > worth providing which might help debug and fix this issue?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Satadru Pramanik
> > > > > >
> > > > > > --
> > > > > > Additional information about regzbot:
> > > > > >
> > > > > > If you want to know more about regzbot, check out its web-interface, the
> > > > > > getting start guide, and the references documentation:
> > > > > >
> > > > > > https://linux-regtracking.leemhuis.info/regzbot/
> > > > > > https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
> > > > > > https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
> > > > > >
> > > > > > The last two documents will explain how you can interact with regzbot
> > > > > > yourself if your want to.
> > > > > >
> > > > > > Hint for reporters: when reporting a regression it's in your interest to
> > > > > > CC the regression list and tell regzbot about the issue, as that ensures
> > > > > > the regression makes it onto the radar of the Linux kernel's regression
> > > > > > tracker -- that's in your interest, as it ensures your report won't fall
> > > > > > through the cracks unnoticed.
> > > > > >
> > > > > > Hint for developers: you normally don't need to care about regzbot once
> > > > > > it's involved. Fix the issue as you normally would, just remember to
> > > > > > include 'Link:' tag in the patch descriptions pointing to all reports
> > > > > > about the issue. This has been expected from developers even before
> > > > > > regzbot showed up for reasons explained in
> > > > > > 'Documentation/process/submitting-patches.rst' and
> > > > > > 'Documentation/process/5.Posting.rst'.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Thanks,
> > > > >
> > > > > Steve
>
> The DebugData shows that the connection and smb session are fine, but
> the tree connect is not in a good state.
> Similarly, the trace output shows that connection was reconnected
> successfully, SMB session was reconnected as well. However, the tree
> connect did not go over the wire.
>
> > The trace.dat file is attached, covering the period before suspend,
> > and through wake several hours later, when the mount no longer worked,
> > and showed the CIFS: VFS: cifs_tree_connect: could not find
> > superblock: -22 message, and through when I unmounted and remounted
> > the share, which then started working.
>
> This suggests to me that the cifs_tcp_get_super is failing.
> This is odd, since it looks up the server as pointers.
> Did we start undercounting the ref count somewhere?
>
> --
> Regards,
> Shyam

[-- Attachment #2: dmesg.txt.gz --]
[-- Type: application/gzip, Size: 24136 bytes --]