From owner-freebsd-current@FreeBSD.ORG Fri Jan 25 19:23:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226AD16A473 for ; Fri, 25 Jan 2008 19:23:19 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id C363E13C4CC for ; Fri, 25 Jan 2008 19:23:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m0PIsM8F082488; Fri, 25 Jan 2008 11:54:22 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <479A305E.3020801@samsco.org> Date: Fri, 25 Jan 2008 11:54:22 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Ruslan Ermilov References: <20080125180740.GA1646@team.vega.ru> In-Reply-To: <20080125180740.GA1646@team.vega.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 25 Jan 2008 11:54:22 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: minidumps are unsafe on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2008 19:23:19 -0000 Ruslan Ermilov wrote: > Hi, > > Kernel minidumps on amd64 SMP can write beyond the bounds > of the configured dump device causing (as in our case) the > file system data following swap partition to be overwritten > with the dump contents. > > The problem is that while we're in the process of dumping > mapped physical pages via a bitmap (in minidump_machdep.c), > other CPUs continue to work and may modify page mappings of > processes. This in turn causes the modifications to > pv_entries, which in turn modifies the bitmap of pages to > dump. As the result, we can dump more pages than we've > calculated, and since dumps are written to the end of the > dump device, we may end up overwriting it. > > The attached patch mitigates the problem, but the real solution > seems to be to disable interrupts (there's an XXX about this > in kern_shutdown.c before calling doadump()), and stopping > other CPUs, so we don't modify page tables while we're dumping. > > This only affects 7.x/8.x amd64 SMP systems configured with > minidump. i386 systems aren't affected. > Is this a case where you are manually triggering a dump on a system that is otherwise running fine? I thought that crashes already disabled interrupts and made an attempt to stop other CPUs. That's why there is dump-specific code in every storage driver in the first place; it implements polled i/o so that crashdump i/o can take place with interrupts disabled. If it's a case where interrupts aren't actually getting disabled, then that's one thing. If it's a case where you're trying to fix something that isn't broken, then I'm very cautious about the added complexity that you're proposing. Scott