From owner-freebsd-stable@FreeBSD.ORG Fri Dec 20 19:29:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E79E3265 for ; Fri, 20 Dec 2013 19:29:40 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B1C3C12D5 for ; Fri, 20 Dec 2013 19:29:40 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id r10so2935265pdi.10 for ; Fri, 20 Dec 2013 11:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bfNNLaRFMW/Zo9kt6uyQTHS2zlzlWz8p5bf6bj0nNkc=; b=wgqwFsePCo6SxJLHVrUiq6NX8hiSRdhwHguFoEmVtfp1PPOcJjQ3HyG9wrq2T/+VA/ hHTTVRKCxdrMLbo7wmvtdX/G8wJ1F1pgrqbyfT+GBTQ151cD8NRLR/bo7P1MdMhZM3Qf F3OkgCWDd1WVW/f/NqiJSChbaESF75LY8oTHw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bfNNLaRFMW/Zo9kt6uyQTHS2zlzlWz8p5bf6bj0nNkc=; b=XVHk4UGZaGWJqWGOXyXS0bYhhboCmkn/q+xtfVGPjmG/eP6x1Uy0IiTyomkouK+o6B EQ6KPsQpAMv8kwsNJqhHkNiSxWW0IJ+Z9UWMvNhT5Tf4kWUhLaQtNFbWCj6zywtwD8EY GJKqCvIR/R8p5WLDLDS3JOEvfTqYPElS0aAH9jmCIUa7VtYTTX5TH38FaWXPJEkyRLHf zZL2DaWjQkPkb70G0c2FXLs2l8IndfdNE2ayoZLWTailp7s4yd1cBt+zgEs5hOK4iZK3 ovFNgkMLWiS2HPq7/1Xk+j/8SnyLGQL6R/4AXcUZm+yy0fQB0HhV2e/LAjNV3tXAaAw2 JGgA== X-Gm-Message-State: ALoCoQnr/Oj4GmC9uMfetyhSB+ZrVR857g/cZuWkRojgaIBHyM6sCG3mqGgxZokKojjaCtMJXYLE MIME-Version: 1.0 X-Received: by 10.68.189.165 with SMTP id gj5mr10434822pbc.111.1387567780245; Fri, 20 Dec 2013 11:29:40 -0800 (PST) Received: by 10.66.162.3 with HTTP; Fri, 20 Dec 2013 11:29:40 -0800 (PST) In-Reply-To: <20131220162254.GT59496@kib.kiev.ua> References: <20131217120019.GD59496@kib.kiev.ua> <1387285472.2372.2.camel@powernoodle.corp.yahoo.com> <1387473915.2494.0.camel@powernoodle.corp.yahoo.com> <20131219180833.GN59496@kib.kiev.ua> <1387479064.2494.5.camel@powernoodle.corp.yahoo.com> <1387492541.27693.5.camel@powernoodle.corp.yahoo.com> <20131220094835.GR59496@kib.kiev.ua> <1387554355.1491.4.camel@powernoodle.corp.yahoo.com> <20131220162254.GT59496@kib.kiev.ua> Date: Fri, 20 Dec 2013 11:29:40 -0800 Message-ID: Subject: Re: 10.0 BETA 3 with redports kernel panic From: Peter Wemm To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 19:29:41 -0000 On Fri, Dec 20, 2013 at 8:22 AM, Konstantin Belousov wrote: > On Fri, Dec 20, 2013 at 07:45:55AM -0800, Sean Bruno wrote: >> With this change to pmap.c we blow up in keg_alloc_slab() now: >> >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> kernel trap 12 with interrupts disabled >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x8 >> fault code = supervisor write data, page not present >> instruction pointer = 0x20:0xffffffff80b2602a >> stack pointer = 0x28:0xffffffff81a90a50 >> frame pointer = 0x28:0xffffffff81a90ac0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 0 () >> [ thread pid 0 tid 0 ] >> Stopped at keg_alloc_slab+0x13a: movq %r13,0x8(%rax) >> db> whe >> Tracing pid 0 tid 0 td 0xffffffff81527500 >> keg_alloc_slab() at keg_alloc_slab+0x13a/frame 0xffffffff81a90ac0 >> keg_fetch_slab() at keg_fetch_slab+0x152/frame 0xffffffff81a90b10 >> zone_fetch_slab() at zone_fetch_slab+0x7e/frame 0xffffffff81a90b50 >> zone_import() at zone_import+0x3c/frame 0xffffffff81a90b90 >> uma_zalloc_arg() at uma_zalloc_arg+0x33e/frame 0xffffffff81a90c10 >> malloc() at malloc+0x6a/frame 0xffffffff81a90c60 >> init_dynamic_kenv() at init_dynamic_kenv+0x8d/frame 0xffffffff81a90c90 >> mi_startup() at mi_startup+0x118/frame 0xffffffff81a90cb0 >> btext() at btext+0x2c >> db> bt >> Tracing pid 0 tid 0 td 0xffffffff81527500 >> keg_alloc_slab() at keg_alloc_slab+0x13a/frame 0xffffffff81a90ac0 >> keg_fetch_slab() at keg_fetch_slab+0x152/frame 0xffffffff81a90b10 >> zone_fetch_slab() at zone_fetch_slab+0x7e/frame 0xffffffff81a90b50 >> zone_import() at zone_import+0x3c/frame 0xffffffff81a90b90 >> uma_zalloc_arg() at uma_zalloc_arg+0x33e/frame 0xffffffff81a90c10 >> malloc() at malloc+0x6a/frame 0xffffffff81a90c60 >> init_dynamic_kenv() at init_dynamic_kenv+0x8d/frame 0xffffffff81a90c90 >> mi_startup() at mi_startup+0x118/frame 0xffffffff81a90cb0 >> btext() at btext+0x2c >> > > This could be related, indeed. > > Lets limit the impact to the /dev/{,k}mem only. Please try this. > > diff --git a/sys/amd64/amd64/mem.c b/sys/amd64/amd64/mem.c > index abbbb21..2a9b7c1 100644 > --- a/sys/amd64/amd64/mem.c > +++ b/sys/amd64/amd64/mem.c > @@ -98,7 +98,11 @@ memrw(struct cdev *dev, struct uio *uio, int flags) > kmemphys: > o = v & PAGE_MASK; > c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o)); > - error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio); > + v = PHYS_TO_DMAP(v); > + if (v < DMAP_MIN_ADDRESS || v >= dmaplimit || > + pmap_kextract(v) == 0) > + return (EFAULT); > + error = uiomove((void *)v, (int)c, uio); > continue; > } > else if (dev2unit(dev) == CDEV_MINOR_KMEM) { > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 014020b..13404b0 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -321,7 +321,7 @@ SYSCTL_INT(_machdep, OID_AUTO, nkpt, CTLFLAG_RD, &nkpt, 0, > "Number of kernel page table pages allocated on bootup"); > > static int ndmpdp; > -static vm_paddr_t dmaplimit; > +vm_paddr_t dmaplimit; > vm_offset_t kernel_vm_end = VM_MIN_KERNEL_ADDRESS; > pt_entry_t pg_nx; > > diff --git a/sys/amd64/include/pmap.h b/sys/amd64/include/pmap.h > index 3918282..e83e07e 100644 > --- a/sys/amd64/include/pmap.h > +++ b/sys/amd64/include/pmap.h > @@ -369,6 +369,7 @@ extern vm_paddr_t phys_avail[]; > extern vm_paddr_t dump_avail[]; > extern vm_offset_t virtual_avail; > extern vm_offset_t virtual_end; > +extern vm_paddr_t dmaplimit; > > #define pmap_page_get_memattr(m) ((vm_memattr_t)(m)->md.pat_mode) > #define pmap_page_is_write_mapped(m) (((m)->aflags & PGA_WRITEABLE) != 0) The reason why the dmaplimit change originally exploded was becase dmaplimit is set to zero for the duration of while we're running on the page tables given to us by the loader. I believe initializing dmaplimit to DMAP_MAX_ADDRESS rather than zero would have solved the original explosions. There's far more rotten things here though. :( -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV Yes, I know, gmail sucks now. If you see this then I forgot. Habits are hard to break.