Very Computer

I must be missing something... Why does fs/super.c do a down/up on a
semaphore in its do_mount and do_unmount routines, which will only get
called within a lock_kernel/unlock_kernel pairing? On an SMP box, once
one thread gets into that code between the lock/unlock, no one else can,
so why is the down/up needed? On a UP box, the kernel isn't pre-emptive,
so no one else can run that code a second time until the first one is
finished, right?

Confused... .bri.

I'm not completely sure, but I can think of three possible
explanations of seemingly unnecesarry locks.

I think the kernel developers are trying to replace the kernel
lock with more fine grained locking. I think some parts of the
code still use the kernel lock even though fine grained locking
should be ready to make the kernel lock unnecesarry in this
part of the code.

Also notice that even though the kernel is not preempted, it
might still be interrupted. If an interrupt handler needs to
access the same datastructures the spinlock would be needed,
in that case it should be combined with disabling interrupts.

Finally other parts of the kernel might use the spinclocks
without holding the kernel lock.

--
Kasper Dupont

Wrong on all counts.  If code does a blocking operation (e.g. IO, which
is definitely going to happen during mount(2)) - it can block, SMP or
not.  And as soon as it blocks other tasks are free to go.  Kernel
isn't preemptive.  But all it means is that all switches are voluntary.
Anything that directly or indirectly calls schedule(), be it down(),
or wait_on_...(), etc. may lead to context switch.

Quote:>I'm not completely sure, but I can think of three possible
>explanations of seemingly unnecesarry locks.

>I think the kernel developers are trying to replace the kernel
>lock with more fine grained locking. I think some parts of the
>code still use the kernel lock even though fine grained locking
>should be ready to make the kernel lock unnecesarry in this
>part of the code.

        BKL almost never gives you protection from races.  It's not
about "fine grained" - exclusion is needed on UP as well as on SMP.

        One of the worst myths about kernel programming is that SMP
means more races.  Wrong.  In practice code racy on SMP is almost
always racy on UP.  I've lost the count of times when somebody produced
blatantly racy code, slapped BKL around it, smiled and said that now
it was OK, since magic lock_kernel() was there.  Doesn't work that
way.

Quote:>Finally other parts of the kernel might use the spinclocks
>without holding the kernel lock.

        Just as BKL, spinlocks are no-op on UP.  Calls of schedule(),
though...

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.