From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 10 18:01:29 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AE7F16A4CE for ; Wed, 10 Nov 2004 18:01:29 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B5A43D4C for ; Wed, 10 Nov 2004 18:01:28 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) iAAI1SvA061884 for ; Wed, 10 Nov 2004 10:01:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id iAAI1SkK061883; Wed, 10 Nov 2004 10:01:28 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Nov 2004 10:01:28 -0800 (PST) From: Matthew Dillon Message-Id: <200411101801.iAAI1SkK061883@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: bugs in contigmalloc*() related to "page not found in hash" panics X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2004 18:01:29 -0000 I've tracked down several bugs in contigmalloc*() in DragonFly based on kernel cores provided by David Rhodus. These bugs have just been addressed in DFly but also need to be addressed in FreeBSD-4, and at least some work must also be done in FreeBSD-5/6. So someone needs to take up the ball and deal with this in FreeBSD. Here is the DragonFly commit. http://www.dragonflybsd.org/cvsweb/src/sys/vm/vm_contig.c.diff?r1=1.10&r2=1.11&f=u FreeBSD-4: FreeBSD-4 is in the same situation that DFly was in and requires the same fixes as the above patch, though note that in FreeBSD-4 the contigmalloc() code is in vm_page.c, not vm_contig.c. FreeBSD-5/6: FreeBSD-5/6 may also has issues, though it is likely that they are masked by later checks done in FreeBSD-5/6's contigmalloc code. The main issue is the attempt to reuse a PQ_CACHE page by unconditionally vm_page_free()ing it without checking to see if it is held, busied, or anything else. This sounds a bit dangerous to me since vm_page_select_cache() does NOT do this. I recommend that FreeBSD-5/6's contigmalloc code be adjusted similar to vm_page_select_cache() and not try to free cache pages which are held or busied or otherwise in a weird state. FreeBSD-5/6 *DOES* recheck that the pages are PQ_FREE before it actually reallocates them, and this may be its saving grace (since vm_page_free() might have moved the page to PQ_HOLD this recheck should catch the incorrect cache->free cases). But it is unclear whether the PQ_CACHE -> vm_page_free() code above was itself safe so it may be better to be safe then sorry. You also need to replace the unconditional 'm->object = NULL' with an assertion that m->object is already NULL, because if m->object isn't NULL it means that the page is in the VM page bucket hash table and NULLing out the object is guarenteed to corrupt the hash table. Note in particular the symptoms of the contigmalloc() problem: * "page not found in hash" panics (due to VM bucket hash table corruption). * Memory corruption, particularly filesystem corruption since those are the most likely pages to be in a held state while on the free list. Due to a page being reused before it is reusable. If you have either of these two symptoms in FreeBSD-5/6 then you need to take a very close look at your contigmalloc() code, even if you think it is correct. -Matt Matthew Dillon