This case is the result of a fairly long, drawn-out case. The problem
goes something like this:
1) mount a samba share using CIFS
2) start some continuous I/O on the mount (a loop that creates a
tarball on the mount and removes it seems to work)
3) shut down the samba server
4) suspend the process doing I/O (via ^z)
5) kill -9 pid_of_cifsd_kthread (I have no idea why they're doing this,
but bear with me)
6) umount -l the mount
7) start up samba again
after this, you cannot remount the samba share. mount attempts all
return either -ENOTDIR or -EAGAIN. The only fix seems to be to reboot
the box.
While the steps for this reproducer are pathological, I think they
expose a problem with how cifsd handles signals. If we're in
cifs_reconnect and cifsd is signalled, then the connect calls will all
start returning -ERESTARTSYS and we'll never exit from the while loop.
I *think* the following patch (or something like it) might be
appropriate. I've tested a similar patch on Steve's backported 1.48a
CIFS code and it seems to fix the problem there, but that code doesn't
have the kthread changes. Does this look reasonable, or am I missing
something important? :-)
--
Jeff Layton <jlayton@xxxxxxxxxx>
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index f4e9266..d369dd0 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -197,6 +197,11 @@ cifs_reconnect(struct TCP_Server_Info *server)
server->server_RFC1001_name);
}
if(rc) {
+ if (rc == -ERESTARTSYS) {
+ cFYI(1,("reconnect interrupted by signal"));
+ kthread_stop(server->tsk);
+ continue;
+ }
cFYI(1,("reconnect error %d",rc));
msleep(3000);
} else {
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
