Big kernel lock in 2.6.10 and scheduling
 

Hi everybody,I have some questions in scheduling and locking the kernel (Big Kernel Lock) in kernel 2.6.10:
1. Is it posible that one process invoke lock_kernel() for more than onc? In other word can lock_depth have positive value means more than zero?

2. If process A catch the lock of kernel (with invoking lock_kernel()) and after it’s timestamp scheduler release kernel lock from process A with(release_kernel_lock(prev) in kernel_lock.c) and scheduler give the lock to process B, what happen for the data structures of the kernel that process A change them and process A need them again? Can B manipulates them? After that process A reacquire kernel lock from where continue it’s executing?

3. How can a process reacquire big kernel lock?


4. From where scheduler know that one process (not current) need kernel lock while it’s lock_depth=-1 before invoking lock_depth?
Best regards.

Of course you can call lock twice; it simply deadlocks the kernel.

Why do you want to use the BKL? Do you want to be flamed by the LKML? The BKL was an early mistake which many people wish would go away, but no one has time to spare to fix the remaining legacy code which uses the BKL.

I don't use it! only, I want to know it.

Hi,
Can anybody tell me that when scheduler will release kernel lock provisionally from process that has the BKL?"with release_kernel_lock()" . if BKL releases provisionally what will happen for datas of previous process?
thanks

It is categorically true of any locking mechanism that you:

1. Must "acquire" the lock before making any examination whatsoever of the data structure.
2. Must leave the data struture in a logically-complete and stable state before unlocking it.
3. Must spend the minimum amount of time possible with the lock held ... you cannot yield-control.
4. After acquiring the lock again, you must start over completely from-scratch. Nothing that you might have "remembered" is valid.

The "Big Kernel Lock" idea is a poor one at-its-core: locks ought not to be "big." Nevertheless, it's easy to see how the lock came to be. "Big locks" are convenient when you are introducing them into logic that never had, nor needed, locks before... as the kernel itself didn't. But then they're quite difficult to get rid of.

what would you mean?
do you mean that After acquiring the lock again, you must start from the beginning?
thanks