Wish the world do not share and lock go way.

Rusty Russell's Unreliable Guide To Locking give a very good introductionto the locking in linux kernel. The most important thing is to indentify the critical region and then apply lock on them.

here are two main types of kernel locks. The fundamental type is the spinlock (include/asm/spinlock.h), which is a very simple single-holder lock: if you can't get the spinlock, you keep trying (spinning) until you can. Spinlocks are very small and fast, and can be used anywhere. The second type is a semaphore (include/asm/semaphore.h): it can have more than one holder at any time (the number decided at initialization time), although it is most commonly used as a single-holder lock (a mutex). If you can't get a semaphore, your task will put itself on the queue, and be woken up when the semaphore is released. This means the CPU will do something else while you are waiting, but there are many cases when you simply can't sleep (see Chapter 9), and so have to use a spinlock instead.

Sleep sleep sleep Zzzzzzzz

Yeah..if you can not sleep, you can not use semaphore! If you hold a lock, you can not sleep!! That is the rule. You can not take something back home and sleep, you need to take care someone else who still running and need your unlock to get some thing.

LIDS with the lock and sleep

I fight with the sleep while hold a lock for a few times. This time, I learn to not using sleepable function like kmalloc(GFP_KERNEL), getxattr, setxattr etc while within a lock. Instead, just put what you want to process into a list and then unlock it and process the list one by one to get what you want to done.
Locking? yeah..task->security need to be lock each time you set it. inode->i_security need spin_lock(&i_lock) as well. And for each subject_acl, yes, each task_acl has a t_lock and each inode_acl got a i_lock too. Go bless this lock! I still remember year 2000, I forget to init a spin_lock and a lot of problems coming out without any sense..:-((