Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Technically this wasn't caused by those instructions but by the spinlocks waiting for the lock to be released. Also "blocked by seven instructions" sounds a bit click-baity.. you can lock the CPU or power off the computer with less than that amount of instructions :-)


Or break it, depending on how old it is:

  f0 0f c7 c8: lock cmpxchg8b eax


Does this still bug still bite anywhere? Embedded computing with Pentiums?


I used a Pentium with that bug as a router up until 2009.


Yeah, I used to have a similar setup then. That was 10 years ago, though.


It's an invalid instruction, so a compiler wouldn't (shouldn't) ever generate it.


You can make gcc generate it, and versions of Linux without no-execute support will actually run it. Like so:

int main = 0xc8c70ff0;


Ah, but that's something you do on purpose. What I meant is that it's not a Meltdown-like problem.


Did you read the post? There were no spin locks waiting for the lock to be released. The ~100 threads waiting for the lock were all waiting in an idle state, quite efficiently.

The problem was that the thread that owned the lock was spinning in a seven-instruction loop.


I think the point is that you have this beast of a computer and the lions share if its power is going to these 7 instructions. It's a bit theatrical way of putting it, but in the article he doesn't actually blame the 7 instructions for the root problem.


In this case I'm OK with it. It pulled me in long enough to be entertained.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: