From: Andrew Morton <akpm@osdl.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mremap sleeping in incorrect context
Date: Thu, 31 Jul 2003 14:51:32 -0700 [thread overview]
Message-ID: <20030731145132.64ab1574.akpm@osdl.org> (raw)
In-Reply-To: <1059658728.2417.112.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>
> > oops. What are your CONFIG_HIGHMEM and CONFIG_HIGHPTE settings there?
>
> this is on ppc32, HIGHPTE doesn't exist, HIGHMEM is enabled (1Gb of
> RAM)
>
OK, thanks. Seems that I made a little bug. This should fix it. With a
changelog like this, it _has_ to be right ;)
move_one_page() is awkward. It grabs an atomic_kmap of the source pte
(because it needs to know if there's really a page there) and then it needs
to allocate a pte for the dest. But it cannot allocate the dest pte while
holding the src's atomic kmap.
So it performs this little dance peeking at pagetables to predict if
alloc_one_pte_map() might need to perform a pte page allocation.
When I wrote this code I made it conditional on CONFIG_HIGHPTE. But that was
bogus: even in the !CONFIG_HIGHPTE case, get_one_pte_map_nested() will run
atomic_kmap() against the pte page, which disables preemption.
Net effect: with CONFIG_HIGHMEM && !CONFIG_HIGHPTE we can end up performing a
GFP_KERNEL pte page allocation while preemption is disabled. It triggers a
might_sleep() warning and indeed is buggy.
So the patch removes the conditionality: even in the !CONFIG_HIGHPTE case we
still do the pagetable peek and drop the kmap if necessary.
(Arguably, we shouldn't be performing the atomic_kmap() at all if
!CONFIG_HIGHPTE: all it does is a pointless preemption disable).
(Arguably, kmap_atomic() should not be disabling preemption if the target
page is not highmem. But we're doing it anyway at present for consistency
(ie: debug coverage) and because the filemap.c pagecache copying functions
rely on kmap_atomic() disabling do_no_page() for all pages: see
do_no_page()'s use of in_atomic()).
25-akpm/mm/mremap.c | 4 ----
1 files changed, 4 deletions(-)
diff -puN mm/mremap.c~mremap-atomicity-fix mm/mremap.c
--- 25/mm/mremap.c~mremap-atomicity-fix Thu Jul 31 14:37:05 2003
+++ 25-akpm/mm/mremap.c Thu Jul 31 14:37:15 2003
@@ -56,7 +56,6 @@ end:
return pte;
}
-#ifdef CONFIG_HIGHPTE /* Save a few cycles on the sane machines */
static inline int page_table_present(struct mm_struct *mm, unsigned long addr)
{
pgd_t *pgd;
@@ -68,9 +67,6 @@ static inline int page_table_present(str
pmd = pmd_offset(pgd, addr);
return pmd_present(*pmd);
}
-#else
-#define page_table_present(mm, addr) (1)
-#endif
static inline pte_t *alloc_one_pte_map(struct mm_struct *mm, unsigned long addr)
{
_
next prev parent reply other threads:[~2003-07-31 22:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-30 17:32 Benjamin Herrenschmidt
2003-07-30 22:34 ` Andrew Morton
2003-07-31 13:38 ` Benjamin Herrenschmidt
2003-07-31 21:51 ` Andrew Morton [this message]
2003-08-01 10:41 ` Benjamin Herrenschmidt
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=20030731145132.64ab1574.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=benh@kernel.crashing.org \
--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®