From owner-freebsd-stable@FreeBSD.ORG Mon Sep 9 15:39:23 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3A40AA7A for ; Mon, 9 Sep 2013 15:39:23 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 053B62EF1 for ; Mon, 9 Sep 2013 15:39:22 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id fb19so5932039obc.24 for ; Mon, 09 Sep 2013 08:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rUC9NhyrhQwF1SRhAic6WptGEVCX8nKvPZqHyBJFT90=; b=aJSF8Yc+Qsoyl5buH5GvMqeam9KReiLgC4sKiErDQPlZotu3CN2K5hGrYzBWrPRCHM x2kQFK43Uh3gtM07g4isvNaziIYC5hGsupoThWHQuwgPJU8OsWO4wowS9GoSXi3yQFTm 3QRHYMIBnDh43KU0Go4FlOiCeKunLlxzjqM2NhVh9Kyy8loXI8dQ6N5MeeDqinJ5lBgi 8EpdJcH7jdYB6xTSSq2kYurEHfoElMLYTfKNuf5hJyzU9ot560XCGvELCncaO/2s6CPR +ekOzATFOYCZtlCJd776oWpASGS/Ldt4A5FYzkqy0/0MK4iWcGKXfKukYx6wrvbTq3zv 6P8g== MIME-Version: 1.0 X-Received: by 10.182.16.201 with SMTP id i9mr1793570obd.21.1378741162254; Mon, 09 Sep 2013 08:39:22 -0700 (PDT) Received: by 10.182.22.161 with HTTP; Mon, 9 Sep 2013 08:39:22 -0700 (PDT) In-Reply-To: <20130909071112.GI41229@kib.kiev.ua> References: <20130909051444.GG41229@kib.kiev.ua> <20130909071112.GI41229@kib.kiev.ua> Date: Mon, 9 Sep 2013 17:39:22 +0200 Message-ID: Subject: Re: 9.2-STABLE: supervisor read data, page not present From: Oliver Pinter To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:39:23 -0000 On 9/9/13, Konstantin Belousov wrote: > On Mon, Sep 09, 2013 at 08:45:21AM +0200, Oliver Pinter wrote: >> On 9/9/13, Konstantin Belousov wrote: >> > On Sun, Sep 08, 2013 at 11:40:01PM +0200, Oliver Pinter wrote: >> >> #6 0xffffffff806a2ab3 in cpuctl_ioctl (dev=, >> >> cmd=, data=, flags=0, >> >> td=) at /usr/src/sys/dev/cpuctl/cpuctl.c:478 >> >> cpu = >> >> ret = >> > >> > Do you indeed posses VIA CPU ? Was it due to some violence act ? >> >> Nope, this is an Intel Q9300. >> >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.76-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x10677 Family = 0x6 Model = 0x17 >> Stepping = 7 >> >> Features=0xbfebfbff >> >> Features2=0x8e3fd >> AMD Features=0x20100800 >> AMD Features2=0x1 >> TSC: P-state invariant, performance statistics >> real memory = 4294967296 (4096 MB) >> avail memory = 4103024640 (3912 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> FreeBSD/SMP: 1 package(s) x 4 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> cpu2 (AP): APIC ID: 2 >> cpu3 (AP): APIC ID: 3 > Intel update code has the same issue. Still, it is weird that the debugger > reported the line from the update_via(). > >> >> >> > >> > I am not sure about the first panic, lets fix the malloc/free >> > corruption >> > and see. The proc_reap() issue might be a consequence of the memory >> > corruption from the wrong free(). >> > >> > There is no public documentation for VIA CPUs, at least I was not >> > able to find anything when I looked. According to the comment in the >> > update_via(), all what is needed is that update buffer was 4-bytes >> > aligned, which is always guaranteed by our malloc(9), at least for the >> > allocation of size >=4. >> > >> > Try this. > > Updated patch. > > diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c > index 4e5abb2..317fc08 100644 > --- a/sys/dev/cpuctl/cpuctl.c > +++ b/sys/dev/cpuctl/cpuctl.c > @@ -295,10 +295,10 @@ cpuctl_do_update(int cpu, cpuctl_update_args_t *data, > struct thread *td) > static int > update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td) > { > - void *ptr = NULL; > + void *ptr; > uint64_t rev0, rev1; > uint32_t tmp[4]; > - int is_bound = 0; > + int is_bound; > int oldcpu; > int ret; > > @@ -312,10 +312,11 @@ update_intel(int cpu, cpuctl_update_args_t *args, > struct thread *td) > } > > /* > - * 16 byte alignment required. > + * 16 byte alignment required. Rely on the fact that > + * malloc(9) always returns the pointer aligned at least on > + * the size of the allocation. > */ > ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK); > - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf)); > if (copyin(args->data, ptr, args->size) != 0) { > DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", > __LINE__, args->data, ptr, args->size); > @@ -408,10 +409,10 @@ fail: > static int > update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) > { > - void *ptr = NULL; > + void *ptr; > uint64_t rev0, rev1, res; > uint32_t tmp[4]; > - int is_bound = 0; > + int is_bound; > int oldcpu; > int ret; > > @@ -427,8 +428,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct > thread *td) > /* > * 4 byte alignment required. > */ > - ptr = malloc(args->size + 16, M_CPUCTL, M_WAITOK); > - ptr = (void *)(16 + ((intptr_t)ptr & ~0xf)); > + ptr = malloc(args->size, M_CPUCTL, M_WAITOK); > if (copyin(args->data, ptr, args->size) != 0) { > DPRINTF("[cpuctl,%d]: copyin %p->%p of %zd bytes failed", > __LINE__, args->data, ptr, args->size); > Thanks, this patch fixed the issue.