From mboxrd@z Thu Jan 1 00:00:00 1970 From: "ISHIKAWA,chiaki" Subject: Re: Hung CIFS driver Date: Sun, 10 Nov 2013 21:38:44 +0900 Message-ID: <527F7E54.5080905@yk.rim.or.jp> References: <527BAFC6.5010600@yk.rim.or.jp> <20131107110353.6d203196@tlielax.poochiereds.net> <527BC9C9.5080502@yk.rim.or.jp> <527D1ABD.3080404@yk.rim.or.jp> <527D2255.1070709@yk.rim.or.jp> <20131109065826.481ff52c@tlielax.poochiereds.net> <527F0E21.603@yk.rim.or.jp> <20131110070412.0c685682@tlielax.poochiereds.net> <527F7C46.4040105@yk.rim.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Layton To: "linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" Return-path: In-Reply-To: <527F7C46.4040105-FORCTJUUkgPbmG5+kqVDhQ@public.gmane.org> Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: (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" wrote: >> >>> (2013/11/09 20:58), Jeff Layton wrote: >>>> On Sat, 09 Nov 2013 02:41:41 +0900 >>>> "ISHIKAWA,chiaki" 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//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 [] process_timeout+0x0/0x5 [] sk_wait_data+0x7b/0xbb [] autoremove_wake_function+0x0/0x2a [] tcp_recvmsg+0x466/0x999 [] inet_recvmsg+0x5a/0x6e [] sock_recvmsg+0x5a/0x79 [] mmdrop+0xd/0x1c [] lock_hrtimer_base.isra.16+0x1b/0x3c [] kernel_recvmsg+0x30/0x3a [] cifs_readv_from_socket+0x14a/0x1ed [cifs] [] mempool_alloc+0x5c/0x128 [] cifs_read_from_socket+0x1e/0x23 [cifs] [] cifs_demultiplex_thread+0x775/0x79a [cifs] [] cifs_demultiplex_thread+0x0/0x79a [cifs] [] kthread+0x7d/0x85 [] do_exit+0x901/0x918 [] kthread+0x0/0x85 [] ret_from_fork+0x7c/0xb0 [] kthread+0x0/0x85 [] 0xffffffffffffffff root@vm-debian-amd64:/tmp# cat /proc/16853/stack [] rescuer_thread+0x23f/0x265 [] rescuer_thread+0x0/0x265 [] kthread+0x7d/0x85 [] kthread+0x0/0x85 [] ret_from_fork+0x7c/0xb0 [] kthread+0x0/0x85 [] 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 > >