Locks in kernel

Locks in kernel

[Sivakumar Kuppusamy]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Hi All,
I am having doubts in locking mechanism in Linux 2.2 kernel code. 

We have done modifications in the Linux kernel code to support our
application which runs at the user space. The modification done in 
the Linux kernel is to maintain a table of data(like a routing table),
which will be updated by the applicaition with appropriate data. This
data will be used by the kernel for other processing. 

We are using "up" & "down" functions for locking global data in the kernel.
Our code in kernel will get called when a IP packet is received. During
that time we are trying to lock that global data and retrieve some
info from that. Is this a correct way to do. We are also locking 
the global data when it gets updated from the application. Since 
ip_rcv() gets called from bottom_half(), can we do any locking
stuff there? We faced kernel panicking when the application locked
the global data and got scheduled to continue later(with lock held). 
That time ip_rcv() got called and we are trying to acquire the lock
which is held by the scheduled process. This made the kernel panic.

How should we approach this problem? Shouldn't we use any locking in
the code which is called by the bottom_half()? 

Thanks in advance for your replies,
Siva

[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 855 bytes --]

-----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
------------------------------------------------------------------------------------------------------------------------

Re: Locks in kernel

[george anzinger]

Sivakumar Kuppusamy wrote:
> 
> Hi All,
> I am having doubts in locking mechanism in Linux 2.2 kernel code.
> 
> We have done modifications in the Linux kernel code to support our
> application which runs at the user space. The modification done in
> the Linux kernel is to maintain a table of data(like a routing table),
> which will be updated by the applicaition with appropriate data. This
> data will be used by the kernel for other processing.
> 
> We are using "up" & "down" functions for locking global data in the kernel.
> Our code in kernel will get called when a IP packet is received. During
> that time we are trying to lock that global data and retrieve some
> info from that. Is this a correct way to do. We are also locking
> the global data when it gets updated from the application. Since
> ip_rcv() gets called from bottom_half(), can we do any locking
> stuff there? We faced kernel panicking when the application locked
> the global data and got scheduled to continue later(with lock held).
> That time ip_rcv() got called and we are trying to acquire the lock
> which is held by the scheduled process. This made the kernel panic.
> 
> How should we approach this problem? Shouldn't we use any locking in
> the code which is called by the bottom_half()?
> 
As I am sure you are beginning to suspect, you need to NOT hold locks in
tasks that can sleep which are also accessed from an interrupt context
(bottom_half).  Among the locks that allow (or even force) sleeping are
the "up" "down" locks.  These must NOT be used from the interrupt
context.  Locks that can be used from the interrupt context are the
spinlocks.  Of these you would need to use the "irq" versions.  In this
group you will also find the read/ write locks which allow several
readers at a time, while writers are given exclusive access.

If you must allow sleeping locks, you will have to promote the interrupt
code to a kernel task which can sleep.  This is done using wait queues. 
There are various versions of these, but they all end up having the
"consumer" sleep until the "producer" calls "wake_up".  Again, there are
various wrappers that can be used here.  The key is that the interrupt
context calls the "wake_up" side and the kernel task calls the sleep
side.

Then you will most likely need to use one of the spinlock_irq locks to
synchronize the interrupt context with the kernel task, but remember,
the kernel task must NOT sleep while holding a spinlock.

This is an overview.  You can find much more detail in the
kernel-hacking-HOWTO
http://www.linuxgrill.com/anonymous/fire/netfilter/kernel-hacking-HOWTO-5.html
or try Google.

George