Re: try KMGUARD and debug_freecheck=1

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> > I tried on a amd64 host with 8GB RAM (looks like I expanded the i386
> > tests.tgz instead of amd64 but it shouldn't matter). I got a panic
> > while running the stress_long test, but not from kmemguard
> > unforntunably:
> 
> And another one:
> login: uvm_fault(0xffffffff80e7c960, 0xffff800015787000, 1) -> e
> fatal page fault in supervisor mode
> trap type 6 code 0 rip ffffffff80113f8e cs 8 rflags 10206 cr2
> ffff800015787000 cpl 0 rsp fffffe810c72fa28 kernel: page fault trap,
> code=0 Stopped in pid 1063.4 (h_reconcli) at   netbsd:copystr+0xe:
> lodsb   (%rsi) db{6}> tr
> copystr() at netbsd:copystr+0xe
> unp_connect() at netbsd:unp_connect+0x90
> uipc_usrreq() at netbsd:uipc_usrreq+0x238
> do_sys_connect() at netbsd:do_sys_connect+0x8d
> sys_connect() at netbsd:sys_connect+0x38
> syscall() at netbsd:syscall+0xac

This looks like potentially a real bug found by KMGUARD.  I have not had
time to inspect the code yet..  Keep in mind that KMGUARD forces defective
code (e.g. which overruns a buffer or uses the memory after free) at the
moment it does that.

Also, there is another debugging facility.  Try setting debug_freecheck
to 1 early in DDB.  I wonder if we are doing good enough job in catching
wrong kmem_free() arguments.

-- 
Mindaugas