All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Soeren Sandmann Pedersen <sandmann@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: d451564 breakage
Date: Sat, 14 Nov 2009 01:21:38 +0100	[thread overview]
Message-ID: <20091114002138.GA9421@elte.hu> (raw)
In-Reply-To: <20091113233734.GG27752@flint.arm.linux.org.uk>


* Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> On Sat, Nov 14, 2009 at 12:17:14AM +0100, Ingo Molnar wrote:
> > 
> > * Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > 
> > > On Fri, Nov 13, 2009 at 11:48:20PM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > > > 
> > > > > Change:
> > > > > 
> > > > > highmem: Fix debug_kmap_atomic() to also handle KM_IRQ_PTE, KM_NMI, and KM_NMI_PTE
> > > > > 
> > > > > Appears to break ARM:
> > > > > 
> > > > > mm/highmem.c: In function ???debug_kmap_atomic???:
> > > > > mm/highmem.c:436: error: ???KM_NMI??? undeclared (first use in this function)
> > > > 
> > > > indeed - sorry.
> > > > 
> > > > Note that debug_kmap_atomic() will be removed in v2.6.33 so i'd suggest 
> > > > to just do the easy solution and add #ifndef dummy definitions to 
> > > > mm/highmem.c to cover ARM - we'll remove the whole cruft for good.
> > > 
> > > Actually, the following patch is probably the simplest solution.
> > > 
> > > > Btw., testing sidenote: i test the ARM defconfig and it didnt break 
> > > > there. Perhaps highmem is off in the ARM defconfig? It would be helpful 
> > > > if the ARM defconfig enabled highmem.
> > > 
> > > Given that highmem on ARM is experimental, I'd rather not have it enabled
> > > in too many machine defconfigs as standard just yet.
> > > 
> > > However, enabling highmem on itself is not enough to show this breakage,
> > > you also need highmem debugging enabled.
> > > 
> > >  arch/arm/include/asm/kmap_types.h |    6 ++++++
> > >  1 files changed, 6 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/arch/arm/include/asm/kmap_types.h b/arch/arm/include/asm/kmap_types.h
> > > index d16ec97..c019949 100644
> > > --- a/arch/arm/include/asm/kmap_types.h
> > > +++ b/arch/arm/include/asm/kmap_types.h
> > > @@ -22,4 +22,10 @@ enum km_type {
> > >  	KM_TYPE_NR
> > >  };
> > >  
> > > +#ifdef CONFIG_DEBUG_HIGHMEM
> > > +#define KM_NMI		(-1)
> > > +#define KM_NMI_PTE	(-1)
> > > +#define KM_IRQ_PTE	(-1)
> > > +#endif
> > 
> > Please solve this in mm/highmem.c as Andrew suggested it - other 
> > architectures could be affected as well beyond ARM.
> 
> Have you actually put any thought into that approach? [...]

Yes.

> [...]  What you're suggesting means:
> 
> - adding preprocessor definitions to all existing places where these
>   symbols are defined
> - adding multiple complex ifdefs to mm/highmem.c thusly:
> 
> 		if (
> #ifdef KM_NMI
> 			type != KM_NMI
> #else
> 			1
> #endif
> 			&&
> #ifdef KM_NMI_PTE
> 			type != KM_NMI_PTE
> #else
> 			1
> #endif

I'd NAK such ugly code.

What i was thinking of was a really simple thing in highmem.c (or 
rather, in include/linux/highmem.h, after kmap_types.h gets included):

#ifndef KM_NMI
# define KM_NMI			-1
#endif
#ifndef KM_NMI_PTE
# define KM_NMI_PTE		-1
#endif

etc.

Thanks,

	Ingo

  reply	other threads:[~2009-11-14  0:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-13 15:11 d451564 breakage Russell King
2009-11-13 19:54 ` Andrew Morton
2009-11-13 22:50   ` Ingo Molnar
2009-11-13 22:48 ` Ingo Molnar
2009-11-13 23:02   ` Russell King
2009-11-13 23:17     ` Ingo Molnar
2009-11-13 23:37       ` Russell King
2009-11-14  0:21         ` Ingo Molnar [this message]
2009-11-14  8:19           ` Russell King
2009-11-14  9:28             ` Ingo Molnar

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=20091114002138.GA9421@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    --cc=sandmann@redhat.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.