From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Li Zefan <lizf@cn.fujitsu.com>, linux-kernel@vger.kernel.org
Subject: Re: mmotm 2010-10-20-15-01 uploaded
Date: Thu, 21 Oct 2010 11:52:17 +0200 [thread overview]
Message-ID: <1287654737.3488.94.camel@twins> (raw)
In-Reply-To: <20101021003008.064302ad.akpm@linux-foundation.org>
On Thu, 2010-10-21 at 00:30 -0700, Andrew Morton wrote:
> On Thu, 21 Oct 2010 09:17:26 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> > > It would have been clearer to do
> > >
> > > WARN_ON_ONCE(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx))
> > >
> > > but I don't see what's gone wrong here. Peter?
> >
> > Right, so that's the warning that the unmapped address isn't actually
> > the top-of-stack one.
> >
> > Your version is much nicer, although I haven't looked too hard at it, I
> > probably got my head in a twist.
> >
> > But like you, I cannot directly see what's going wrong here,
> > zero_user_segments() seems a simple enough function without any
> > kmap_atomic nesting, so I'm not at all seeing how that's going wrong.
> >
> > /me goes find where you hide your mmotm patch-queue and stare at the
> > actual code.
OK, so found it, and its really rather embarrassing.. I really blotched
those x86 WARN_ON_ONCE()s, for some reason I got my brain in a twist and
messed those up big-time. All other architectures have the form you
suggested earlier.
The problem is that fixmaps are top-down, so the original warning ended
up trying to compare x with (-x) >> PAGE_SHIFT, which clearly won't
work.
The sad part is that I apparently only compile tested the debug code :/
With the warning fixed (and CONFIG_DEBUG_HIGHMEM=y) an otherwise
i386-defconfig seems to fully complete boot without warnings on a qemu
with 2048 MB of memory.
---
Subject: mm, x86: Fix stack based kmap_atomic debug warnings
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Thu Oct 21 11:45:08 CEST 2010
Due to a massive brainfart I got the x86 kunmap_atomic debug code that
is supposed to avoid stack violations wrong.
Use the form all other architectures already use (which was also
independently suggested by Andrew).
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
arch/x86/mm/highmem_32.c | 3 +--
arch/x86/mm/iomap_32.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/x86/mm/highmem_32.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/highmem_32.c
+++ linux-2.6/arch/x86/mm/highmem_32.c
@@ -78,8 +78,7 @@ void __kunmap_atomic(void *kvaddr)
idx = type + KM_TYPE_NR * smp_processor_id();
#ifdef CONFIG_DEBUG_HIGHMEM
- WARN_ON_ONCE(idx !=
- ((vaddr - __fix_to_virt(FIX_KMAP_BEGIN)) >> PAGE_SHIFT));
+ WARN_ON_ONCE(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
#endif
/*
* Force other mappings to Oops if they'll try to access this
Index: linux-2.6/arch/x86/mm/iomap_32.c
===================================================================
--- linux-2.6.orig/arch/x86/mm/iomap_32.c
+++ linux-2.6/arch/x86/mm/iomap_32.c
@@ -102,8 +102,7 @@ iounmap_atomic(void __iomem *kvaddr)
idx = type + KM_TYPE_NR * smp_processor_id();
#ifdef CONFIG_DEBUG_HIGHMEM
- WARN_ON_ONCE(idx !=
- ((vaddr - __fix_to_virt(FIX_KMAP_BEGIN)) >> PAGE_SHIFT));
+ WARN_ON_ONCE(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
#endif
/*
* Force other mappings to Oops if they'll try to access this
next prev parent reply other threads:[~2010-10-21 9:52 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 22:01 mmotm 2010-10-20-15-01 uploaded akpm
2010-10-21 2:54 ` Li Zefan
2010-10-21 3:15 ` Li Zefan
2010-10-21 3:38 ` Konrad Rzeszutek Wilk
2010-10-21 3:44 ` Li Zefan
2010-10-21 14:28 ` Konrad Rzeszutek Wilk
2010-10-21 3:46 ` Andrew Morton
2010-10-21 7:17 ` Peter Zijlstra
2010-10-21 7:30 ` Andrew Morton
2010-10-21 9:52 ` Peter Zijlstra [this message]
2010-10-21 9:54 ` Peter Zijlstra
2010-10-21 7:41 ` HDA: no sound [was: mmotm 2010-10-20-15-01 uploaded] Jiri Slaby
2010-10-21 7:49 ` Takashi Iwai
2010-10-21 7:57 ` Jiri Slaby
2010-10-21 8:05 ` Takashi Iwai
2010-10-21 18:27 ` Jiri Slaby
2010-10-21 19:20 ` Takashi Iwai
2010-10-21 19:21 ` Jiri Slaby
2010-10-21 19:22 ` Takashi Iwai
2010-10-21 19:40 ` Takashi Iwai
2010-10-21 20:29 ` Valdis.Kletnieks
2010-10-21 20:48 ` Takashi Iwai
2010-10-21 21:24 ` Valdis.Kletnieks
2010-10-21 21:31 ` Takashi Iwai
2010-10-21 21:42 ` Jiri Slaby
2010-10-22 8:46 ` Colin Guthrie
2010-10-22 9:02 ` Takashi Iwai
2010-10-22 9:18 ` Jiri Slaby
2010-10-22 9:40 ` Takashi Iwai
2010-10-22 9:45 ` Jiri Slaby
2010-10-22 10:26 ` Takashi Iwai
2010-10-22 11:10 ` Jiri Slaby
2010-10-22 9:41 ` Colin Guthrie
2010-10-22 11:31 ` [alsa-devel] " Clemens Ladisch
2010-10-22 11:51 ` Jiri Slaby
2010-10-22 14:03 ` Takashi Iwai
2010-10-22 19:53 ` Colin Guthrie
2010-10-21 15:22 ` Valdis.Kletnieks
2010-10-21 17:59 ` Jiri Slaby
2010-10-21 11:10 ` mmotm 2010-10-20-15-01 uploaded Zimny Lech
2010-10-21 11:14 ` mmotm 2010-10-20 - netfilter Kconfig whinge Valdis.Kletnieks
2010-10-29 19:11 ` Patrick McHardy
2010-10-21 17:51 ` DVB: af9015 defunct [was: mmotm 2010-10-20-15-01 uploaded] Jiri Slaby
2010-10-21 22:24 ` Jiri Slaby
2010-10-22 9:21 ` Jiri Slaby
2010-10-22 13:56 ` Mauro Carvalho Chehab
2010-10-22 14:06 ` Jiri Slaby
2010-10-27 16:12 ` Mauro Carvalho Chehab
2010-10-27 16:36 ` Jiri Slaby
2010-10-27 17:05 ` Mauro Carvalho Chehab
2010-10-27 16:41 ` Antti Palosaari
2010-10-27 17:11 ` Mauro Carvalho Chehab
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=1287654737.3488.94.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox