What does lock_kernel and unlock_kernel actualy makes ?

What does lock_kernel and unlock_kernel actualy makes ?

Post by Eugene Shchepeto » Fri, 07 Jul 2000 04:00:00



 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

 
 
 

What does lock_kernel and unlock_kernel actualy makes ?

Post by Fabrice Pei » Fri, 07 Jul 2000 04:00:00



>  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

        Yop,

        I think is not very important because you must use spinlock.

        Bye.

 
 
 

What does lock_kernel and unlock_kernel actualy makes ?

Post by Fabrice Pei » Fri, 07 Jul 2000 04:00:00




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

>         Yop,

>         I think is not very important because you must use spinlock.

>         Bye.

        Sorry....

        Here a list of lock in the kernel , i find it in the kernel ML.

----------------------------------------------------------------------------------
        Types of Kernel Locks

 Big Kernel Lock
    When to use:     You don't know what fine-grain lock to call,
                                         or a fine-grained lock doesn't
exists.
    Lock:            lock_kernel();
    Unlock:          unlock_kernel();

 spinlock
    When to use:     SMP, # writers == # readers

    Initialize:      spinlock_t my_lock = SPIN_LOCK_UNLOCKED;
    Lock:            spin_lock(&my_lock);
    Unlock:          spin_unlock(&my_lock);

 irq spinlock
    When to use:     SMP, sending signals or in an IRQ back-half

    Initialize:      spinlock_t my_lock = SPIN_LOCK_UNLOCKED;
    Lock:            spin_lock_irq(&my_lock);
    Unlock:          spin_unlock_irq(&my_lock);

 rwlock:
    When to use:     # writers < # readers

    Initialize:      rwlock_t my_lock = RW_LOCK_UNLOCKED;
    Read Lock:       read_lock(&my_lock);
    Read Unlock:     read_unlock(&my_lock);
    Write Lock:      write_lock(&my_lock);
    Write Unlock:    write_unlock(&my_lock);

 bitlocks:
    When to use:     Never?

    Initialize:      unsigned long my_lock=0;
    Spin Lock:       while (test_and_set_bit(bit,&my_lock))
                schedule();
    Unlock:          clear_bit(bit,&my_lock);

 
 
 

What does lock_kernel and unlock_kernel actualy makes ?

Post by Kaz Kylhe » Fri, 07 Jul 2000 04:00:00



> Is it performs a full stop of kernel (except some life-parts of course) ?

No, it acquires a global lock so that only one processor can execute
the code between kernel_lock and kernel_unlock.

Quote:>What parts are still working ? What can I do (call, implement) and what I
>can't between lock and unlock ?

Interrupts are still enabled, so you cannot assume that some given code
won't be interrupted. You must still guard data that is shared with
interrupt service routines.

Quote:>By the way I want to prevent process memory access from anyone but my kernel
>process, is a lock_kernel helps ?

No; for locking your fine grained-data structures, you should use individual
spinlocks. These also work for mutual exclusion against interrupts. A global
kernel lock is something you should avoid introducing at all costs.

--
#exclude <windows.h>

 
 
 

1. kernel: down/up inside of lock_kernel/unlock_kernel?

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.

2. Unusual Paritions are Mounted

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

4. Arrow/tcsh problem with Solaris2.7/CDE

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

6. ***Digital Circuit Simulation Program

7. Matrox Mystique ands X.

8. network device (as in /dev)

9. What actualy is GGI?

10. lock_kernel in 2.2.0pre4

11. lock_kernel check...

12. do_exit() and lock_kernel() semantics

13. lock_kernel() usage and sync_*() functions