From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 15:20:23 2010 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 BC8FC1065693; Thu, 14 Oct 2010 15:20:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1196B8FC25; Thu, 14 Oct 2010 15:20:21 +0000 (UTC) Received: by qwe4 with SMTP id 4so3482780qwe.13 for ; Thu, 14 Oct 2010 08:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aGR+ahDzDeBmYoN2FBFGhAYTsSu0bowfGBkF05Qxdp8=; b=MYEehXmmjpYjbFUjyrxhICH0fwkA9J+fZb3By1kOMJuCIzMhFcDWCWTD+lx7VGalKz wok5lZS9CNSQ9BYVDZ5vmEKY9oqr17pPclnR0DIGhT4ggGRxn+5AF95XI9Fwie7rq3YB kEoOlter0JGnzM2lFDSjd+Nx7Wm81qql150cI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OkJAU5GANxCzsAvSSffUzfry8mOndjzLWel/8gpZQbh3mVEPUnfu6dKIH/EvGewuxc Y+O8n6WJECwqNBhgjT6A8CNcWaua2wd0L2laUh4vcp6eQGNYO4Zj2xEUOR0a4RoyOK5e E+ExxR0dhuk/+Ek/Zjw/PyHiHZ+BUyYKxL/Yo= MIME-Version: 1.0 Received: by 10.224.29.4 with SMTP id o4mr830471qac.38.1287069621115; Thu, 14 Oct 2010 08:20:21 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 14 Oct 2010 08:20:19 -0700 (PDT) In-Reply-To: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> Date: Thu, 14 Oct 2010 17:20:19 +0200 X-Google-Sender-Auth: EALIKnMFJ19fQUtHNvbKXUyJay0 Message-ID: From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version 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: Thu, 14 Oct 2010 15:20:23 -0000 2010/10/14 Robert N. M. Watson : > > On 14 Oct 2010, at 15:10, Attilio Rao wrote: > >>> My concern is less about occasional lost dumps that destabilising the d= umping process: calls into the memory allocator can currently trigger a lot= of interesting behaviours, such as further calls back into the VM system, = which can then trigger calls into other subsystems. What I'm suggesting is = that if we want the mbuf allocator to be useful in this context, we need to= teach it about things not to do in the dumping / crash / ... context, whic= h probably means helping uma out a bit in that regard. And a watchdog to ma= ke sure the dump is making progress. >> >> I think that this would be way too complicated just to cope with panic >> within the VM/UMA (not sure what other subsystems you are referring >> to, wrt supposed to call). Besides, if we have a panic in the VM I'm >> sure that normal dumps could also be affected. >> When dealing with netdump, I'm not trying to fix all the bugs related >> to our dumping infrastructure because, as long as we already >> discussed, we know there are quite a few of them, but trying at least >> to follow the same fragile-ness than what we have today. >> And again, while I think the "watchdog" idea is good, I think it still >> applies to normal dumps too, it is not specific to netdump. > > No, what I'm saying is: UMA needs to not call its drain handlers, and ide= ally not call into VM to fill slabs, from the dumping context. That's easy = to implement and will cause the dump to fail rather than causing the system= to hang. Ok. My point is, however, still the same: that should not happen just for the netdump specific case but for all the dumping/KDB/panic cases (I know it is unlikely current code !netdump calls into UMA but it is not an established pre-requisite and may still happen that some added code does). I still see this as a weakness on the infrastructure, independently from netdump. I can see that your point is that it is vital to netdump correct behaviour though, so I'd wonder if it worths fixing it now or later. More people's comment would be appreciated. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein