public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



  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