Bug 12015 - cifs module freezes and creates IO blocked processes
Summary: cifs module freezes and creates IO blocked processes
Status: NEW
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 3.x
Hardware: x64 Linux
: P5 critical
Target Milestone: ---
Assignee: Steve French
QA Contact: cifs QA contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-10 12:04 UTC by Xen
Modified: 2020-07-16 00:12 UTC (History)
0 users

See Also:


Attachments
First pastelog describing the 120 second "hung" messages. (17.10 KB, text/plain)
2016-07-10 12:04 UTC, Xen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xen 2016-07-10 12:04:58 UTC
Created attachment 12266 [details]
First pastelog describing the 120 second "hung" messages.

I've had multiple shares mounted (cifs-utils) from the same Samba server. Client machine (on which the hangs occur) is Ubuntu 4.4.0-28-generic #47-Ubuntu SMP. Server machine is a synology NAS with kernel 2.6.32 and Samba 3.6.9. I did not ever really experience such hangs before on the client machine.

Here is a pastelog of what happens

http://pastebin.com/bnKpmXXv

The paste is not complete, the entire thing repeats itself twice but that is just the repeat of the 120 second window that causes the output.

In this particular instance I had two shares mounted on top of one another, in the sense that:

- share 1 mounted at /nas/share, and
- share 2 mounted at /nas/share/sub.

But I believe I have experienced it before when this was not the case.

(The contents of the second share is not visible in the contents of the first share, when it is getting mounted, that subdirectory is empty, although the subdirectory is part of share 1. I am not sure it is even relevant).

Nothing particularly strange was happening on my system. "gvfsd-recent" may be the result of an installation of Cinnamon. This is the task that blocks here in this output, but anything else, like "ls /nas" or "umount /nas/share" will equally block just as well.

So I'm not sure gvfsd has anything to do with it; it seems more likely that it is just any random hung task, but I don't know.

This freeze happened at some point during the running of the system, not during boot. Not during mount. There were no other kernel errors that I could see. After reboot the system mounts normally and appears to have no issue with anything; but it is not in active use, and I have not run any "activity" tests or anything; I have not automated access to the shares as a way of trying to reproduce anything.

The first thing I noticed on my system was that "Kate" would not start; apparently it had a handle on the share or was trying to open something from it. "ps" showed Kate as "D", meaning IO-blocked in uninterruptable sleep. I couldn't figure out why this was happening but Kate wouldn't start. So the blocking was going on long before I noticed, and had apparently not been the result of any "conscious" activity on the share from my part, in that I did something and immediately noticed a hang. 

I don't know what gvfsd does or why it is there; but the shares were mounted from fstab, manually. It seems gvfsd was just a process trying to access it?

If it happens more I will attach more pastes, but I hope it doesn't.

Regards.