Re: Hung CIFS driver

["ISHIKAWA,chiaki" <ishikawa-FORCTJUUkgPbmG5+kqVDhQ@public.gmane.org>]

(2013/11/10 21:29), ISHIKAWA,chiaki wrote:
> (2013/11/10 21:04), Jeff Layton wrote:
>> On Sun, 10 Nov 2013 13:40:01 +0900
>> "ISHIKAWA,chiaki" <ishikawa-FORCTJUUkgPbmG5+kqVDhQ@public.gmane.org> wrote:
>>
>>> (2013/11/09 20:58), Jeff Layton wrote:
>>>> On Sat, 09 Nov 2013 02:41:41 +0900
>>>> "ISHIKAWA,chiaki" <ishikawa-FORCTJUUkgPbmG5+kqVDhQ@public.gmane.org> wrote:
>
>> cifsd is a kernel thread, which means that it acts like a process but
>> always runs in kernel mode. It'll have a name like "[cifsd]" in ps. You
>> can get its stack in exactly the same way as any other process
>> (/proc/<pid>/stack).
>
> Thank you.
> I found it in my ps output.
> I will investigate more.
> My previous post was before I read you latest info.
>
> Thank again for your tips.
>

Here is the stack trace of cifs and cifsiod.
It looks that the reading seems to gets stuck.

root@vm-debian-amd64:/tmp# LC_ALL=C
root@vm-debian-amd64:/tmp# LANG=C
root@vm-debian-amd64:/tmp# ps -aef | grep cifs
root     11607 11427  0 21:35 pts/8    00:00:00 grep cifs
root     16853     2  0 Nov08 ?        00:00:00 [cifsiod]
root     16901     2  0 Nov08 ?        00:00:31 [cifsd]
root@vm-debian-amd64:/tmp# cat /proc/16901
cat: /proc/16901: Is a directory
root@vm-debian-amd64:/tmp# cat /proc/16901/stack
[<ffffffff81047920>] process_timeout+0x0/0x5
[<ffffffff812b72d4>] sk_wait_data+0x7b/0xbb
[<ffffffff81057c7d>] autoremove_wake_function+0x0/0x2a
[<ffffffff812f9bab>] tcp_recvmsg+0x466/0x999
[<ffffffff813163f1>] inet_recvmsg+0x5a/0x6e
[<ffffffff812b482b>] sock_recvmsg+0x5a/0x79
[<ffffffff8105eaff>] mmdrop+0xd/0x1c
[<ffffffff81059b0e>] lock_hrtimer_base.isra.16+0x1b/0x3c
[<ffffffff812b499b>] kernel_recvmsg+0x30/0x3a
[<ffffffffa04d9f87>] cifs_readv_from_socket+0x14a/0x1ed [cifs]
[<ffffffff810c2ad0>] mempool_alloc+0x5c/0x128
[<ffffffffa04da048>] cifs_read_from_socket+0x1e/0x23 [cifs]
[<ffffffffa04da7fc>] cifs_demultiplex_thread+0x775/0x79a [cifs]
[<ffffffffa04da087>] cifs_demultiplex_thread+0x0/0x79a [cifs]
[<ffffffff81057325>] kthread+0x7d/0x85
[<ffffffff81040900>] do_exit+0x901/0x918
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffff8138b47c>] ret_from_fork+0x7c/0xb0
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffffffffffff>] 0xffffffffffffffff
root@vm-debian-amd64:/tmp# cat /proc/16853/stack
[<ffffffff81052dd4>] rescuer_thread+0x23f/0x265
[<ffffffff81052b95>] rescuer_thread+0x0/0x265
[<ffffffff81057325>] kthread+0x7d/0x85
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffff8138b47c>] ret_from_fork+0x7c/0xb0
[<ffffffff810572a8>] kthread+0x0/0x85
[<ffffffffffffffff>] 0xffffffffffffffff
root@vm-debian-amd64:/tmp#

>>>> What kernel version is this too, btw?
>>>
>>> uname -r
>>> 3.10-3-amd64
>>>
>>> It is 3.10.3 64bit.
>>>
>>
>> Thanks. It might be worth testing something v3.12-ish, but I sort of
>> doubt it'll make much difference.
>>
>
> I will try to gather as much data as possible from my hung CIFS state so
> that we can have a better idea of where the problems may lie
> before I try upgrading my kernel and test similar operations.
> (Also, I am not sure if I can replace the kernel as easily as we could
> do before. It seems some userland daemeon may be tied to kernel versions
> rather in complicated manner these days.)
>
> Thank you again for your attention.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>