(resending to wider distribution list per Steve French's request)
When cifs_demultiplex_thread was converted to a kthread based kernel
thread, great pains were taken to make it so that kthread_stop would be
used to bring it down. This just added unnecessary complexity since we
needed to use a signal anyway to break out of kernel_recvmsg.
Also, cifs_demultiplex_thread does a bit of cleanup as it's exiting, and
we need to be certain that this gets done. It's possible for a kthread
to exit before its main function is ever run if kthread_stop is called
soon after its creation. While I'm not sure that this is a real problem
with cifsd now, it could be at some point in the future if cifs_mount is
ever changed to bring down the thread quickly.
The upshot here is that using kthread_stop to bring down the thread just
adds extra complexity with no real benefit. This patch changes the code
to use the original method to bring down the thread, but still leaves it
so that the thread is actually started with kthread_run.
This seems to fix the deadlock caused by the reproducer in this bug
If this patch looks OK, I think it's probably 2.6.28 material, though
getting it into linux-next ASAP would be good way to get it some
As a side comment, the locking and refcounting with cifsd startup and
shutdown is really hairy, and there are probably other races lurking
here. We really need for someone to take a hard look at this code and
try to clarify and clean up the locking on the variables involved.
Signed-off-by: Jeff Layton <firstname.lastname@example.org>
fs/cifs/connect.c | 42 +++++++++++++-----------------------------
1 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 4c13bcd..0d63fc7 100644
@@ -124,7 +124,7 @@ cifs_reconnect(struct TCP_Server_Info *server)
struct mid_q_entry *mid_entry;