From: "shahid shaikh" <shahid.shaikh@patni.com>
To: <linux-kernel@vger.kernel.org>
Subject: Defination of Flag CONFIG_DEBUG_SPINLOCK_SLEEP in AS4 UP1
Date: Tue, 16 Aug 2005 15:37:07 +0530 [thread overview]
Message-ID: <00a501c5a24a$4339aca0$11051aac@pcp41116> (raw)
[-- Attachment #1: Type: text/plain, Size: 2454 bytes --]
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 netadmin@patni.com and delete this mail.
_____________________________________________________________________
next reply other threads:[~2005-08-16 10:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-16 10:07 shahid shaikh [this message]
2005-08-16 10:09 ` Arjan van de Ven
2005-08-16 10:12 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00a501c5a24a$4339aca0$11051aac@pcp41116' \
--to=shahid.shaikh@patni.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®