I'm surprised that nintendo maintains their own OS for the switch console too, instead of using linux or other unix derivative : https://en.wikipedia.org/wiki/Nintendo_Switch_system_softwar...
A one in a million bug in Switch kernel
91–95 of 95 posts
Re: A one in a million bug in Switch kernel
#92Earlier quoted context omitted.
On what basis are you saying the interrupt messes it up? The post directly says that if a migration doesn't happen, then nothing goes wrong. What messes up is when you do the barrier-needing instructions on one core, and a memory barrier on a completely different core. Which seems pretty expected to me. If the thing you're describing happens, that does sound like a hardware bug, but I don't see where you got that des…
> On what basis are you saying the interrupt messes it up? Because nothing else makes sense. The code as posted in the linked article does not seem to have an ordering violation that I can see. The linked blog just asserts that it's there, but AFAICT it isn't unless there's a symmetric ordering bug in the putative context switch code that isn't presented.
The problem is very simple, isn't it? There are instructions that need a memory barrier after them. If the thread leaves the core, then from the view of that core no memory barrier happens.
And it's a particular kind of memory barrier that nothing else does incidentally.
Re: A one in a million bug in Switch kernel
#93Earlier quoted context omitted.
Dude, it was meant to be mildly educational, not an "argument."
Then present it as a fun fact rather than as a correction? And I'm not trying to be mean but I think the way you phrased your last line is accidentally anti-educational. Your last line treats 1 million ops and 4 million ops as nearly equivalent, when the truth is that 1 million ops is far from "every day" while 4 million ops can easily be called "every day". And if you dislike the word "argument" pretend I said "poin…
And yet... here you are, having applied that same mathematical principle to calculate the probability of observing a one-in-a-million event at least once in 4mil independent trials. That's probably something you already knew how to do, but if not, it's a pretty educational moment. ;)
ps — "to be pedantic" means "fun fact" but sarcastically.
Re: A one in a million bug in Switch kernel
#94Earlier quoted context omitted.
Then present it as a fun fact rather than as a correction? And I'm not trying to be mean but I think the way you phrased your last line is accidentally anti-educational. Your last line treats 1 million ops and 4 million ops as nearly equivalent, when the truth is that 1 million ops is far from "every day" while 4 million ops can easily be called "every day". And if you dislike the word "argument" pretend I said "poin…
And yet... here you are, having applied that same mathematical principle to calculate the probability of observing a one-in-a-million event at least once in 4mil independent trials. That's probably something you already knew how to do, but if not, it's a pretty educational moment. ;) ps — "to be pedantic" means "fun fact" but sarcastically.
The bulk of your post was educational, but it was misleadingly shown as an answer to both "million" and "millions", when those two scenarios actually have very different answers.
> ps — "to be pedantic" means "fun fact" but sarcastically.
It means that, but also sets it up as a correction. But "millions" being "every day" was right all along.
Re: A one in a million bug in Switch kernel
#95Earlier quoted context omitted.
For the record: Returning from an interrupt is fully serializing on x86, which I believe means that all modern operating systems on x86 will handle this properly. https://pvk.ca/Blog/2019/01/09/preemption-is-gc-for-memory-r... is a very good blog post about exploiting this for a high-performance membarrier daemon.
But a thread can be context switched via a system call, so switching back to it will return to it via a return from system call which is not necessarily serializing on x86. Also memory operations and barriers executed in kernel mode have to be ordered correctly within a thread and context switches there can happen cooperatively so there may be no interrupt at all. Also a serializing operation is not a memory barrier.…
Linux has barriers in the scheduler for this and other reasons.