On Thu, 4 Jan 2018 02:27:54 +0100 (CET) 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. Agreed enitely - and coverity is non-free which is even worse as a dependancy. Right now we are in the 'what could be done quickly by a few people' space. The papers are now published, so the world can work on better solutions and extending more convenient tooling. > If the CPU speculation can cause these kinds of side-effects, it just must > not happen, full stop. At which point your performance will resemble that of a 2012 atom processor at best. > 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. In the ideal world it becomes possible for future processors to resolve such markings down to no-ops. Will that be possible or will we get more explicit ways to tell the processor what is unsafe - I don't personally know but I do know that turning off speculation is not the answer. Clearly if the CPU must be told then C is going to have to grow some syntax for it and some other languages are going to see 'taint' moving from a purely software construct to a real processor one. Alan
