From owner-freebsd-net@FreeBSD.ORG Thu Oct 14 14:10:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23768106564A; Thu, 14 Oct 2010 14:10:42 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDC08FC1D; Thu, 14 Oct 2010 14:10:41 +0000 (UTC) Received: by qyk31 with SMTP id 31so51371qyk.13 for ; Thu, 14 Oct 2010 07:10:40 -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=VdrfBunv2f7NPCMKPfpABT+EG3J7PPEg7UNCTulp8Ok=; b=D2qKjp2jK2BNzg9HLFqHb/wjsobhlPkrFIIE1lIRamyi/As/ZtN1qoGA5yMOMSWOEi jljDNcdOgBJk8Ip8VDO79EUGILRWAp0Wu1pexZlF8bxu0Ct5nKcaItA/4WNdKxAMtP3l MoMvZ7Vt3em2vI/PAbUm0x3CZFhgiiy77uEnc= 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=vEnv7Dz1Vr0+hEOBSCvBOwE8MoaajplkKQS0ravA623OD/+QqOzfKUyoYnSb1KEwua mF5a+nCJ7DJ1ASG0zhrnCT7rLbB1sh3mErExAbb6H3ZMQFq/Ef/kvpMGcVbh2k1cR6FN WJZTJncob71IbUbG8PUrCqJtoZ8bUBjqINB3c= MIME-Version: 1.0 Received: by 10.224.76.78 with SMTP id b14mr7891677qak.75.1287065440468; Thu, 14 Oct 2010 07:10:40 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 14 Oct 2010 07:10:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Oct 2010 16:10:26 +0200 X-Google-Sender-Auth: vsnm9Bpqhonyk5rLnsHoFrpYpkU 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-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 14:10:42 -0000 2010/10/14 Robert N. M. Watson : > > On 13 Oct 2010, at 18:46, Ryan Stone wrote: > >> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrot= e: >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get and fill= a header mbuf, then chain data as an >>> extended >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* mbuf. >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MGETHDR(m, M_DONTWAI= T, MT_DATA); >>> >>> The idea of calling into the mbuf allocator in this context is just fre= aky, >>> and may have some truly awful side effects. =C2=A0I suppose this is the= cost of >>> trying to combine code paths in the network device driver rather than h= ave >>> an independent path in the netdump case, but it's quite unfortunate and= will >>> significantly reduce the robustness of netdumps in the face of, for exa= mple, >>> mbuf starvation. >> >> Changing this will require very invasive changes to the network >> drivers. =C2=A0I know that the Intel drivers allocate their own mbufs fo= r >> their receive rings and I imagine that all other drivers have to do >> something similar. =C2=A0Plus the drivers are responsible for freeing mb= ufs >> after they have been transmitted. =C2=A0It seems to me that the cost of >> making significant changes to the network drivers to support an >> alternate lifecycle for netdump mbufs far outweighs the cost of losing >> a couple of kernel dumps in extreme circumstances. > > My concern is less about occasional lost dumps that destabilising the dum= ping process: calls into the memory allocator can currently trigger a lot o= f interesting behaviours, such as further calls back into the VM system, wh= ich can then trigger calls into other subsystems. What I'm suggesting is th= at if we want the mbuf allocator to be useful in this context, we need to t= each 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. 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. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein