Defination of Flag CONFIG_DEBUG_SPINLOCK_SLEEP in AS4 UP1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,
While doing insmod for a psuedo driver, kernel is dumping a stack because
sleep function is called.
My init_module function for psuedo driver calls add_disk to register admin
device.
In add_disk(), kernel is allocating memory using kmalloc with flag
GFP_KERNEL. This is hardcoded in kernel code for add_disk.

Whenever kernel inserts any module or driver it disable all interrupts. But
allocating memory with GFP_KERNEL  flag may sleep. This becomes self
contradicting. Hence an invalid context.
Through kmalloc(), might_sleep_if( flag & GFP_WAIT ) function is called
where flag is GFP_KERNEL.
At this, sleep function is called.
Sleep function have been defined differently depending on defination of
CONFIG_DEBUG_SPINLOCK_SLEEP flag.
The above flag is defined in AS4 UP1. If the flag is defined, might_sleep()
function calls sleep function and then calls reschedule function.
If not defined, might_sleep() function directly calls reschedule function.
In sleep function if irqs_disabled() returns 1, it dumps stack.
irqs_disabled() returns 1 when irqs are disabled.

What we should do to avoid the above scenario?

GFP_KERNEL flag in kmalloc code is hard coded. Can't change that.

We have to call add_disk from our init_module to register admin device for
our psuedo driver.

We tried by enabling irqs before calling add_disk using kernel api
local_irq_enable(). It works fine.
But is it correct to enable irqs in a kernel module?
After add_disk we even restored it back using kernel api
local_irq_disable().

Or is there any other way around thorugh which we can avoid the above
scenario?

Warm Regards,
Shahid Shaikh.





http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________

This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete  this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at [email protected] and delete this mail. 
_____________________________________________________________________

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux