Commit 5c200197130e307de6eba72fc335c83c9dd6a5bc

Authored by Maksim Rayskiy
Committed by Ralf Baechle
1 parent b2f909419b

MIPS: ASID conflict after CPU hotplug

I am running SMP Linux 2.6.37-rc1 on BMIPS5000 (single core dual thread)
and observe some abnormalities when doing system suspend/resume which I
narrowed down to cpu hotplugging. The suspend brings the second thread
processor down and then restarts it, after which I see memory corruption
in userspace. I started digging and found out that problem occurs because
while doing execve() the child process is getting the same ASID as the
parent, which obviously corrupts parent's address space.

Further digging showed that activate_mm() calls get_new_mmu_context() to
get a new ASID, but at this time ASID field in entryHi is 1, and
asid_cache(cpu) is 0x100 (it was just reset to ASID_FIRST_VERSION when
the secondary TP was booting).

So, get_new_mmu_context() increments the asid_cache(cpu) value to
0x101, and thus puts 0x01 into entryHi. The result - ASID field does
not get changed as it was supposed to.

My solution is very simple - do not reset asid_cache(cpu) on TP warm
restart.

Patchwork: https://patchwork.linux-mips.org/patch/1797/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

Showing 1 changed file with 2 additions and 1 deletions Side-by-side Diff

arch/mips/kernel/traps.c
... ... @@ -1596,7 +1596,8 @@
1596 1596 }
1597 1597 #endif /* CONFIG_MIPS_MT_SMTC */
1598 1598  
1599   - cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
  1599 + if (!cpu_data[cpu].asid_cache)
  1600 + cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
1600 1601  
1601 1602 atomic_inc(&init_mm.mm_count);
1602 1603 current->active_mm = &init_mm;