Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754347Ab0KDBSz (ORCPT ); Wed, 3 Nov 2010 21:18:55 -0400 Received: from smtp-out.google.com ([216.239.44.51]:30024 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754216Ab0KDBSx (ORCPT ); Wed, 3 Nov 2010 21:18:53 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kxjdrosFAG/FNqZLg23FqB1pGG/8CI2DOSW2GmUO85pgQ8lu2IF46VgUM/wqAtFVE2 o/Ghzm21NOnfDd8OWQdA== Message-ID: <4CD209F1.90708@google.com> Date: Wed, 03 Nov 2010 18:18:41 -0700 From: Mike Waychison User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Matt Mackall CC: Greg KH , simon.kagstrom@netinsight.net, davem@davemloft.net, adurbin@google.com, akpm@linux-foundation.org, chavey@google.com, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH v1 00/12] netoops support References: <20101103012917.4641.57113.stgit@crlf.mtv.corp.google.com> <20101103023422.GB5782@kroah.com> <20101103181634.GF7441@kroah.com> <4CD1C612.5080902@google.com> <1288817685.26428.1129.camel@calx> In-Reply-To: <1288817685.26428.1129.camel@calx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4209 Lines: 85 Matt Mackall wrote: > On Wed, 2010-11-03 at 13:29 -0700, Mike Waychison wrote: >> Mike Waychison wrote: >>> FWIW, another semantic difference between netconsole and netoops (that >>> I had missed in the last email) is filtering: we really do want to get >>> the whole log when a crash happens, debug messages and all. >>> Netconsole is subject to console filtering (which we _do_ want as >>> debug messages going out the uart slows the whole world down). >>> >>> netconsole and netoops _do_ have bits in common, for instance the >>> handling of NETDEV events and source+target configuration. I'd rather >>> those bits become common between the two than figure out how to jam >>> the semantics we need into netconsole. >> Hi Matt, >> >> I've been reading through the netconsole driver in response to Greg's >> comments on this thread, and it is definitely more robust in terms of >> configuration and handling of network device events than the netoops >> driver I proposed. > > I've been following the discussion to see if it went anywhere > interesting.. > >> What are your thoughts on extending netconsole with the same sort of >> semantics that are in the netoops patchset? > > My first thought is that it's a bit unfortunate that some of the the > netconsole configgy bits weren't implemented in a generic way that would > be applicable to other netpoll clients. Some people have never gotten it > into their heads that netconsole isn't the only client. > >> I'd still like to have blit-dmesg-to-the-network-on-oops semantics, >> which seems doable by having a per-target flag for streaming of console >> messages (enabled by default) and a flag to emit a structured full dmesg >> dump (disabled by default). > > I'd actually like to see you go forward with netoops. It's clear to me > that it's a different beast and complexifying netconsole with a bunch of > weird new options doesn't really sit well. If that means abstracting > some of the sysfs crap from netconsole, great. I'd be happy to take a stab at this. This solves most of the ABI reservations that I have with this v1 patchset. Looking at netconsole, it looks to lack some locking for data consistency, and it appears that we will deadlock if we ever get a NETDEV_UNREGISTER event (due to recursively grabbing the rtnl in netpoll_cleanup). I have a couple patches I've been hacking on this afternoon that should clear those issues up. I'm thinking of pushing all the target handling options down into net/core/netpoll.c. I'll probably expose this interface as "struct netpoll_targets" where ->lock and ->list could be completely exposed to clients. netconsole would then get a lot smaller as would netoops. > That said, I don't think netoops is an ideal name, given how closely > bound oops _events_ are with their textual output. Presumably it covers > events other than oopsen like panics too. True. We call this code 'netdump' or 'network_dumper' internally, but I figured it'd be better to follow current conventions with ramoops and mtdoops already in the tree. I don't really care what it's called in the end :) > > Regarding rolling oopses: lots of machines regularly survive oopses, so > I think you ought to consider rate-limiting them (to a configurable rate > with a very low default) rather than suppressing all but the first. > The trouble with Oopses is just that: We don't know whether we can safely survive them or not and it's a total gamble each time we do Oops. We can't programmatically know how crapped out the machine is, so historically we've erred on not allowing bad things to continue happening once someone notices something wrong. It's easier for us to just shoot the machine in the head (panic_on_oops) and move on than corrupt data or dead-lock in weird ways at some later point in time. This is definitely not the behaviour I would want nor expect from my desktop or phone, but for the cluster, it's just safer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/