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:	Wed, 30 Jul 2014 10:48:52 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Chen, Gong" <gong.chen@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org, tglx@...utronix.de,
	paulus@...ba.org, benh@...nel.crashing.org, tony.luck@...el.com,
	hpa@...or.com, jkosina@...e.cz, rafael.j.wysocki@...el.com,
	linux@....linux.org.uk, ralf@...ux-mips.org,
	schwidefsky@...ibm.com, davem@...emloft.net,
	viro@...iv.linux.org.uk, fweisbec@...il.com, cl@...ux.com,
	akpm@...ux-foundation.org, axboe@...nel.dk,
	JBottomley@...allels.com, neilb@...e.de,
	christoffer.dall@...aro.org, rostedt@...dmis.org, rric@...nel.org,
	gregkh@...uxfoundation.org, mhocko@...e.cz, david@...morbit.com
Subject: Re: [RFC PATCH v1 13/70] x86, x2apic_cluster: _FROZEN Cleanup

On Wed, Jul 30, 2014 at 02:24:15AM -0400, Chen, Gong wrote:
> On Wed, Jul 23, 2014 at 10:36:28PM +0200, Borislav Petkov wrote:
> >   /*
> >    * At CPU state changes, update the x2apic cluster sibling info.
> >    */
> > @@ -151,9 +166,14 @@ static int
> >  update_clusterinfo(struct notifier_block *nfb, unsigned long action, void *hcpu)
> >  {
> >  	unsigned int this_cpu = (unsigned long)hcpu;
> > -	unsigned int cpu;
> >  	int err = 0;
> >  
> > +	if (action & CPU_TASKS_FROZEN) {
> > +		if ((action & ~CPU_TASKS_FROZEN) == CPU_UP_CANCELED)
> > +			__update_clusterinfo(this_cpu);
> > +		return NOTIFY_OK;
> > +	}
> > +
> Hi, Boris
> 
> Here you assume once the action contains FROZEN flag, it will return
> NOTIFY_OK.

Well, look at the original code. What do you think happens if another
_FROZEN action comes in which we don't handle in the switch-case?

Take a piece of paper and play it through slowly if you don't see it.
Hint: err = 0.

> It looks like not quite comply with original logic. Once
> new FROZEN logic is added, we have to update this code again. How
> about using following code snippet:
> 
> +       if ((action & CPU_TASKS_FROZEN) &&
> +           ((action & ~CPU_TASKS_FROZEN) == CPU_UP_CANCELED)) {
> +               __update_clusterinfo(this_cpu);
> +               return NOTIFY_OK;

No, this is different now from the original logic.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ