From: Nishanth Aravamudan <nacc@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Miles Lane <miles.lane@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, Adam Litke <agl@us.ibm.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: 2.6.24-git20 -- BUG: sleeping function called from invalid context at include/asm/uaccess_32.h:449
Date: Mon, 11 Feb 2008 14:28:55 -0800 [thread overview]
Message-ID: <20080211222855.GA9138@us.ibm.com> (raw)
In-Reply-To: <20080210212528.GA17442@us.ibm.com>
On 10.02.2008 [13:25:28 -0800], Nishanth Aravamudan wrote:
> On 09.02.2008 [16:26:43 -0800], Andrew Morton wrote:
> > On Sat, 9 Feb 2008 14:03:28 -0500 "Miles Lane" <miles.lane@gmail.com> wrote:
> >
> > > Command run:
> > > find /proc | xargs tail
> > >
> > > [ 2710.028219] BUG: sleeping function called from invalid context at
> > > include/asm/uaccess_32.h:449
> > > [ 2710.028229] in_atomic():1, irqs_disabled():0
> > > [ 2710.028232] 1 lock held by head/9380:
> > > [ 2710.028234] #0: (hugetlb_lock){--..}, at: [<c016734f>]
> > > hugetlb_overcommit_handler+0x16/0x3e
> > > [ 2710.028248] Pid: 9380, comm: head Not tainted 2.6.24-git20 #5
> > > [ 2710.028260] [<c0118749>] __might_sleep+0xc2/0xc9
> > > [ 2710.028267] [<c021cb39>] copy_to_user+0x32/0x49
> > > [ 2710.028277] [<c0123f6a>] do_proc_doulongvec_minmax+0x1df/0x27f
> > > [ 2710.028289] [<c012403c>] proc_doulongvec_minmax+0x15/0x17
> > > [ 2710.028295] [<c0167363>] hugetlb_overcommit_handler+0x2a/0x3e
> > > [ 2710.028303] [<c01a1462>] proc_sys_read+0x5e/0x7b
> > > [ 2710.028311] [<c01a1404>] ? proc_sys_read+0x0/0x7b
> > > [ 2710.028317] [<c0170d7a>] vfs_read+0x8a/0x106
> > > [ 2710.028325] [<c017116f>] sys_read+0x3b/0x60
> > > [ 2710.028331] [<c0103e32>] sysenter_past_esp+0x5f/0xa5
> >
> > Ugh, how did I let that one through?
>
> Don't blame yourself, blame me.
>
> > Guys, how often mut it be said?
>
> Hopefully this is often enough.
>
> > PLEASE always test all code with all kernel deubg options enabled.
>
> Yep, 100% my error. Am testing a fix now, will post soon.
While I'm not removing the brown paper bag from my head, I was unable to
reproduce the BUG on my 2-way x86_64 at home. I then noticed Miles'
system is x86_32. After wrangling with our testing grid, I got a 32-bit
system booting 2.6.24-git22. Didn't reproduce there either, with
CONFIG_DEBUG_SPINLOCK_SLEEP=y. What am I doing wrong? I think the
following is the right fix, but have not see the original BUG to know
for sure. I did the `find /proc | xargs tail`, but shouldn't I hit the
BUG just simply `cat`'ing or `echo`ing into the file?
Miles, could you test the following?
Thanks,
Nish
hugetlb: fix overcommit locking
proc_doulongvec_minmax() calls copy_to_user()/copy_from_user(), so we
can't hold hugetlb_lock over the call. Use a dummy variable to store the
sysctl result, like in hugetlb_sysctl_handler(), then grab the lock to
update nr_overcommit_huge_pages.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 7ca198b..addca4c 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -33,8 +33,8 @@ int hugetlb_reserve_pages(struct inode *inode, long from, long to);
void hugetlb_unreserve_pages(struct inode *inode, long offset, long freed);
extern unsigned long max_huge_pages;
+extern unsigned long sysctl_overcommit_huge_pages;
extern unsigned long hugepages_treat_as_movable;
-extern unsigned long nr_overcommit_huge_pages;
extern const unsigned long hugetlb_zero, hugetlb_infinity;
extern int sysctl_hugetlb_shm_group;
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index d41ef6b..2024632 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -978,8 +978,8 @@ static struct ctl_table vm_table[] = {
{
.ctl_name = CTL_UNNUMBERED,
.procname = "nr_overcommit_hugepages",
- .data = &nr_overcommit_huge_pages,
- .maxlen = sizeof(nr_overcommit_huge_pages),
+ .data = &sysctl_overcommit_huge_pages,
+ .maxlen = sizeof(sysctl_overcommit_huge_pages),
.mode = 0644,
.proc_handler = &hugetlb_overcommit_handler,
},
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d9a3803..cb1b3a7 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -24,14 +24,15 @@
const unsigned long hugetlb_zero = 0, hugetlb_infinity = ~0UL;
static unsigned long nr_huge_pages, free_huge_pages, resv_huge_pages;
static unsigned long surplus_huge_pages;
+static unsigned long nr_overcommit_huge_pages;
unsigned long max_huge_pages;
+unsigned long sysctl_overcommit_huge_pages;
static struct list_head hugepage_freelists[MAX_NUMNODES];
static unsigned int nr_huge_pages_node[MAX_NUMNODES];
static unsigned int free_huge_pages_node[MAX_NUMNODES];
static unsigned int surplus_huge_pages_node[MAX_NUMNODES];
static gfp_t htlb_alloc_mask = GFP_HIGHUSER;
unsigned long hugepages_treat_as_movable;
-unsigned long nr_overcommit_huge_pages;
static int hugetlb_next_nid;
/*
@@ -609,8 +610,9 @@ int hugetlb_overcommit_handler(struct ctl_table *table, int write,
struct file *file, void __user *buffer,
size_t *length, loff_t *ppos)
{
- spin_lock(&hugetlb_lock);
proc_doulongvec_minmax(table, write, file, buffer, length, ppos);
+ spin_lock(&hugetlb_lock);
+ nr_overcommit_huge_pages = sysctl_overcommit_huge_pages;
spin_unlock(&hugetlb_lock);
return 0;
}
next prev parent reply other threads:[~2008-02-11 22:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-09 19:03 2.6.24-git20 -- BUG: sleeping function called from invalid context at include/asm/uaccess_32.h:449 Miles Lane
2008-02-10 0:26 ` Andrew Morton
2008-02-10 0:38 ` Arjan van de Ven
2008-02-10 10:44 ` Stefan Richter
2008-02-10 21:26 ` Nishanth Aravamudan
2008-02-10 21:25 ` Nishanth Aravamudan
2008-02-11 22:28 ` Nishanth Aravamudan [this message]
2008-02-12 3:57 ` Miles Lane
2008-02-12 4:17 ` Miles Lane
2008-02-12 5:16 ` Nishanth Aravamudan
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=20080211222855.GA9138@us.ibm.com \
--to=nacc@us.ibm.com \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=david@gibson.dropbear.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=miles.lane@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.