From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 08:31:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 997FE16A4CE; Fri, 1 Oct 2004 08:31:44 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D88743D39; Fri, 1 Oct 2004 08:31:44 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 5E2DE5C902; Fri, 1 Oct 2004 01:31:44 -0700 (PDT) Date: Fri, 1 Oct 2004 01:31:44 -0700 From: Alfred Perlstein To: re@FreeBSD.org Message-ID: <20041001083144.GT39252@elvis.mu.org> References: <200410010741.i917fJUo076107@pooker.samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410010741.i917fJUo076107@pooker.samsco.org> User-Agent: Mutt/1.4.2.1i cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 08:31:44 -0000 * Scott Long [041001 00:40] wrote: > | if_em wedging under | | | "wedging" under | > | high pps | Not done | - | high | I've seen this for months... > |------------------+-------------+----------------+----------------------| > | | | | A process cannot be | > | | | | interrupted while | > | | | | waiting on a lock. | > | rpc.lockd(8) | | | Fixing this requires | > | stability | -- | -- | that the RPC code be | > | | | | taught how to deal | > | | | | with lock | > | | | | cancellation and | > | | | | interruption events. | Thinking about it... I think Darwin has the fix, I'll see if I can merge it. > |------------------+-------------+----------------+----------------------| > | | | | Truss appears to | > | | | | have another | > | | | | problem. It is | > | | | | repeatable by | > | | | | running "truss -f | > | More truss | Not done | -- | fsck -p /", | > | problems | | | suspending it with | > | | | | ^Z, and then killing | > | | | | truss. It will leave | > | | | | behind the fsck | > | | | | processes which will | > | | | | be unkillable. | This fixes it: Index: kern_sig.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v retrieving revision 1.290 diff -u -r1.290 kern_sig.c --- kern_sig.c 31 Aug 2004 07:34:53 -0000 1.290 +++ kern_sig.c 1 Oct 2004 08:27:12 -0000 @@ -1775,6 +1775,16 @@ !((prop & SA_CONT) && (p->p_flag & P_STOPPED_SIG))) return; /* + * SIGKILL: Remove procfs STOPEVENTs. + */ + if (sig == SIGKILL) { + /* from procfs_ioctl.c: PIOCBIC */ + p->p_stops = 0; + /* from procfs_ioctl.c: PIOCCONT */ + p->p_step = 0; + wakeup(&p->p_step); + } + /* * Some signals have a process-wide effect and a per-thread * component. Most processing occurs when the process next * tries to cross the user boundary, however there are some > | | | | The LOR reported in | > | | | | PR kern/55175 needs | > | filedesc LOR | Not done | -- | to be fixed. | > | | | | Filedesc locking | > | | | | needs to be heavily | > | | | | reviewed in general. | Oy this thing... :) The only thing blocking this was that we need to access the filedesc as the process shuts down for nfs locks, Darwin has a workaround that I'll see if i can incorporate. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684