:I don't see how 2 could make break the API - all a process in this
:state can do is spin trying to serve SIGBUSs. I think HPUX may KILL
:processes in this state. Yep, on HPUX 10.10 when I run my test
:program (included at the bottom of this mail) I get:
:
:Pid 2717 was killed due to failure in writing the signal context.
:
:Solaris 2.6 gives a bus error. AIX and Digital Unix have the same
:behavior as FreeBSD. Linux either does what FreeBSD does or core
:dumps depending on the address of the SIGBUS handler I give it.
:I'd like to see what NTs POSIX subsystem does...
:
:BTW - don't run the test program on a -CURRENT machine unless you've
:recompiled the kernel today. There was a bug which alowd processes
:to catch SIGKILL, and it results in the process being unkillable.

    Oh, sure, during stacking.  I was thinking of processes which
    catch SIGBUS and then do something inside their signal handler
    which may SIGBUS again.  That sort of recursion is legal.

:Init got stuck in vmopar while doing a wait on a 3.2-STABLE machine.
:We haven't managed to do this reproduceably, but the first stuck
:zombie was a process which had suffered from the "vm_fault: pager
:read error" problem which someone had kill -9'ed.
:
:We do have a trace from a 4.0 machine with a normal process stuck
:in vmopar. I've tacked that on the bottom too. The problems may
:be similar. I don't understand why waiting on a zombie would
:require the text of the program at all - but I haven't looked at
:the code so.

    The vmopar lockup is a known bug.  If the underlying vnode changes
    out from under a vm_fault a client can get into trouble.

> (earlier email written by Matt in May 99)
>     The problem is a same-process deadlock.  A VM fault occurs accessing a
>     NFS-backed page.  The fault locks (PG_BUSY's) the page in question then
>     calls vnode_pager_getpages() to bring the page in.  This filters down
>     into an nfs_getpages() call which then calls nfs_readrpc().
> 
>     nfs_readrpc() normally ( and properly ) tries to keep the vnode 
>     synchronized to the NFS state returned by the RPC.  The problem is that
>     if the state indicates that the server has truncated the file,
>     vnode_pager_setsize() will be called and will attempt to remove all
>     the pages beyond the truncation point from the VM object.
> 
>     Unfortunately, at least one of those pages has been locked by the same
>     process.  Bewm.  Deadlock.

    Did I never fix this problem?  May was a bad month.  This is still an 
    open problem.

                                        -Matt
                                        Matthew Dillon 
                                        <dil...@backplane.com>

:       David.

:... (from 4.0 box panic)
:    wmesg=0xc0250b91 "vmopar", timo=0) at ../../kern/kern_synch.c:443
:#2  0xc01e2caf in vm_object_page_remove (object=0xc87baf3c, start=0, end=978, 
:    clean_only=0) at ../../vm/vm_page.h:536
:#3  0xc01e7449 in vnode_pager_setsize (vp=0xc8760980, nsize=0)
:    at ../../vm/vnode_pager.c:285
:#4  0xc01ad117 in nfs_loadattrcache (vpp=0xc86aedbc, mdp=0xc86aedc8, 
:    dposp=0xc86aedcc, vaper=0x0) at ../../nfs/nfs_subs.c:1383
:#5  0xc01b5f80 in nfs_readrpc (vp=0xc8760980, uiop=0xc86aee30, cred=0xc0ac6580)
:    at ../../nfs/nfs_vnops.c:1086
:#6  0xc018def5 in nfs_getpages (ap=0xc86aee6c) at ../../nfs/nfs_bio.c:154
:#7  0xc01e79fe in vnode_pager_getpages (object=0xc87baf3c, m=0xc86aef00, 
:    count=1, reqpage=0) at vnode_if.h:1067
:#8  0xc01dc158 in vm_fault (map=0xc7c5ff80, vaddr=134512640, 
:    fault_type=1 '\001', fault_flags=0) at ../../vm/vm_pager.h:130
:#9  0xc0214a14 in trap_pfault (frame=0xc86aefa8, usermode=1, eva=134513640)
:    at ../../i386/i386/trap.c:781
:#10 0xc02145a3 in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
:      tf_edi = -1077945600, tf_esi = -1077945608, tf_ebp = -1077945652, 
:      tf_isp = -932515884, tf_ebx = 1, tf_edx = 1, tf_ecx = 0, tf_eax = 10, 
:      tf_trapno = 12, tf_err = 4, tf_eip = 134513640, tf_cs = 31, 
:      tf_eflags = 66118, tf_esp = -1077945652, tf_ss = 47})
:    at ../../i386/i386/trap.c:349
:#11 0x80483e8 in ?? ()
:#12 0x804837d in ?? ()
:



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to