Date: Fri, 1 Oct 2004 01:31:44 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: re@FreeBSD.org Cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO Message-ID: <20041001083144.GT39252@elvis.mu.org> In-Reply-To: <200410010741.i917fJUo076107@pooker.samsco.org> References: <200410010741.i917fJUo076107@pooker.samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Scott Long <scottl@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041001083144.GT39252>