kernel: down/up inside of lock_kernel/unlock_kernel?

kernel: down/up inside of lock_kernel/unlock_kernel?

Post by Brian Horto » Sun, 09 Dec 2001 03:30:34



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.

 
 
 

kernel: down/up inside of lock_kernel/unlock_kernel?

Post by Kasper Dupon » Tue, 18 Dec 2001 09:45:53



> 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?

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

 
 
 

kernel: down/up inside of lock_kernel/unlock_kernel?

Post by Alexander Vi » Tue, 18 Dec 2001 18:26:11





>> 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?

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.

 
 
 

1. What does lock_kernel and unlock_kernel actualy makes ?

 Is it performs a full stop of kernel (except some life-parts of course) ?
What parts are still working ? What can I do (call, implement) and what I
can't between lock and unlock ?
By the way I want to prevent process memory access from anyone but my kernel
process, is a lock_kernel helps ?
Thanks

Eugene

2. dip 3.37o-uri / pppd problem

3. adds missed lock_kernel/unlock_kernel to reiserfs_dir_fsync().

4. ./configure fails on KDE2 apps

5. driver/sound/soundcard.c lock_kernel()/unlock_kernel()

6. rmap 13

7. Shape Ups,Men's Shape Ups,Men's Skechers Shape Ups - new styles!

8. curses

9. UPS daemon & shutting down a Mac.

10. Where should I shut down UPS during powerfail shutdown?

11. listening to a UPS, and shutting down a network

12. "Linux Inside": Spoof of Intel Inside

13. Formattet output inside variable / line brak inside variable