Right. These days the boot CPU is a thing of the past - lock_kernel no
longer cares which CPU it happened on. And indeed, it's lean and mean and
doesn't need to disable interrupts, so it also doesn't need to check for
cross-calls explicitly etc.
The code is _very_ simple, and looks fine to me (and is noticeably
faster). I was nervous about changing the atomic -> nonatomic thing, but
if the scheduler spinlock wouldn't act as a synchronization point we'd
have _so_ many problems that it wouldn't work at all (imagine the stack
accesses getting old data on the new CPU etc ;) so I really cannot see
how it could possibly not be correct.
The old code was obviously the only way to sanely do it back when
interrupts would get the kernel lock, and it felt a bit bad to remove the
file where David said "Whee, I'm writing x86 assembly" ;), but it looked
like the time had come to get rid of it.
[ Btw, to others - this _seems_ to be another timing-related one, as Ingo
in another mail said he'd occasionally seen something that looked like
it before. Possibly the new lock code just made it show up more easily ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html