From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 12 06:18:12 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB861322; Fri, 12 Jul 2013 06:18:12 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5511C78; Fri, 12 Jul 2013 06:18:12 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id x11so8325999pdj.1 for ; Thu, 11 Jul 2013 23:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=iPf/+XL61vSTjr49EQjXhjjs5Npdg6xxZzduXyChdJA=; b=PgJ5ZQbI3cE681X6No/+3X6NgiEC+kZ2TzoUG8CEsvjOxpHHwOf+S/X9vKKl9VGM7v O4qdgeUMlDhc0gNUwKlRBKdylbgbxYWyIIhUiXlt22c8zPJRicJBmLe1mQxJ8QtJwHEv D0DZFyVIEYvQHtuX4N2lN5OAkTn9UC1m+eGOlCUZRr3jFF6TFfTB+G3zsmBG2qpcdpuj 80VIM1UIYTRuCWAhsElMUaFT8ww4NxCbOaYyu1AHwXMZxPI5R4puknd6an5oMxsO9jOr maPgbiwUZqpzhgCReCoXmHyFGTQCorz4xtGCaXhxj3m8aXWMd94P1o2hgsHgMSfBS0Ne WKag== X-Received: by 10.68.217.137 with SMTP id oy9mr40072694pbc.130.1373609891891; Thu, 11 Jul 2013 23:18:11 -0700 (PDT) Received: from [10.20.30.70] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id eq5sm43538520pbc.15.2013.07.11.23.18.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 23:18:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Kernel dumps [was Re: possible changes from Panzura] From: Hubbard Jordan In-Reply-To: Date: Thu, 11 Jul 2013 23:18:08 -0700 Message-Id: <90871AB4-6615-4571-A0F6-B605141497FA@gmail.com> References: <9890DFF1-892A-4DCA-9E33-B70681154F43@mail.turbofuzz.com> <4F0DFAB7-D6D5-4068-A543-C9DF885D1A7D@dragondata.com> <51DEC0E8.7010305@freebsd.org> To: Artem Belevich X-Mailer: Apple Mail (2.1510) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: hackers@freebsd.org, Kevin Day X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 06:18:12 -0000 On Jul 11, 2013, at 2:05 PM, Artem Belevich wrote: > It would probably work for most of the crashes, but will not work in = few > interesting classes of failure. Using in-kernel stack implicitly = assumes > that your memory allocator still works as both the stack and the = interface > driver will need to get their mbufs and other data somewhere. Alas = it's > those unusual cases that are hardest to debug and where you really do = want > debugger or coredump to work. This is all true, though I think Julian was also suggesting that this = "fall-back vimage" would be somehow preallocated, perhaps not from the = kernel allocator pool, ahead of time. The mbufs needed for it a = "connection time" would also presumably come from a special pool, though = I don't know how much conditional logic in the existing stack would be = necessary to make sure it didn't try to allocate any data from the = generic allocator. It might indeed be easier to simply bake-in a much simpler, UDP-only = stack and polled device driver combo. - Jordan