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

[Steve French <smfrench@gmail.com>]

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