Ralf Baechle wrote: > On Wed, Sep 23, 2009 at 02:27:26PM -0400, Randy MacLeod wrote: > > >> I'd like advice on changing the implementation of smp_processor_id on >> Cavium specifically and/or MIPS generally. >> >> Currently we have: arch/mips/include/asm/smp.h >> #define raw_smp_processor_id() (current_thread_info()->cpu) >> >> A co-worker has an issue where the current thread pointer is corrupted >> on a Cavium MIPS system running 2.6.14 (but the same code exists in 2.6.31). >> During the resulting panic() the kernel calls smp_processor_id() >> which dereferences the corrupt task pointer again - ouch. I've notice that >> other arches have raw_smp_processor_id() defined to >> - a platform specific register read, or >> - a percpu variable or >> - have a hard_smp_processor_id() defined >> This last one is presumably for times when you don't trust the kernel >> data structures to be >> sane. >> > > Dereferencing current_thread_info()->cpu is fairly likely to hit in the cache > so probably a single cycle operation. Ironically, it's statistically faster than reading a dedicated CP0 register on those cores that have them, even if that were otherwise a good idea (see below), since access to CP0 registers generally doesn't pipeline! > raw_smp_processor_id() is also a > very common operation so you really don't want to change it to something > slower except for a debugging kernel. > > If you have a good kernel stack pointer you can compute the thread pointer > from that: > > ori $28, sp, _THREAD_MASK > xori $28, _THREAD_MASK > > >> I can create a patch that calls cvmx_get_core_num(); for cavium. >> Is there a more generic way to get the cpu number on MIPS? >> > > raw_smp_processor_id() returns the processor ID as counted by Linux. That > number does not necessarily match the firmware's numbering. Nor does it necessarily match the MIPS32R2's hardware CPU number in the EBase register. smp_processor_id() is fundamentally a software concept, and it's more a lucky coincidence than an ironclad rule when it tracks hardware/firmware numbering. Regards, Kevin K.