Not true, it is architecture independent (commit also mentions Android) and i can find this bug backported to atleast RHEL5.11 with 2.6.18-404.

Also, i don't believe your queries are a sufficient check at all.

You can clearly find the missing default case in http://kernel.ubuntu.com/git/ubuntu/ubuntu-precise.git/tree/... . So i guess that means ubuntu precise is/was also affected?

Same in your other link https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st... .

Please check your facts next time.

Thanks, I've corrected the links, please check them again to see they are pre-regression versions [1]

> Not true, it is architecture independent (commit also mentions Android)

I saw it (and arm64 comment in this thread) but I didn't include them because I don't think it would be a production-serious issue there. Thanks for clarification.

> Please check your facts next time.

Thanks to your post I've corrected links, but no need for such an aggressive tone, huh? Maybe you should try to be more polite in your next refutal tries?

[1] https://github.com/torvalds/linux/commit/b0c29f79ecea0b6fbce...

Please note that i was just looking for the missing default case. It might still be the case that the bug is not in precise..

The patch also replaces atomic_inc() with futex_get_mm():

  -		atomic_inc(&key->private.mm->mm_count);
  +		futex_get_mm(key); /* implies MB (B) */

And your links are using atomic_inc().. What that means with regards to this bug? I don't know.

Fix commit and OP claims bug was introduced in [1], which has been never backported to 3.2.x, so I assume lack of default case was not a problem before that commit.

> And your links are using atomic_inc().. What that means with regards to this bug? I don't know.

It means they are simply old versions and they were never affected by the bug, if we believe the commit message of the fix commit and OP.

[1] https://github.com/torvalds/linux/commit/b0c29f79ecea0b6fbce...

Or not recognized.. But you are right, i suppose that the atomic_inc() doesn't need a memory barrier because it's atomic and the new function may need one, guessing.

Where are you seeing this backported to 5.11 or 2.6.18-404? I'm pretty sure the changeset that introduced the problem has not been backported to RHEL5 kernels.

I was only looking for the missing switch case in that function (which was what has been fixed by Linus). My conclusion that this missing case is showing the bug was probably not right.