From owner-freebsd-hackers@freebsd.org Fri Jul 15 19:44:00 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27EBCB9843B for ; Fri, 15 Jul 2016 19:44:00 +0000 (UTC) (envelope-from arlie@worldash.org) Received: from ansuz.worldash.org (ansuz.worldash.org [198.144.201.100]) by mx1.freebsd.org (Postfix) with ESMTP id 075721F6B for ; Fri, 15 Jul 2016 19:43:59 +0000 (UTC) (envelope-from arlie@worldash.org) Received: by ansuz.worldash.org (Postfix, from userid 1000) id 3C23CE2E7B; Fri, 15 Jul 2016 12:52:35 -0700 (PDT) Date: Fri, 15 Jul 2016 12:52:35 -0700 From: Arlie Stephens To: freebsd-hackers@freebsd.org Subject: Re: Zone Allocator Initialization Question Message-ID: <20160715195235.GA7003@worldash.org> References: <20160714210448.GA16971@worldash.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160714210448.GA16971@worldash.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:44:00 -0000 Never mind. This is beautiful code; very easy to follow. I'm now self-educated on zone allocator initialization. If I'd realized it would be this clear, I wouldn't have bothered the list by posting a query. Kudos to the authors. --Arlie On Jul 14 2016, Arlie Stephens wrote: > > Hi Folks, > > I'm chasing yet another kernel memory corruption in an obsolete > version of FreeBSD (8.4 in this case). I expect that it will turn out > to be a bug in some local customization, as they usually are. So I'm > not looking for help with actually debugging it ;-) > > What I would like help with is understanding something my > instrumentation is reporting, on systems that don't appear to have the > problem. > > In brief, I'm seeing what appears to be uma_zalloc() returning a > pointer to a virtual address that does not have PG_SLAB set on the > vm_page_t for the corresponding physical page. > > Most allocations from that zone are fine; I only see one strange one, > and that's fairly early in the system lifetime. (It's one of the > "struct file" for files opened by init.) > > Is there some kind of bootstrap situation with the zone allocator, > where certain early use zones get their first memory via a path that > doesn't mark PG_SLAB? And if so, is there any other way to recognize > those addresses as coming from a zone? (My corruption is scribbling on > process' fd_ofiles[] arrays, so I'm trying to write a sanity checker, > and was really surprised to find a valid-seeming struct file * that > didn't appear to have come from the right place.) > > Thanks in advance for any enlightenment. > -- Arlie (Arlie Stephens arlie@worldash.org)