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.

It's possible.

B could change them. After reacquiring the bkl, A will continue from where it was left out.

Use lock_kernel().

When process A needs to relinquish the CPU, schedule() will release the bkl, but lock_depth in A's task_struct is not reset to -1. So, the A is scheduled to run again, the scheduler knows A needs to acquire the bkl.

Please note, up to 2.6.10, the bkl is implemented using a spin_lock. Since 2.6.11, it's a semaphore.

Thank you very much! I know that from 2.6.11 to now it implements with semaphore but my research is in 2.6.10

1. as you say the scheduler gives the time to "A"(never another one like "B") again after invoking release_kernel_lock(). so why scheduler invokes release_kernel_lock()?


2. I understand from your speech that BKL in 2.6.10 and before was very bad.
you think that process "A" gives BKL and invokes unlock_kernel() after some times scheduler gives the time to it again, while it's lock_depth=0 then scheduler gives BKL to it again while it does'nt need it. is it true?

3. you say that lock_kernel() can be invoken more than once by a process but in unlock_kernel() we have if(likely(--current->lock_depth<0) --unlock_kernel(); so when lock_depth!=0 never BKL will be freed and it has made a dealock. is it true?

Ah, sorry! something forgotten!
how other process (that has't BKL now)understand that they can't come in to kernel?