Killing process with SIGKILL and ncpfs

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!

Trace; d18e8822 <[ncpfs]ncp_do_request+1e2/1f8>
Trace; d18e88a5 <[ncpfs]ncp_request2+6d/a0>
Trace; d18e7c3c <[ncpfs]ncp_make_closed+9c/c8>
Trace; d18e332e <[ncpfs]ncp_release+a/1c>
Trace; c01349c1 <fput+39/e8>
Trace; c012566e <exit_mmap+da/124>
Trace; c0115e54 <mmput+38/50>
Trace; c011a134 <do_exit+d0/2a8>
Trace; c0108e10 <do_signal+234/28c>
Trace; c011f032 <force_sig_info+9a/a4>
Trace; c011f24d <force_sig+11/18>
Trace; c0109581 <do_int3+35/78>
Trace; c0109088 <error_code+34/3c>
Trace; c0108fa4 <signal_return+14/18>

So my question is:
(1) should ncpfs ignore ALL signals (even SIGKILL/SIGSTOP) when task is in PF_EXITING mode, or
(2) should kernel clear all pending signals at the beginning of do_exit or
(3) is it gdb bug that they forget 'int3' operation in traced program?

Thanks,
Petr Vandrovec [email protected]

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

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/