Bug#695492: CIFS mount fails if I ctrl-c a long-running find process (Linux mounting Windows share)
On Sun, Jan 13, 2013 at 05:46:35AM -0500, Jeff Layton wrote:
> On Sat, 12 Jan 2013 10:28:01 -0800
> John Darrah <xyllyx@gmail.com> wrote:
>
> >
> > Is there a command or kernel magic the can force a dump to
> > see where the contention is that is causing the hang?
> >
> > Also, I just tried starting the VM and mounting the CIFS
> > drives and then just letting it sit there without running
> > anything to touch the drives.... they still hang. So this
> > means the CTRL-C thing has nothing to do with it.
> >
>
> Ok, so it sounds like the original bug is now fixed with the patch I
> proposed. This other thing sounds like it warrants a new bug. When you
> say it hangs, does the whole box hang or is it just processes that
> touch the cifs mount?
>
> If you know the pid of the hung process, you can look at
> /proc/<pid>/stack to see what it's doing. There are also things like
> sysrq-t. You can also set up kdump and force a crash on a machine to
> get a coredump, and then try to analyze it to figure out why it's hung.
>
I've have looked at this several times, but all I can come
up with is the contents of /proc/<pid>/stack. The is an 'ls'
command that is waiting for something. I can see some CIFS
stuff but I have no idea what i'm looking at. This was taken
after about 30 minutes in the hung state.
[<c11fee0d>] kernel_setsockopt+0x34/0x46
[<f86925c7>] smb_send_rqst+0x107/0x170 [cifs]
[<c1035b66>] prepare_to_wait+0x12/0x37
[<f86922d8>] wait_for_response.isra.8+0x6d/0xc2 [cifs]
[<c1035af9>] autoremove_wake_function+0x0/0x29
[<f8692c7a>] SendReceive+0x141/0x1f1 [cifs]
[<f867b793>] CIFSSMBNegotiate+0x17c/0x6bf [cifs]
[<f8697fc3>] cifs_negotiate+0xb/0x31 [cifs]
[<f8686557>] cifs_negotiate_protocol+0x3b/0x62 [cifs]
[<f867b471>] cifs_reconnect_tcon+0x16f/0x235 [cifs]
[<c10870ff>] prep_new_page+0xac/0xe0
[<f867b550>] smb_init+0x19/0x58 [cifs]
[<f867f815>] CIFSSMBQPathInfo+0x4c/0x1e2 [cifs]
[<f8697eb4>] cifs_query_path_info+0x26/0x5a [cifs]
[<f868e327>] cifs_get_inode_info+0x10d/0x4a1 [cifs]
[<c10a9e6a>] __kmalloc+0x8d/0x99
[<f86875e9>] build_path_from_dentry+0xab/0x182 [cifs]
[<f868761b>] build_path_from_dentry+0xdd/0x182 [cifs]
[<f868f8e2>] cifs_revalidate_dentry_attr+0xd7/0x131 [cifs]
[<f868f965>] cifs_revalidate_dentry+0x9/0x1d [cifs]
[<f8687497>] cifs_d_revalidate+0x13/0x6e [cifs]
[<c10b5c84>] d_revalidate+0x5/0x6
[<c10b6922>] lookup_fast+0x169/0x1ed
[<c10b6c13>] walk_component+0x2e/0x144
[<c10b7288>] link_path_walk+0x32c/0x3ca
[<c10b764f>] path_lookupat+0x4d/0x251
[<c10b7872>] filename_lookup+0x1f/0x6c
[<c10b93bf>] user_path_at_empty+0x59/0x81
[<c10b6201>] vfs_readlink+0x2d/0x3c
[<c10b6256>] generic_readlink+0x46/0x6a
[<c10b93f2>] user_path_at+0xb/0xe
[<c10b2d24>] vfs_fstatat+0x33/0x61
[<c10b2d77>] vfs_stat+0x10/0x12
[<c10b31e5>] sys_stat64+0xe/0x21
[<c10bd157>] dput+0x16/0x96
[<c10b31af>] sys_readlinkat+0x82/0x93
[<c10b31d3>] sys_readlink+0x13/0x17
[<c12a2a7f>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
Sorry I can't be more help.
-- john
Reply to: