Steve French 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
Steve French writes:
> I did some additional testing and it looks like the "allow_signal"
> change may be safe enough
>
> # git diff -a
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index a4830ced0f98..a15a6e738eb5 100644
> --- a/fs/cifs/connect.c
> +++ b/fs/cifs/connect.c
> @@ -1113,6
Patch attached - tests out ok.
On Tue, Jul 23, 2019 at 9:28 PM Steve French wrote:
>
> I did some additional testing and it looks like the "allow_signal"
> change may be safe enough
>
> # git diff -a
> diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
> index a4830ced0f98..a15a6e738eb5 100644
I did some additional testing and it looks like the "allow_signal"
change may be safe enough
# git diff -a
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index a4830ced0f98..a15a6e738eb5 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -1113,6 +1113,7 @@ cifs_demultiplex_thread(void
Pavel noticed I missed a line from the attempt to do a similar patch
to Eric's suggestion
(it still didn't work though - although "allow_signal" does albeit is
possibly dangerous as user space can kill cifsd)
# git diff -a
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index
On Tue, Jul 23, 2019 at 8:32 PM Eric W. Biederman wrote:
>
> Steve French 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
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
On Tue, Jul 16, 2019 at 1:15 AM Sasha Levin wrote:
>
> From: "Eric W. Biederman"
>
> [ Upstream commit 72abe3bcf0911d69b46c1e8bdb5612675e0ac42c ]
>
> The locking in force_sig_info is not prepared to deal with a task that
> exits or execs (as sighand may change). The is not a locking problem
>
From: "Eric W. Biederman"
[ Upstream commit 72abe3bcf0911d69b46c1e8bdb5612675e0ac42c ]
The locking in force_sig_info is not prepared to deal with a task that
exits or execs (as sighand may change). The is not a locking problem
in force_sig as force_sig is only built to handle synchronous
9 matches
Mail list logo
