Re: SCHEDULE and high load situations

Don Lewis wrote:
> On 12 Aug, Martin Blapp wrote:
>>
>>Here is more information: (thanks robert for the help)
>>
>>>Fatal trap 12: page fault while in kernel mode
>>>cpuid = 1; apic id = 01
>>>fault virtual address   = 0x14
>>>fault code              = supervisor write, page not present
>>>instruction pointer     = 0x8:0xc066a1c7
>>>stack pointer           = 0x10:0xe2626aa8
>>>frame pointer           = 0x10:0xe2626ab8
>>>code segment            = base 0x0, limit 0xfffff, type 0x1b
>>>                        = DPL 0, pres 1, def32 1, gran 1
>>>processor eflags        = interrupt enabled, resume, IOPL = 0
>>>current process         = 27897 (mimedefang)
>>>
>>
>>db> where
>>unp_connect2(c4bb78a4,c39cc13c,0,0,0) at /usr/src/sys/kern/uipc_usrreq.c:892
>>unp_connect(c4bb78a4,c43d9380,c4dee9a0,c43d9380,80) at /usr/src/sys/kern/uipc_usrreq.c:865
>>uipc_connect(c4bb78a4,c43d9380,c4dee9a0) at /usr/src/sys/kern/uipc_usrreq.c:179
>>soconnect(c4bb78a4,c43d9380,c4dee9a0,0,bf1dad88) at /usr/src/sys/kern/uipc_socket.c:518
>>kern_connect(c4dee9a0,3,c43d9380,c43d9380,c3e958ac) at /usr/src/sys/kern/uipc_syscalls.c:477
>>connect(c4dee9a0,e2626d14,c,c4dee9a0,e2626d3c) at connect+0x42
>>syscall(2f,2f,2f,bf1dad88,bf1dad8a) at syscall+0x300
>>Xint0x80_syscall() at Xint0x80_syscall+0x1f
>>--- syscall (98, FreeBSD ELF32, connect), eip = 0x28101d23, esp = 0xbf1dad74, ebp = 0xbf1dae10 ---
>>
>>src/sys/kern/uipc_syscalls.c,v 1.199
>>src/sys/kern/uipc_usrreq.c,v 1.135
>>src/sys/kern/uipc_socket.c,v 1.207
>>
>>(gdb) l *unp_connect2+0x2a
>>0x1f93 is in unp_connect2 (/usr/src/sys/kern/uipc_usrreq.c:892).
>>887             UNP_LOCK_ASSERT();
>>888
>>889             if (so2->so_type != so->so_type)
>>890                     return (EPROTOTYPE);
>>891             unp2 = sotounpcb(so2);
>>892             unp->unp_conn = unp2;
>>893             switch (so->so_type) {
>>894
>>895             case SOCK_DGRAM:
>>896                     LIST_INSERT_HEAD(&unp2->unp_refs, unp, unp_reflink);
> 
> 
> Looks like unp is NULL here.
> 
> My first suspicion would be the recent memory allocation changes that
> affected the type safety of various dynamically allocated data
> structures, though I'm not sure that fits the symptoms.

I have backed out the change this morning (GMT) because of concernes of this.
It looks like the code accesses free'd memory or uninitialized memory.  This
might have worked in the SPL days but today with SMP it's tough.  You never
know if the free'd memory has been allocated again already somewhere else
even if it is type-stable.

-- 
Andre