Messages in this thread | | | Date | Wed, 29 Jul 1998 23:29:20 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] IDE problems on SMP, fixed? (fwd) |
| |
On Thu, 30 Jul 1998, MOLNAR Ingo wrote: > > [ Btw, I added code to the big kernel lock that checks that the lock is > > always aquired with interrupts enabled (locally or globally). I've run a > > kernel that would panic if interrupts were ever disabled upon trying to > > access the global kernel lock, and it's been up so far, under both heavy > > load and me trying to find some other way to crash it. [...] > > the case i occasionally saw was i think the first lock_kernel() done in > non-boot CPUs. (this was fixed) But i think the original reason was > because lock_kernel() _itself_ used to disable interrupts (just like a > spin_lock_irq()). But now it's lean and mean.
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
| |