Re: [patch] IDE problems on SMP, fixed? (fwd)

Linus Torvalds (
Wed, 29 Jul 1998 23:29:20 -0700 (PDT)

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 ]


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at