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@xxxxxxxxxxxxx> 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
