Date: Sun, 22 Oct 2006 09:27:29 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: David Xu <davidxu@freebsd.org> Cc: cvs-src@freebsd.org, Don Lewis <truckman@freebsd.org>, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_exit.c Message-ID: <20061022062729.GE45605@deviant.kiev.zoral.com.ua> In-Reply-To: <200610221354.57273.davidxu@freebsd.org> References: <200610220014.k9M0E5mG061752@gw.catspoiler.org> <200610221354.57273.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--AsxXAMtlQ5JHofzM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Oct 22, 2006 at 01:54:57PM +0800, David Xu wrote:
> But I am still worrried by these signal changes, if an exiting process
> can be sent a signal, and msleep will interrupted in cleanup code, where =
the
> code will return to ? in normal case, code will return to userland, and=
=20
> signal will be removed and delivered, but if a thread is in exit1(), where
> the code can be returned to ? if a cleanup procedure is interrupted, is=
n't=20
> there is any resource leak or dead-loop if it is retried because signal i=
s=20
> never removed ?
As noted in the original commit message, I asked for something related some
time ago. But, I wanted only to wake up the thread sleeping in exit code.
The scenario when this is needed is driver (or nfs client) sleeping in
file descriptors cleanup. Currently, such process may become unkillable.
I proposed the following change:
Index: kern_sig.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /usr/local/arch/ncvs/src/sys/kern/kern_sig.c,v
retrieving revision 1.332
diff -u -r1.332 kern_sig.c
--- kern_sig.c 5 Oct 2006 01:56:11 -0000 1.332
+++ kern_sig.c 22 Oct 2006 06:23:55 -0000
@@ -2126,8 +2126,7 @@
* action will be SIG_DFL here.)
*/
mtx_lock(&ps->ps_mtx);
- if (SIGISMEMBER(ps->ps_sigignore, sig) ||
- (p->p_flag & P_WEXIT)) {
+ if (SIGISMEMBER(ps->ps_sigignore, sig)) {
mtx_unlock(&ps->ps_mtx);
if (ksi && (ksi->ksi_flags & KSI_INS))
ksiginfo_tryfree(ksi);
@@ -2144,7 +2143,12 @@
else
intrval =3D ERESTART;
mtx_unlock(&ps->ps_mtx);
-
+ if (p->p_flag & P_WEXIT) {
+ mtx_lock_spin(&sched_lock);
+ tdsigwakeup(td, sig, action, intrval);
+ mtx_unlock_spin(&sched_lock);
+ return (ret);
+ }
if (prop & SA_CONT)
sigqueue_delete_stopmask_proc(p);
else if (prop & SA_STOP) {
I have a hope that kernel code would wake up and make a progress, while not
actually delivering signal to the user mode handler.
--AsxXAMtlQ5JHofzM
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFOw9RC3+MBN1Mb4gRAmz5AKCozwSqUIAW5SvVCRrhuEEktqCU3QCgmvfF
b+iRQ/efpmDYqO8pL1xVWiM=
=0IKu
-----END PGP SIGNATURE-----
--AsxXAMtlQ5JHofzM--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061022062729.GE45605>