[PATCH] MIPS: ASID conflict after CPU hotplug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a repost of my original message which somehow did not reach
the mailing list (filtered out?).

Hello,

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 was very simple - do not reset asid_cache(cpu) on TP warm
restart. But I would welcome any comments because my understanding of
the code is somewhat fuzzy.

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index d83f325..ccf9272 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1577,7 +1577,8 @@ void __cpuinit per_cpu_trap_init(void)
        }
 #endif /* CONFIG_MIPS_MT_SMTC */

-       cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
+       if (!cpu_data[cpu].asid_cache)
+               cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
        TLBMISS_HANDLER_SETUP();

        atomic_inc(&init_mm.mm_count);

Regards,
Max Rayskiy.



[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux