linux-kernel - Re: [PATCH v1 00/12] netoops support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 04 Nov 2010 10:21:14 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	Américo Wang <xiyou.wangcong@...il.com>
CC:	Matt Mackall <mpm@...enic.com>, Greg KH <greg@...ah.com>,
	simon.kagstrom@...insight.net, davem@...emloft.net,
	adurbin@...gle.com, akpm@...ux-foundation.org, chavey@...gle.com,
	linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH v1 00/12] netoops support

Américo Wang wrote:
> On Wed, Nov 03, 2010 at 03:54:45PM -0500, 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.
>>
> 
> Really? What are other clients? I remember netdump *was* one client,
> but it is not in upstream and is deprecated, so netconsole is the only
> client in tree, AFAIK.

I see the bonding and bridging drivers using netpoll.

> 
> 
>>> 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. 
>>
> 
> That would be good.
> 
> 
>> 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. 
>>
>> 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.
>>
> 
> We have WARN_ONCE(), maybe we can make one oops_once()...
> At least, that is not hard.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/