in 2.6.10 big kernel lock is implement with spinlock and i am researching in it:
imagin a senario like this: process A have the big kernel lock now.

1. how other processes(that has't BKL now)understand that they can't come in to kernel?

2. after timeslice scheduler invokes release_kernel_lock... then scheduler invokes reacquire_kernel_lock. the scheduler gives the time to "A" again?(never another one like "B"!?) after invoking release_kernel_lock()? so why scheduler invokes release_kernel_lock()? if scheduler select B for running what happen for A's data structures?

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?

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

Best regards.

Nonsense ;-)

There are some excellent discussions of kernel synchronization issues in this book (if you want to understand the subject in-depth):

Linux Kernel Development, 2nd Ed.
Robert Love
http://www.amazon.com/Linux-Kernel-D...946945&sr=11-1

Here are a couple of briefer articles on the BKL:
http://lwn.net/Articles/86859/
http://www.ibm.com/developerworks/li...onization.html

The real issue isn't catastrophe (Linux kernel synchronization is very robust), but efficiency (fine-grained locks result in far better utilization than some "BKL").

IMHO .. PSM

Security of process’s data inside Critical Section

I read Linux Kernel Development Second Edition By Robert Love. And in section Big Kernel Lock I found this:


lock_kernel();
/*
* Critical section, synchronized against all other BKL users...
* Note, you can safely sleep here and the lock will be transparently
* released. When you reschedule, the lock will be transparently
* reacquired. This implies you will not deadlock, but you still do
* not want to sleep if you need the lock to protect data here!
*/
unlock_kernel();
It is about kernel 2.6.10 and before it.
why process datas is not secure here? So what is the usage of locking the kernel? I thougt that when a process want to leave CPU temporary, it’s values save in a stack, before switch context.
This situation is like the situation that scheduler take BKL from a process after a timestamp (with release_kernel_lock(prev)) and take time to another process. If it is so, this situation is not safe for a process too. Is it true? What is the difference between this condition and others that a process leaves CPU?
Best regards

Everybody wants and has somewhat of a "right" to equal exposure for their questions. However the way you chose to promote your current question is not appreciated. You're new here so you are met with leniency, but please do not crosspost again.

Data is safe..... just so long as you don't sleep! The comment is just reminding you that if you sleep you will give up the big kernel lock...

Also, while the stack should be fine, keep in mind not all data you are accessing is going to be on the stack.... say your messing with a task struct of a running process for example...

DISCLAIMER: Please keep in mind I haven't touched kernel code in about 3 years, I believe my comments are accurate, but don't take them as the gospel

first of all, Thanks for your helps:-)

1. When a process time's up(or it sleeps), it goes to the runqueue and after some times it returns to runnig on a CUP again, but it has information of it's task struct and also it has a stack, but all of these are not enough! this process change some variables that are in the kernel code, like "int variable;" but another process that get the time from scheduler and comes in to the kernel, manipulates this variable. is it true? so when early process comes back, it accostes with false datas. as ROBERT LOVE says: "This implies you will not deadlock, but you still do not want to sleep if you need the lock to protect data here!" if it's data is secure here why we call it critical section?
This question is not only about big kernel lock and critical section, it is very basically I think!:-)

2. do you think that realy one process that has the Big Kernel Lock sleeps in the critical section?

Thanks alot

I might be confused about what your saying but.....

1. Don't confuse the kernel with "regular processes". The purpose of the big kernel lock was to mark sections in the kernel that cannot be preempted.... for anything by anything. You can't use the big kernel lock anywhere but in the kernel itself. No userspace process should ever directly be touching any variables inside the scope of the kernel, that would be a security nightmare. Userspace processes interact with the kernel through syscalls.

2. I honestly can't come up with a good reason in my mind why anyone would grab the big kernel lock and sleep... but I'm also not intimately knowledgeable of the entire kernel code base so a perfectly valid reason might exist...

heroma -

I'm totally confused about what you're really asking. It could be any/all of:

1. History of the BKL (and the differences between the different implementations at different stages in its history)

2. Different mechanisms for kernel locking and synchronization

3. Locking and synchronization in general

4. Possible issues with your particular application vis a vis the BKL

5. Possible issues with your particular application vis a vis a specific version of Linux (and with that version's BKL implementation)

6. Something else entirely...

Understanding the "why" behind your question will help us give you a meaningful answer.

Could you please help us out and give us a little of the *context* for your question?

Thank you very much in advance .. PSM

Sorry. I'm realy sorry!
I want to understand all the codes that are about BKL in the kernel 2.6.10,OK? my first question is solved now. my second question is something about BKL but different from my first.

my last question is about the security of datas inside critical section that is made by invoking lock_kernel() in a process.

lock_kernel();
critical section
unlock_kernel();

in this book that paulsm4 suggest me and I’m so thankful from him, Robert Love says:
/*
* Critical section, synchronized against all other BKL users...
* Note, you can safely sleep here and the lock will be transparently
* released. When you reschedule, the lock will be transparently
* reacquired. This implies you will not deadlock, but you still do
* not want to sleep if you need the lock to protect data here!
*/

what is the meaning of this comment?and totally this is my problem now!

If I had to guess (and I do) this sounds like a hackish job of protecting idiot programmers from themselves by making the lock not really a lock. If they do something that causes them to be suspended, they should be abnormally terminated. Instead of that happening, it seems that there's a way that to keep track of threads that do that and when they get redispatched they get redispatched holding the lock.

During the time they lose control, and until the time they regain control, they don't hold the lock. This is why it says in the comment not to sleep if you need the lock. Because if you do sleep, while you are sleeping you will not hold the lock and any resource you serialized under the lock is now free for any other thread who can get the lock.

I'd agree with this assessment. I wouldn't be surprised if you could find a message in the LKML around the time the comment was put in with the why.

What I don't understand is the statement "My last question is about the security of datas inside critical section that is made by invoking lock_kernel() in a process."

You cannot call lock_kernel() from outside of the kernel itself so this is not an issue. A process cannot call lock_kernel and one process cannot muck with the data of another. If you are using IPC shared memory you should be using IPC semaphores to protect your critical sections.

thank you Randux, as you say: "Because if you do sleep, while you are sleeping you will not hold the lock and any resource you serialized under the lock is now free for any other thread who can get the lock." I understand from your speech that there is no danger for datas that are inside critical section, only this process loses resources and others can catch these resources. OK? so who guaranties the precision of datas of the kernel that this process do something on them and other process after losing BKL can manipulate them?this process needs datas after reacquires BKL!

Oh no dear jtshaw, as I had said in my previous post:"I want to understand all the codes that are about BKL in the kernel 2.6.10", so everything that I tell is about kernel code. I am not a programmer yet! I want to know BKL now. I am not outside the kernel! but I don't understand this:"one process cannot muck with the data of another" exactly I wish to know boundary of datas of each process and datas of kernel. please describe your sentence.
I am thankful you beforehand

Most people don't understand that serialization is a protocol rather than a force-field against changes. It has to be used properly; everyone has to agree on what it means and everyone has to use it the same way, or data can't be serialized.

I didn't say there isn't any danger to data inside the critical section. Nothing can prevent against that except good programming practices which include everyone who accesses a resource agreeing to serialize it the same way. For example, when a process holding the lock sleeps, I can theoretically get control on another thread and update this resource. I shouldn't be able to, but I can if I don't use the same lock the other guy used.

To answer your question: so who guarantees the precision (I think you mean what guarantees the serialization) of data? The answer is, good programming practice and a correct design. Everyone who accesses a resource that needs to be serialized has to do it the same way. One of the conditions required in this situation is that you must not sleep until you have committed any changes to data. Sleeping here is equivalent to releasing the lock.

Thanks JTShaw for confirming my suspicions. I didn't mean to second guess you as I have no experience with *NIX internals and missed your response when I first posted. (I do have a long history with multiprocessing hardware and OS however)

Ok... so here we go.

When I say "process" I'm speaking strictly in terms of a user space process. When the process is executed it gets a heap and a stack in virtual memory with a task_struct in between (and the heap and stack grow towards each other). It cannot access another processes memory because the kernel does not allow the process to access memory outside of its virtual memory section. If its heap overruns its stack it will also overrun the task_struct (first) which virtually guarantees the program will crash before it can do anything nasty.

In the kernel all bets are off, because there is no line of defense to prohibit anyone from accessing anything (since the kernel IS the line of defense for user space).

So to start looking at the big kernel lock you should first consider it's history. Starting back in the 2.2 kernel, if I'm not mistaken, Linux started supporting SMP (Symmetric multiprocessing). Unfortunately there was a lot of kernel code that wasn't "thread-safe" meaning it wasn't safe to run both procedures simultaneously on different CPU's and insure data coherency. The big kernel lock was put in to protect those areas of code which were not "thread safe". Now during the development of the 2.4 kernel much of the system was completely redesigned to remove the dependance on the bkl and as a result it's use was decreased. In 2.6 they started working towards a preemptable kernel to, among other things, lower the latency on certain setups (like a Linux desktops or real-time linux systems for example). Part of making the system more preemptable was to make the bkl preemptable. I believe this happened around 2.6.8 but it could have been much sooner. This is likely what lead to the comments in the code your discussing... just a friendly reminder that if you've grabbed the lock you best not expect it to stay yours if you have to sleep for any reason, so code wisely.

Around 2.6.26rc2 somebody removed the preemtable part of the bkl again, which lead to another debate amongst the kernel folks. Linus seems to be most in favor of removing the bkl entirely going forward.

Really what it comes down to is you must be extra careful when using shared resources in the context of the kernel...