From owner-cvs-all@FreeBSD.ORG Sun Oct 22 06:27:36 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B369C16A403; Sun, 22 Oct 2006 06:27:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from fw.zoral.com.ua (fw.zoral.com.ua [213.186.206.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05F1C43D45; Sun, 22 Oct 2006 06:27:35 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id k9M6BU1C062005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 09:11:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id k9M6RU7x005215; Sun, 22 Oct 2006 09:27:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id k9M6RTGO005210; Sun, 22 Oct 2006 09:27:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 Oct 2006 09:27:29 +0300 From: Kostik Belousov To: David Xu Message-ID: <20061022062729.GE45605@deviant.kiev.zoral.com.ua> References: <200610220014.k9M0E5mG061752@gw.catspoiler.org> <200610221354.57273.davidxu@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsxXAMtlQ5JHofzM" Content-Disposition: inline In-Reply-To: <200610221354.57273.davidxu@freebsd.org> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE, SPF_NEUTRAL,UNPARSEABLE_RELAY autolearn=no version=3.1.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on fw.zoral.com.ua Cc: cvs-src@freebsd.org, Don Lewis , src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_exit.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 06:27:36 -0000 --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--