Re: 5.3-RELEASE TODO

From: Alfred Perlstein <alfred_at_freebsd.org>
Date: Fri, 1 Oct 2004 01:31:44 -0700
* Scott Long <scottl_at_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
_at__at_ -1775,6 +1775,16 _at__at_
 	    !((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_at_mu.org cell: 408-480-4684
Received on Fri Oct 01 2004 - 06:31:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC