Re: Killing process with SIGKILL and ncpfs

From: Urban Widmark (urban@teststation.com)
Date: Wed Jan 17 2001 - 07:41:39 EST


On Wed, 17 Jan 2001, Petr Vandrovec wrote:

> Hi,
> Maarten de Boer pointed to me, that if you load some simple program,
> such as 'void main(void) {}', trace into main (break main; run)
> and then quit from gdb (Really exit? yes), child process is then
> killed due to INT3 (probably). Then exit_mmap releases executable
> mapping - and ncp_do_request is entered with SIGKILL pending!

smbfs has a signal problem in it's fs/smbfs/sock.c, possibly related.

SIGKILL or SIGSTOP can be already pending, or perhaps received while
waiting in socket->ops->recvmsg(). recvmsg will then return -ERESTARTSYS
because signal_pending() is true and the smbfs code treats that as a
network problem (causing unnecessary reconnects and sometimes complete
failures requiring umount/mount).

I don't know what happens with ncpfs, I don't think you wrote that, but I
am interested in how it handles this. (Again, I have looked at the ncpfs
code for useful bits to copy :)

Running strace on a multithreaded program causes problems for smbfs.
Someone was nice enough to post a small testprogram for this (you may want
to try it on ncpfs, if you want it I'll find it for you).

These problems go away if all signals are blocked. Of course the smbfs
code would need to be changed to not block on recv, else you may end up
with a program waiting for network input that can't be killed ... (?)

/Urban

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Jan 23 2001 - 21:00:15 EST