linux-kernel - Re: [GIT PULL] RAS update for 3.20 (one more thing)

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150209101316.GB5461@gmail.com>
Date:	Mon, 9 Feb 2015 11:13:16 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org,
	linux-edac@...nel.org, Borislav Petkov <bp@...e.de>
Subject: Re: [GIT PULL] RAS update for 3.20 (one more thing)


* Luck, Tony <tony.luck@...el.com> wrote:

> The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce:
> 
>   Linux 3.19-rc6 (2015-01-25 20:04:41 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/please-pull-fixmcelog
> 
> for you to fetch changes up to 728b6f14abaa7f36a8c6d41c6d6fe0320d32d5e9:
> 
>   x86, mce: Kernel does full decoding for AMD, others still need /dev/mcelog reports (2015-01-30 11:25:46 -0800)
> 
> ----------------------------------------------------------------
> Long standing regression - functions registered on the mce decoder
> chain can declare that they have completely dealt with an event.
> True for AMD (says Boris), since the kernel fully decodes the
> machine check bank information. Not true for Intel processors. Full
> decode is done in user space, so we need to make the log visible
> via /dev/mcelog

So I'm having second thoughts about this:

This kind of vendor specific hard coding is really ugly:

        if (c->x86_vendor == X86_VENDOR_AMD && ret == NOTIFY_STOP)
                return;

Instead we should fix the Intel side to do a proper decode 
as well - by the time mcelog is running it might be too 
late, attempting an intelligent printk is way better...

So what would we need to make the Intel side just as good 
as the AMD side?

I've undone the pull for now.

Thanks,

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