From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 14:23:37 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 57F781065793; Thu, 14 Oct 2010 14:23:37 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 261C58FC18; Thu, 14 Oct 2010 14:23:37 +0000 (UTC) Received: from [192.168.33.146] (lapwing-gw-1.csx.cam.ac.uk [131.111.1.66]) by cyrus.watson.org (Postfix) with ESMTPSA id AA26846B8F; Thu, 14 Oct 2010 10:23:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Oct 2010 15:23:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> References: To: Attilio Rao X-Mailer: Apple Mail (2.1081) 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 14:23:37 -0000 On 14 Oct 2010, at 15:10, Attilio Rao wrote: >> My concern is less about occasional lost dumps that destabilising the = dumping 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, which probably means helping uma out a bit in that = regard. And a watchdog to make sure the dump is making progress. >=20 > 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 = ideally 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. Robert=