linux-kernel - Re: x86/mce merge, integration hickup + crash, design thoughts

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]

Message-ID: <496FBF2B.4010809@linux.intel.com>
Date:	Thu, 15 Jan 2009 23:56:43 +0100
From:	Andi Kleen <ak@...ux.intel.com>
To:	Tim Hockin <thockin@...il.com>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	ying.huang@...el.com, Aaron Durbin <adurbin@...il.com>,
	priyankag@...gle.com
Subject: Re: x86/mce merge, integration hickup + crash, design thoughts

Tim Hockin wrote:
> Yeah, no offense, but that's horrible :)

I'm not sure it's worse than the XML like format proposals that seem to
get thrown around. That is I am the only one who mentioned the
X word yet, but the structured ASCII records that have been hinted
at would be exactly like that.

> 
> Ideally, I'd rather see a more generic conduit for all sorts of
> events.  Polled and exception MCEs.  Thermal interrupts.  MCE
> threshold interrupts. 

Actually I think now MCE threshold interrupts should have never been
separate events. That was a design mistake in the AMD implementation
(together with all the sysfs complications)

An MCE threshold interrupt is just a slightly different internal
notification mechanism and it should only trigger the events it reads
from the MCE banks. Nothing more.
My upcoming CMCI code works exactly this way.

> PCI-express errors. 

Yes we need some mechanism for those. Fortunately that's easier
because it doesn't need to handle NMIs.

> SATA
> disk timeouts.

Now that's a different issue. Generalized driver error reporting for everyone.

There was a lot of discussion some years ago from a IBM proposal to do
in general structured error reporting. But that was quite unpopular
and no-one really liked it.

What came out of it was the dev_printk() stuff that allows
to match error messages to devices. So you already have some
baby steps in this direction.

I suspect doing this fully generalized would be quite difficult
because there would be so many people you have to convince.

> Now I know there are different conduits for some events - netlink
> tells me about netif link up/down events I think.  I would settle for
> a small number of interfaces.  What I don't want is what we have today
> - EVERYTHING has a different interface.  Some are poll()-able.  Some
> have to be actively polled.  Some have to have a daemon listening or
> else messages are dropped.  

Well the kernel will always have limited buffers, so the someone
needs to listen problem will be always there.

There are not __that__ many I think.

Also whatever code handles this has to have special code for
all of these anyways, so having a variety of interfaces for them
doesn't seem like the end of the world to me.

> 
> Put it this way:  Given a thousand machines, I want to gather,
> collate, and correlate all these events.  I want to be able to produce
> a "life story" of sorts for a machine and for a data center.  Once I
> can do that, I can start to make predictive diagnoses more accurately,
> and I can know how much these things actually COST us.

Sure sounds nice. But frankly I don't see it happening. It would
be just too radical a change of too much code.

-Andi

--
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/