linux-kernel - Re: [PATCH] x86: auto poll/interrupt mode switch for CMC to stop CMC storm

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: <alpine.LFD.2.02.1205241201280.3231@ionos>
Date:	Thu, 24 May 2012 12:02:12 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Chen Gong <gong.chen@...ux.intel.com>
cc:	Borislav Petkov <bp@...64.org>, "Luck, Tony" <tony.luck@...el.com>,
	"x86@...nel.org" <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] x86: auto poll/interrupt mode switch for CMC to stop
 CMC storm

On Thu, 24 May 2012, Chen Gong wrote:
> 于 2012/5/24 14:00, Borislav Petkov 写道:
> > On Thu, May 24, 2012 at 10:23:38AM +0800, Chen Gong wrote:
> >> Hi, Boris, when I write these codes I don't care if it is specific for
> >> Intel or AMD.
> > Well, but I do care so that when you leave and start doing something
> > else, people after you can still read and maintain that code.
> >
> >> I just noticed it should be general for x86 platform and all related
> >> codes are general too, which in mce.c, so I think it should be fine to
> >> place the codes in mce.c.
> > Are you kidding me? Only Intel has CMCI.
> >
> > Now, if some other vendor needs correctable errors interrupt rate
> > throttling, they can carve it out, make it generic, and move it to mce.c.
> >
> > Otherwise, it belongs in mce_intel.c. For the same reason AMD error
> > thresholding code belongs to mce_amd.c.
> >
> > Jeez.
> >
> Sorry, I'm really not familiar with AMD's CPU. But I still consider
> these codes should be in
> current place. Because the original poll timer logic is there, and my
> patch is just the
> extension for poll timer. Even if moving these codes to Intel specific
> file, it should be
> another patch to move whole logic including poll timer/CMCI handler to
> Intel specific
> file, do you agree?

Not at all. See my other reply why this is fundamentaly wrong.

Thanks,

	tglx