From owner-cvs-src@FreeBSD.ORG Sat Oct 21 00:58:10 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3675816A403; Sat, 21 Oct 2006 00:58:10 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: John Baldwin Date: Sat, 21 Oct 2006 08:58:04 +0800 User-Agent: KMail/1.8.2 References: <200610201619.k9KGJLZH076566@repoman.freebsd.org> In-Reply-To: <200610201619.k9KGJLZH076566@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610210858.04180.davidxu@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2006 00:58:10 -0000 On Saturday 21 October 2006 00:19, John Baldwin wrote: > jhb 2006-10-20 16:19:21 UTC > > FreeBSD src repository > > Modified files: > sys/kern kern_sig.c > Log: > Remove the check that prevented signals from being delivered to exiting > processes. It was originally added back when support for Linux threads > (and thus shared sigacts objects) was added, but no one knows why. My > guess is that at some point during the Linux threads patches, the sigacts > object was torn down during exit1(), so this check was added to prevent > a panic for that race. However, the stuff that was actually committed to > the tree doesn't teardown sigacts until wait() making the above race > moot. Re-allowing signals here lets one interrupt a NFS request during > process teardown (such as closing descriptors) on an interruptible mount. > > Requested by: kib (long time ago) > MFC after: 1 week > > Revision Changes Path > 1.333 +1 -3 src/sys/kern/kern_sig.c This commit opens a window that may cause memory leak, since we have signal queue in -CURRENT now, signal queue uses memory, before this change, the P_WEXIT will prevents new signal to be queued, after the flag is set in kern_exit, we call signqueue_flush to free memory. I think we should move sigqueue_flush down to a safe point where the PROC lock is no longer unlocked or move it to a place after p_state is set to PRS_ZOMBIE. David Xu