On Wed, Mar 2, 2022 at 8:16 PM Satadru Pramanik <satadru@xxxxxxxxx> wrote: > > 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@xxxxxxxxx> wrote: > > > > On Wed, Mar 2, 2022 at 3:51 AM Satadru Pramanik <satadru@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@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 > > > > 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 Hi Satadru, The attached dmesg did not have cifsFYI enabled. Please use the below steps to enable cifsFYI before the sleep: # echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control # echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control # echo 7 > /proc/fs/cifs/cifsFYI You can disable it after the repro using this cmd: # echo 0 > /proc/fs/cifs/cifsFYI -- Regards, Shyam
