On Wed, Jan 3, 2018 at 5:27 PM, Jiri Kosina <jikos@xxxxxxxxxx> wrote: > On Thu, 4 Jan 2018, Alan Cox wrote: > >> There are people trying to tune coverity and other tool rules to identify >> cases, > > Yeah, but that (and *especially* Coverity) is so inconvenient to be > applied to each and every patch ... that this is not the way to go. > > If the CPU speculation can cause these kinds of side-effects, it just must > not happen, full stop. OS trying to work it around is just a whack-a-mole > (which we can apply for old silicon, sure ... but not something that > becomes a new standard) that's never going to lead to any ultimate > solution. Speaking from a purely Linux kernel maintenance process perspective we play wack-a-mole with missed endian conversions and other bugs that coccinelle, sparse, etc help us catch. So this is in that same category, but yes, it's inconvenient. Alan already mentioned potential compiler changes and annotating variables so that the compiler can help in the future, but until then we need these explicit checks. Elena has done the work of auditing static analysis reports to a dozen or so locations that need some 'nospec' handling. The point of this RFC is to level set across architectures on the macros/names/mechanisms that should be used for the first round of fixes.
