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: <CA+8MBbKYo_Tmb3Zk4W9gBZmZqBpCu4uLUu9M5C2MZAYZEb16Vg@mail.gmail.com>
Date:	Fri, 11 Jul 2014 12:06:40 -0700
From:	Tony Luck <tony.luck@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Havard Skinnemoen <hskinnemoen@...gle.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Ewout van Bekkum <ewout@...gle.com>
Subject: Re: [PATCH 4/6] x86-mce: Add spinlocks to prevent duplicated MCP and
 CMCI reports.

> +               if (atomic_add_unless(&mce_banks[i].poll_reader, 1, 1)) {
> +                       m.status = mce_rdmsrl(MSR_IA32_MCx_STATUS(i));

Same as yesterday. You may skip reading a bank because someone else
is reading the same bank number, even though you don't share that bank
with them.

If we are willing to be rather flexible amount when polling happens,
and not allow very fast poll rates. Then we could do something like
have the lowest numbered online cpu be the only one that sets a
timer. When it goes off, it scans its own banks, and then uses an
async cross-processor call to poke the next highest numbered
online cpu to have it scan banks and poke the next guy.

That way we know that two cpus can't be polling at the same time,
because we convoy them all one at a time.

Fast poll rates would be a problem on very large systems. Might
need to have the highest numbered cpu notice that it is at the
end of the chain and set some flag so the lowest one can tell
whether it is safe to begin the next ripple.

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