linux-kernel - Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU

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: <1400846226.25914.16.camel@debian>
Date:	Fri, 23 May 2014 19:57:06 +0800
From:	Chen Yucong <slaoub@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"Huang, Ying" <ying.huang@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen
 to Per-CPU rather than only monarch CPU

On Fri, 2014-05-23 at 11:10 +0200, Borislav Petkov wrote:
> On Fri, May 23, 2014 at 09:32:19AM +0800, Chen Yucong wrote:
> > ...if we reach a timeout, there is very little
> > chance for recovering. Thought. the probability for this situation to
> > happen is very slight, it's not impossible. Indeed, it's hard to know
> > the precise causes for timeout.
OK, we can exclude the timeout. 
Why can not we distribute the clear operations of mces_seen to Per-CPU?
Why must monarch need to help all other CPUs to clean mces_seen? What's
the advantage for this?
Why do we have to discard the property of Per-CPU variable?
Why can not we reduce the processing time of monarch CPU?
... 
> 
> Ok, enough talking, let's close that hole and get on with our lives:
You can safely ignore all messages about this talking.

> 
> There is very little and maybe practically nothing we can do to recover
> from a system where at least one core has reached a timeout during the
> whole monarch cores gathering. So panic when that happens.
> 
Why do you prefer to use "very little" and "maybe practically"?
Do you still not sure about that?


>  	if ((s64)*t < SPINUNIT) {
> -		/* CHECKME: Make panic default for 1 too? */
> -		if (mca_cfg.tolerant < 1)
> +		if (mca_cfg.tolerant <= 1)
If (mca_cfg.tolerant == 2 || mce_cfg.tolerant == 3), what can you do for
it?
>  			mce_panic("Timeout synchronizing machine check over CPUs",
>  				  NULL, NULL);
>  		cpu_missing = 1;
> -- 
> 1.9.0
> 


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