From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 5 12:16:52 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB5D106566B for ; Tue, 5 Oct 2010 12:16:52 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6CBF68FC14 for ; Tue, 5 Oct 2010 12:16:51 +0000 (UTC) Received: by wyb29 with SMTP id 29so5527453wyb.13 for ; Tue, 05 Oct 2010 05:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=01RRSsRRz/FO+RwEKxrxQJ2g6ndyTGycQSFCWKcIwio=; b=MukF2cPgSewkbFA1RrQ9c3q5PThBNDRgDJ9GAas0z5prJp5EdgJhJvE2yYHKmY22WE /2bzFVhj3ABfr/k0V6+gr0sB5uGMwJedghFkeJFX0KDixtrsk0peMClbR+GDEvTHEyYB 93ItTY4ms3r2EsaSNSeooh92mJ36ANdFgFTog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PPdlRZ6VsuJEz9gnlYVlSPF7x5XEeaZFfA8XpZoywgSCgHkNGABY30cOysRtWidXph CkcEw3JhbEWn5CJSz5cpAm0M1ng4V7z9s5kh18t0aDK84wluOQJjJkrqfckMXkBCWBb3 P+vAPDJpzLST2KS4ebiynbgbaY4mi/6vWb4bg= MIME-Version: 1.0 Received: by 10.216.187.130 with SMTP id y2mr945137wem.60.1286281011162; Tue, 05 Oct 2010 05:16:51 -0700 (PDT) Received: by 10.216.172.210 with HTTP; Tue, 5 Oct 2010 05:16:51 -0700 (PDT) In-Reply-To: References: <29760054.post@talk.nabble.com> Date: Tue, 5 Oct 2010 14:16:51 +0200 Message-ID: From: Svatopluk Kraus To: alc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: page table fault, which should map kernel virtual address space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 12:16:52 -0000 On Mon, Oct 4, 2010 at 2:03 AM, Alan Cox wrote: > On Thu, Sep 30, 2010 at 6:28 AM, Svatopluk Kraus wrote= : >> >> On Tue, Sep 21, 2010 at 7:38 PM, Alan Cox wrote: >> > On Mon, Sep 20, 2010 at 9:32 AM, Svatopluk Kraus >> > wrote: >> >> Beyond 'kernel_map', some submaps of 'kernel_map' (buffer_map, >> >> pager_map,...) exist as result of 'kmem_suballoc' function call. >> >> When this submaps are used (for example 'kmem_alloc_nofault' >> >> function) and its virtual address subspace is at the end of >> >> used kernel virtual address space at the moment (and above 'NKPT' >> >> preallocation), then missing page tables are not allocated >> >> and double fault can happen. >> >> >> > >> > No, the page tables are allocated.=A0 If you create a submap X of the >> > kernel >> > map using kmem_suballoc(), then a vm_map_findspace() is performed by >> > vm_map_find() on the kernel map to find space for the submap X.=A0 As = you >> > note >> > above, the call to vm_map_findspace() on the kernel map will call >> > pmap_growkernel() if needed to extend the kernel page table. >> > >> > If you create another submap X' of X, then that submap X' can only map >> > addresses that fall within the range for X.=A0 So, any necessary page >> > table >> > pages were allocated when X was created. >> >> You are right. Mea culpa. I was focused on a solution and made >> too quick conclusion. The page table fault hitted in 'pager_map', >> which is submap of 'clean_map' and when I debugged the problem >> I didn't see a submap stuff as a whole. >> >> > That said, there may actually be a problem with the implementation of >> > the >> > superpage_align parameter to kmem_suballoc().=A0 If a submap is create= d >> > with >> > superpage_align equal to TRUE, but the submap's size is not a multiple >> > of >> > the superpage size, then vm_map_find() may not allocate a page table >> > page >> > for the last megabyte or so of the submap. >> > >> > There are only a few places where kmem_suballoc() is called with >> > superpage_align set to TRUE.=A0 If you changed them to FALSE, that is = an >> > easy >> > way to test this hypothesis. >> >> Yes, it helps. >> >> My story is that the problem started up when I updated a project >> ('coldfire' port) >> based on FreeBSD 8.0. to FreeBSD current version. In the current version >> the 'clean_map' submap is created with superpage_align set to TRUE. >> >> I have looked at vm_map_find() and debugged the page table fault once >> again. >> IMO, it looks that a do-while loop does not work in the function as >> intended. >> A vm_map_findspace() finds a space and calls pmap_growkernel() if needed= . >> A pmap_align_superpage() arrange the space but never call >> pmap_growkernel(). >> A vm_map_insert() inserts the aligned space into a map without error >> and never call pmap_growkernel() and does not invoke loop iteration. >> >> I don't know too much about an idea how a virtual memory model is >> implemented >> and used in other modules. But it seems that it could be more reasonable >> to >> align address space in vm_map_findspace() internally and not to loop >> externally. >> >> I have tried to add a check in vm_map_insert() that checks the 'end' >> parameter >> against 'kernel_vm_end' variable and returns KERN_NO_SPACE error if >> needed. >> In this case the loop in vm_map_find() works and I have no problem with >> the page table fault. But 'kernel_vm_end' variable must be initializated >> properly before first use of vm_map_insert(). The 'kernel_vm_end' variab= le >> can be self-initializated in pmap_growkernel() in FreeBSD 8.0 (it is too >> late), >> but it was changed in current version ('i386' port). >> >> Thanks for your answer, but I'm still looking for permanent >> and approved solution. > > I have a patch that implements one possible fix for this problem.=A0 I'll > probably commit that patch in the next day or two. > > Regards, > Alan I tried your patch and it works. Many thanks. Regards, Svata