Steve French smfrench@gmail.com writes:
Very easy to see what caused the regression with this global change:
mount (which launches "cifsd" thread to read the socket) umount (which kills the "cifsd" thread) rmmod (rmmod now fails since "cifsd" thread is still active)
mount launches a thread to read from the socket ("cifsd") umount is supposed to kill that thread (but with the patch "signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig" that no longer works). So the regression is that after unmount you still see the "cifsd" thread, and the reason that cifsd thread is still around is that that patch no longer force kills the process (see line 2652 of fs/cifs/connect.c) which regresses module removal.
force_sig(SIGKILL, task);
send_sig(SIGKILL, task, 1);The comment in the changeset indicates "The signal SIGKILL can not be ignored" but obviously it can be ignored - at least on 5.3-rc1 it is being ignored.
If send_sig(SIGKILL ...) doesn't work and if force_sig(SIGKILL, task) is removed and no longer possible - how do we kill a helper process ...
I think I see what is happening. It looks like as well as misuinsg force_sig, cifs is also violating the invariant that keeps SIGKILL out of the blocked signal set.
For that force_sig will act differently. I did not consider it because that is never supposed to happen.
Can someone test this code below and confirm the issue goes away?
diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c index 5d6d44bfe10a..2a782ebc7b65 100644 --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -347,6 +347,7 @@ __smb_send_rqst(struct TCP_Server_Info *server, int num_rqst, */
sigfillset(&mask); + sigdelset(&mask, SIGKILL); sigprocmask(SIG_BLOCK, &mask, &oldmask);
/* Generate a rfc1002 marker for SMB2+ */
Eric