Re: kern/37799: Writing a large file to an NFS partition panics the kernel

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

The following reply was made to PR kern/37799; it has been noted by GNATS.

From: Reinoud Zandijk <reinoud%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/37799: Writing a large file to an NFS partition panics the 
kernel
Date: Wed, 23 Jan 2008 00:24:14 +0100

 Additional info with the aid of ddb and a few custom check functions:
 
 db{0}> trace
 breakpoint(cb0292a8,5,cb0292cc,c03fa9cb,c05d4d0f) at netbsd:breakpoint+0x4
 cpu_Debugger(c05d4d0f,cb0292d8,c0b60010,e0f,2) at netbsd:cpu_Debugger+0xb
 panic(c05c69b5,0,cb02931c,c036d04b,c09415dc) at netbsd:panic+0xcc
 _elem_check(c09415dc,7000010,c0b62040,c050bdc6,1) at 
 netbsd:_elem_check+0x1d
 uvm_pageinsert_after(c09415dc,0,cb02939c,c036ce2a,c09415dc) at 
 netbsd:uvm_pagein
 sert_after+0x192
 uvm_pageinsert(c09415dc,0,1,cb029378,cae29060) at 
 netbsd:uvm_pageinsert+0x19
 uvm_pagealloc_strat(cb01998c,1658000,0,0,0) at 
 netbsd:uvm_pagealloc_strat+0x450
 uvn_findpage(cb01998c,1658000,0,cb029674,0) at netbsd:uvn_findpage+0x76f
 uvn_findpages(cb01998c,1658000,0,cb0296c0,cb029674) at 
 netbsd:uvn_findpages+0xd6
 
 genfs_getpages(cb0298cc,1656007,0,c050bb11,7) at 
 netbsd:genfs_getpages+0x14f8
 nfs_getpages(cb0298cc,cae29060,43f63233,2b9fe75f,1658000) at 
 netbsd:nfs_getpages
 +0x197
 VOP_GETPAGES(cb01998c,1658000,0,cb0299b0,cb029a18) at 
 netbsd:VOP_GETPAGES+0x9a
 uvn_get(cb01998c,1658000,0,cb0299b0,cb029a18) at netbsd:uvn_get+0x417
 ubc_alloc(cb01998c,1658000,0,cb029a98,1) at netbsd:ubc_alloc+0xa21
 ubc_uiomove(cb01998c,cb029c4c,8000,1,106) at netbsd:ubc_uiomove+0x108
 nfs_write(cb029be0,cae29060,cb029bfc,c0450e13,cb01998c) at 
 netbsd:nfs_write+0x53
 a
 VOP_WRITE(cb01998c,cb029c4c,10,c9d84b40,cb01998c) at netbsd:VOP_WRITE+0x70
 vn_write(cae249d4,cae24a00,cb029c4c,c9d84b40,1) at netbsd:vn_write+0x142
 dofilewrite(4,cae249d4,804b760,10000,cae24a00) at netbsd:dofilewrite+0x8c
 sys_write(cae29060,cb029cf0,cb029ce8,cb029d00,c04c16de) at 
 netbsd:sys_write+0xd7
 
 syscall(cb029d48,b3,ab,1f,bfbf001f) at netbsd:syscall+0x1eb
 -------------
 
 Offending element 0xc09415dc is vm_page*, and the _elem_check is a check
 function i made that checked if an element is modified with the bad value.
 
 0xc036d030 <uvm_pageinsert_after+375>:  call   0xc010d0c0 <mutex_spin_enter>
 0xc036d035 <uvm_pageinsert_after+380>:  mov    0xffffffec(%ebp),%eax
 0xc036d038 <uvm_pageinsert_after+383>:  mov    %eax,(%esp)
 0xc036d03b <uvm_pageinsert_after+386>:  call   0xc036b31c <_pq_check>
 0xc036d040 <uvm_pageinsert_after+391>:  mov    0x8(%ebp),%eax
 0xc036d043 <uvm_pageinsert_after+394>:  mov    %eax,(%esp)
 0xc036d046 <uvm_pageinsert_after+397>:  call   0xc036b353 <_elem_check>
 0xc036d04b <uvm_pageinsert_after+402>:  mov    0x8(%ebp),%eax
 
 i.e. its before the TAILQ_INSERT() that means that the element inserted is
 detected to be corrupted.
 
 it gets called at uvm_pagealloc_strat+0x450 :
 (gdb) list *uvm_pagealloc_strat+0x450
 0xc036ce2a is in uvm_pagealloc_strat (../../../../uvm/uvm_page.c:1238).
 1233                    atomic_inc_uint(&uvmexp.anonpages);
 1234            } else {
 1235                    if (obj) {
 1236                            uvm_pageinsert(pg);
 1237                    }
 1238                    pg->pqflags = 0;
 1239            }
 1240    #if defined(UVM_PAGE_TRKOWN)
 1241            pg->owner_tag = NULL;
 1242    #endif
 
 vm_page *pg has been found faulty/corrupted here before the 
 uvm_pageinsert() and its not anon and associated with an obj. Could this 
 page be reused i.e. been released too early? or is it not cleaned after 
 reuse?
 
 db{0}> x/m c09415dc,68
 0xc09415dc:     cc1494c0 304babc0 40000000 00000000     ....0K..@.......
 0xc09415ec:     00000000 00000000 00000000 3c1706cb     ............<...
 0xc09415fc:     00e05001 00000000 49000000 00000100     ..P.....I.......
 0xc094160c:     0030ff03 01050000 00000000 00000000     .0..............
 0xc094161c:     00000000 14cc94c0 24cd94c0 00000000     ........$.......
 0xc094162c:     98a495c0 14cc94c0 34cd94c0 00000000     ........4.......
 0xc094163c:     e41406cb 00603401 00000000 84100000     .....`4.........
 0xc094164c:     00000002 0040ff03 01050000 00000000     .....@..........
 0xc094165c:     005084ca 01210000 541594c0 741794c0     .P...!..T...t...
 0xc094166c:     00000000 00000000 00000000 00000000     ................
 0xc094167c:     efbeadde efbeadde efbeadde 00000000     ................
 0xc094168c:     00000000 00000100 0050ff03 01050000     .........P......
 0xc094169c:     00000000 00000000 00000000 4cd894c0     ............L...
 0xc09416ac:     44e094c0 00000000 b886d3c9 4cd894c0     D...........L...
 0xc09416bc:     54e094c0 00000000 3c1706cb 00b03901     T.......<.....9.
 0xc09416cc:     00000000 0c000000 00000002 0060ff03     .............`..
 0xc09416dc:     01050000 00000000 00607bca 01000000     .........`{.....
 0xc09416ec:     dc1594c0 304babc0 00000000 3092d3c9     ....0K......0...
 0xc09416fc:     505e93c0 984893c0 00000000 3c1706cb     P^...H......<...
 0xc094170c:     00a05001 00000000 4d000000 00000000     ..P.....M.......
 0xc094171c:     0070ff03 01050000 00000000 00000000     .p..............
 0xc094172c:     00000000 24cd94c0 34ce94c0 00000000     ....$...4.......
 0xc094173c:     d08e95c0 24cd94c0 44ce94c0 00000000     ....$...D.......
 0xc094174c:     e41406cb 00403401 00000000 84100000     
.....%4.........@localhost
 0xc094175c:     00000002 0080ff03 01050000 00000000     ................
 0xc094176c:     00d084ca 01210000 641694c0 841894c0     .....!..d.......
 
 pageq struct is garbage (cc1494c0, 304babc0), hashq struct is garbage 
 (40000000, 00000000), listq is NULL (likely garbage), struct uanon* is NULL 
 (set in uvm_pagealloc_strat), struct uvm_obj *uobject is garbage 
 (3c1706cb), voff_t offset is GARBAGE (00e05001, 00000000) even though it 
 has just been set in uvm_pagealloc_strat (!!!!)...
 
 It looks like this struct has been overwritten by a former user of the 
 memory page now containing the vm_page struct.