From: Andrew Morton <akpm@digeo.com>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: PageLRU BUG() when preemption is turned on (2.4 kernel)
Date: Wed, 06 Nov 2002 18:51:07 -0800 [thread overview]
Message-ID: <3DC9D51B.4CF2B06D@digeo.com> (raw)
In-Reply-To: <20021106183317.E15363@mvista.com>
Jun Sun wrote:
>
> I am chasing a nasty bug that shows up in 2.4 kernel when preemption
> is turned on. I would appreciate any help. Please cc your reply
> to me email account.
>
> I caught the BUG() live with kgdb (on a MIPS board). See the backtrace
> attached at the end.
>
> In a nutshell, access_process_vm() calls put_page(), which
> calls __free_pages(), where it finds page->count is 0 but does not
> like the fact that page->flags still has LRU bit set.
>
That's a bug in older 2.4 kernels. You'll need to use a more recent
kernel, or change that put_page() to be a page_cache_release(),
or forward-port this chunk:
/*
* Yes, think what happens when other parts of the kernel take
* a reference to a page in order to pin it for io. -ben
*/
if (PageLRU(page)) {
if (unlikely(in_interrupt()))
BUG();
lru_cache_del(page);
}
to your __free_pages_ok().
The problem is that `put_page()' doesn't know how to deal with the
final release of a page which is on the LRU. Someone else released
their reference, leaving access_process_vm() unexpectedly holding
the last reference to the page. But it does put_page(), which then
says "why didn't you remove this page from the LRU? BUG."
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
prev parent reply other threads:[~2002-11-07 2:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-07 2:33 Jun Sun
2002-11-07 2:51 ` Andrew Morton [this message]
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=3DC9D51B.4CF2B06D@digeo.com \
--to=akpm@digeo.com \
--cc=jsun@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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