[PATCH for 2.6.22] [0/10] X86 late bug fixes for 2.6.22

[PATCH for 2.6.22] [0/10] X86 late bug fixes for 2.6.22

[Andi Kleen]

All should be added to 2.6.22.

Several of them are minimal bandaids for the release; avoiding
more extensive changes.

And several harmless fixes for various build warnings. 

-Andi

[PATCH for 2.6.22] [1/10] i386: bug in i386 MTRR initialization

[Andi Kleen]

From: Andrea Righi <righiandr@users.sourceforge.net>
BUG: at include/linux/slub_def.h:77 kmalloc_index()
 [<c0168eb0>] get_slab+0x1d0/0x260
 [<c0169056>] __kmalloc+0x16/0x70
 [<c042b0ff>] sysenter_setup+0x6f/0x330
 [<c010baed>] mtrr_bp_init+0xcd/0x270
 [<c041a480>] unknown_bootoption+0x0/0x250
 [<c041a480>] unknown_bootoption+0x0/0x250
 [<c0423f78>] check_bugs+0x8/0x160
 [<c01a644c>] proc_sys_init+0xc/0x30
 [<c041a8ef>] start_kernel+0x21f/0x2b0
 [<c041a480>] unknown_bootoption+0x0/0x250
 =======================

Reproduced running 2.6.22-rc2 (using SLUB) in a virtual machine with qemu 0.9.0
+ kqemu 1.3.0pre11. It occurs only using "-kernel-kqemu" option (full
virtualization mode).

In this case mtrr is supported by the real cpu, but no mtrr range is found,
resulting in a kmalloc(0, GFP_KERNEL) in get_mtrr_state() and init_table().

I don't know if it's an incorrect behaviour of qemu in the mtrr emulation, but I
think it should be handled properly.

Signed-off-by: Andrea Righi <a.righi@cineca.it>
Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/kernel/cpu/mtrr/generic.c |    3 +++
 arch/i386/kernel/cpu/mtrr/main.c    |    5 +++++
 2 files changed, 8 insertions(+)

Index: linux/arch/i386/kernel/cpu/mtrr/generic.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/generic.c
+++ linux/arch/i386/kernel/cpu/mtrr/generic.c
@@ -84,6 +84,9 @@ void get_mtrr_state(void)
 	struct mtrr_var_range *vrs;
 	unsigned lo, dummy;
 
+	if (!num_var_ranges)
+		return;
+
 	if (!mtrr_state.var_ranges) {
 		mtrr_state.var_ranges = kmalloc(num_var_ranges * sizeof (struct mtrr_var_range), 
 						GFP_KERNEL);
Index: linux/arch/i386/kernel/cpu/mtrr/main.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux/arch/i386/kernel/cpu/mtrr/main.c
@@ -120,6 +120,11 @@ static void __init init_table(void)
 {
 	int i, max;
 
+	if (!num_var_ranges) {
+		printk(KERN_ERR "mtrr: no MTRR range found.\n");
+		return;
+	}
+
 	max = num_var_ranges;
 	if ((usage_table = kmalloc(max * sizeof *usage_table, GFP_KERNEL))
 	    == NULL) {

Re: [PATCH for 2.6.22] [1/10] i386: bug in i386 MTRR initialization

[Linus Torvalds]

On Wed, 20 Jun 2007, Andi Kleen wrote:
> 
> From: Andrea Righi <righiandr@users.sourceforge.net>
>
> BUG: at include/linux/slub_def.h:77 kmalloc_index()

This was never a bug, and should have been named a warning. It's also gone 
in the current source-tree, since we instead of warning now just return 
ZERO_SIZE_PTR, and if somebody then dereferences that zero-sized 
allocation, then that is the *real* bug.

So I'm sure the patch description is misleading, but I'm not sure whether 
the patch itself is wrong per se. But I'm dropping it for now.

		Linus

[PATCH for 2.6.22] [2/10] x86_64: Fix readahead/sync_file_range/fadvise64 compat calls

[Andi Kleen]

Correctly convert the u64 arguments from 32bit to 64bit.

Pointed out by Heiko Carstens.

I guess this proves Linus' theory that nobody uses the more exotic Linux 
specific syscalls.  It wasn't discovered by a user.

Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/x86_64/ia32/ia32entry.S |    6 +++---
 arch/x86_64/ia32/sys_ia32.c  |   19 +++++++++++++++++++
 2 files changed, 22 insertions(+), 3 deletions(-)

Index: linux/arch/x86_64/ia32/ia32entry.S
===================================================================
--- linux.orig/arch/x86_64/ia32/ia32entry.S
+++ linux/arch/x86_64/ia32/ia32entry.S
@@ -620,7 +620,7 @@ ia32_sys_call_table:
 	.quad quiet_ni_syscall		/* tux */
 	.quad quiet_ni_syscall    	/* security */
 	.quad sys_gettid	
-	.quad sys_readahead	/* 225 */
+	.quad sys32_readahead	/* 225 */
 	.quad sys_setxattr
 	.quad sys_lsetxattr
 	.quad sys_fsetxattr
@@ -645,7 +645,7 @@ ia32_sys_call_table:
 	.quad compat_sys_io_getevents
 	.quad compat_sys_io_submit
 	.quad sys_io_cancel
-	.quad sys_fadvise64		/* 250 */
+	.quad sys32_fadvise64		/* 250 */
 	.quad quiet_ni_syscall 	/* free_huge_pages */
 	.quad sys_exit_group
 	.quad sys32_lookup_dcookie
@@ -709,7 +709,7 @@ ia32_sys_call_table:
 	.quad compat_sys_set_robust_list
 	.quad compat_sys_get_robust_list
 	.quad sys_splice
-	.quad sys_sync_file_range
+	.quad sys32_sync_file_range
 	.quad sys_tee			/* 315 */
 	.quad compat_sys_vmsplice
 	.quad compat_sys_move_pages
Index: linux/arch/x86_64/ia32/sys_ia32.c
===================================================================
--- linux.orig/arch/x86_64/ia32/sys_ia32.c
+++ linux/arch/x86_64/ia32/sys_ia32.c
@@ -860,3 +860,22 @@ long sys32_lookup_dcookie(u32 addr_low, 
 	return sys_lookup_dcookie(((u64)addr_high << 32) | addr_low, buf, len);
 }
 
+asmlinkage ssize_t sys32_readahead(int fd, unsigned off_lo, unsigned off_hi, size_t count)
+{
+	return sys_readahead(fd, ((u64)off_hi << 32) | off_lo, count);
+}
+
+asmlinkage long sys32_sync_file_range(int fd, unsigned off_low, unsigned off_hi,
+			   unsigned n_low, unsigned n_hi,  int flags)
+{
+	return sys_sync_file_range(fd,
+				   ((u64)off_hi << 32) | off_low,
+				   ((u64)n_hi << 32) | n_low, flags);
+}
+
+asmlinkage long sys32_fadvise64(int fd, unsigned offset_lo, unsigned offset_hi, size_t len,
+		     int advice)
+{
+	return sys_fadvise64_64(fd, ((u64)offset_hi << 32) | offset_lo,
+				len, advice);
+}

[PATCH for 2.6.22] [3/10] x86_64: Fix eventd/timerfd syscalls

[Andi Kleen]

They had the same syscall number. 

Pointed out by Davide Libenzi

Signed-off-by: Andi Kleen <ak@suse.de>

---
 include/asm-x86_64/unistd.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux/include/asm-x86_64/unistd.h
===================================================================
--- linux.orig/include/asm-x86_64/unistd.h
+++ linux/include/asm-x86_64/unistd.h
@@ -626,9 +626,9 @@ __SYSCALL(__NR_utimensat, sys_utimensat)
 __SYSCALL(__NR_epoll_pwait, sys_epoll_pwait)
 #define __NR_signalfd		282
 __SYSCALL(__NR_signalfd, sys_signalfd)
-#define __NR_timerfd		282
+#define __NR_timerfd		283
 __SYSCALL(__NR_timerfd, sys_timerfd)
-#define __NR_eventfd		283
+#define __NR_eventfd		284
 __SYSCALL(__NR_eventfd, sys_eventfd)
 
 #ifndef __NO_STUBS

[PATCH for 2.6.22] [4/10] x86: Disable DAC on VIA bridges

[Andi Kleen]

Several reports that VIA bridges don't support DAC and corrupt
data.  I don't know if it's fixed, but let's just blacklist
them all for now.

It can be overwritten with iommu=usedac

Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/kernel/pci-dma.c     |   27 +++++++++++++++++++++++++++
 arch/x86_64/kernel/pci-dma.c   |   12 ++++++++++++
 include/asm-i386/dma-mapping.h |    6 ++++++
 3 files changed, 45 insertions(+)

Index: linux/arch/x86_64/kernel/pci-dma.c
===================================================================
--- linux.orig/arch/x86_64/kernel/pci-dma.c
+++ linux/arch/x86_64/kernel/pci-dma.c
@@ -322,5 +322,17 @@ static int __init pci_iommu_init(void)
 	return 0;
 }
 
+#ifdef CONFIG_PCI
+/* Many VIA bridges seem to corrupt data for DAC. Disable it here */
+
+static __devinit void via_no_dac(struct pci_dev *dev)
+{
+	if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI && forbid_dac == 0) {
+		printk(KERN_INFO "PCI: VIA PCI bridge detected. Disabling DAC.\n");
+		forbid_dac = 1;
+	}
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_ANY_ID, via_no_dac);
+#endif
 /* Must execute after PCI subsystem */
 fs_initcall(pci_iommu_init);
Index: linux/arch/i386/kernel/pci-dma.c
===================================================================
--- linux.orig/arch/i386/kernel/pci-dma.c
+++ linux/arch/i386/kernel/pci-dma.c
@@ -12,6 +12,7 @@
 #include <linux/string.h>
 #include <linux/pci.h>
 #include <linux/module.h>
+#include <linux/pci.h>
 #include <asm/io.h>
 
 struct dma_coherent_mem {
@@ -148,3 +149,29 @@ void *dma_mark_declared_memory_occupied(
 	return mem->virt_base + (pos << PAGE_SHIFT);
 }
 EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
+
+#ifdef CONFIG_PCI
+/* Many VIA bridges seem to corrupt data for DAC. Disable it here */
+
+int forbid_dac;
+EXPORT_SYMBOL(forbid_dac);
+
+static __devinit void via_no_dac(struct pci_dev *dev)
+{
+	if ((dev->class >> 8) == PCI_CLASS_BRIDGE_PCI && forbid_dac == 0) {
+		printk(KERN_INFO "PCI: VIA PCI bridge detected. Disabling DAC.\n");
+		forbid_dac = 1;
+	}
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_ANY_ID, via_no_dac);
+
+static int check_iommu(char *s)
+{
+	if (!strcmp(s, "usedac")) {
+		forbid_dac = -1;
+		return 1;
+	}
+	return 0;
+}
+__setup("iommu=", check_iommu);
+#endif
Index: linux/include/asm-i386/dma-mapping.h
===================================================================
--- linux.orig/include/asm-i386/dma-mapping.h
+++ linux/include/asm-i386/dma-mapping.h
@@ -123,6 +123,8 @@ dma_mapping_error(dma_addr_t dma_addr)
 	return 0;
 }
 
+extern int forbid_dac;
+
 static inline int
 dma_supported(struct device *dev, u64 mask)
 {
@@ -134,6 +136,10 @@ dma_supported(struct device *dev, u64 ma
         if(mask < 0x00ffffff)
                 return 0;
 
+	/* Work around chipset bugs */
+	if (forbid_dac > 0 && mask > 0xffffffffULL)
+		return 0;
+
 	return 1;
 }
 

[PATCH for 2.6.22] [5/10] x86_64: Quieten Atari keyboard warnings in Kconfig

[Andi Kleen]

Not directly related to x86, but I got tired of seeing these warnings on every
kconfig update when building on a non m68k box:

drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'

I moved the definition of ATARI_KBD_CORE into drivers/input/keyboard/Kconfig 
so it's always seen by Kconfig.

Cc: geert@linux-m68k.org
Cc: zippel@linux-m68k.org

Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/m68k/Kconfig              |    3 ---
 drivers/input/keyboard/Kconfig |    3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux/drivers/input/keyboard/Kconfig
===================================================================
--- linux.orig/drivers/input/keyboard/Kconfig
+++ linux/drivers/input/keyboard/Kconfig
@@ -164,6 +164,9 @@ config KEYBOARD_AMIGA
 	  To compile this driver as a module, choose M here: the
 	  module will be called amikbd.
 
+config ATARI_KBD_CORE
+	bool
+
 config KEYBOARD_ATARI
 	tristate "Atari keyboard"
 	depends on ATARI
Index: linux/arch/m68k/Kconfig
===================================================================
--- linux.orig/arch/m68k/Kconfig
+++ linux/arch/m68k/Kconfig
@@ -418,9 +418,6 @@ config STRAM_PROC
 	help
 	  Say Y here to report ST-RAM usage statistics in /proc/stram.
 
-config ATARI_KBD_CORE
-	bool
-
 config HEARTBEAT
 	bool "Use power LED as a heartbeat" if AMIGA || APOLLO || ATARI || MAC ||Q40
 	default y if !AMIGA && !APOLLO && !ATARI && !MAC && !Q40 && HP300

Re: [PATCH for 2.6.22] [5/10] x86_64: Quieten Atari keyboard warnings in Kconfig

[Roman Zippel]

Hi,

On Wed, 20 Jun 2007, Andi Kleen wrote:

> Not directly related to x86, but I got tired of seeing these warnings on every
> kconfig update when building on a non m68k box:
> 
> drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
> 
> I moved the definition of ATARI_KBD_CORE into drivers/input/keyboard/Kconfig 
> so it's always seen by Kconfig.

Um, I thought it had been fixed already. (I'm a little busy with other 
things at the moment.)

> Signed-off-by: Andi Kleen <ak@suse.de>

Acked-by: Roman Zippel <zippel@linux-m68k.org>

bye, Roman

[PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Andi Kleen]

It's already annoying that they appear on x86 now -- that's for the 3button
emulation needed on x86 macs -- but at least don't make them default.

Signed-off-by: Andi Kleen <ak@suse.de>

---
 drivers/macintosh/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/drivers/macintosh/Kconfig
===================================================================
--- linux.orig/drivers/macintosh/Kconfig
+++ linux/drivers/macintosh/Kconfig
@@ -2,7 +2,7 @@
 menuconfig MACINTOSH_DRIVERS
 	bool "Macintosh device drivers"
 	depends on PPC || MAC || X86
-	default y
+	default y if MAC
 
 if MACINTOSH_DRIVERS
 

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Olaf Hering]

On Wed, Jun 20, Andi Kleen wrote:

> 
> It's already annoying that they appear on x86 now -- that's for the 3button
> emulation needed on x86 macs -- but at least don't make them default.
> 
> Signed-off-by: Andi Kleen <ak@suse.de>
> 
> ---
>  drivers/macintosh/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux/drivers/macintosh/Kconfig
> ===================================================================
> --- linux.orig/drivers/macintosh/Kconfig
> +++ linux/drivers/macintosh/Kconfig
> @@ -2,7 +2,7 @@
>  menuconfig MACINTOSH_DRIVERS
>  	bool "Macintosh device drivers"
>  	depends on PPC || MAC || X86
> -	default y
> +	default y if MAC

This looks incorrect because my macdrivers were almost gone now when
updating from 2.6.21 to 2.6.22. 
A better one may be something like this, to not lose everything on a G5:

        depends on PPC_PMAC || MAC || X86
        default y if (PPC_PMAC || MAC)

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Olaf Hering]

On Thu, Jun 21, Olaf Hering wrote:

> On Wed, Jun 20, Andi Kleen wrote:

> > It's already annoying that they appear on x86 now -- that's for the 3button
> > emulation needed on x86 macs -- but at least don't make them default.

> > +++ linux/drivers/macintosh/Kconfig
> > @@ -2,7 +2,7 @@
> >  menuconfig MACINTOSH_DRIVERS
> >  	bool "Macintosh device drivers"
> >  	depends on PPC || MAC || X86
> > -	default y
> > +	default y if MAC
> 
> This looks incorrect because my macdrivers were almost gone now when
> updating from 2.6.21 to 2.6.22. 
> A better one may be something like this, to not lose everything on a G5:

This one works. 
Without it, every previously enabled option will default to N during
make oldconfig.
With it, every previously enabled option remains the same because make
oldcconfig does not touch them.



Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 0852d33..dbe9626 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -2,7 +2,7 @@
 menuconfig MACINTOSH_DRIVERS
 	bool "Macintosh device drivers"
 	depends on PPC || MAC || X86
-	default y if MAC
+	default y if (PPC_PMAC || MAC)
 
 if MACINTOSH_DRIVERS
 

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Andi Kleen]

> diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
> index 0852d33..dbe9626 100644
> --- a/drivers/macintosh/Kconfig
> +++ b/drivers/macintosh/Kconfig
> @@ -2,7 +2,7 @@
>  menuconfig MACINTOSH_DRIVERS
>  	bool "Macintosh device drivers"
>  	depends on PPC || MAC || X86
> -	default y if MAC
> +	default y if (PPC_PMAC || MAC)

Ah yes it needs to be PPC_MAC. Sigh. MAC apparently is only the m68k macs.
Patch is good, although I guess it would be better to change this death trap
and always define MAC on PPC MACs too.

-Andi

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Will Schmidt]

On Thu, 2007-06-21 at 19:36 +0200, Olaf Hering wrote:
> On Wed, Jun 20, Andi Kleen wrote:
> 
> > 
> > It's already annoying that they appear on x86 now -- that's for the 3button
> > emulation needed on x86 macs -- but at least don't make them default.
> > 
> > Signed-off-by: Andi Kleen <ak@suse.de>
> > 
> > ---
> >  drivers/macintosh/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux/drivers/macintosh/Kconfig
> > ===================================================================
> > --- linux.orig/drivers/macintosh/Kconfig
> > +++ linux/drivers/macintosh/Kconfig
> > @@ -2,7 +2,7 @@
> >  menuconfig MACINTOSH_DRIVERS
> >  	bool "Macintosh device drivers"
> >  	depends on PPC || MAC || X86
> > -	default y
> > +	default y if MAC
> 
> This looks incorrect because my macdrivers were almost gone now when
> updating from 2.6.21 to 2.6.22. 
> A better one may be something like this, to not lose everything on a G5:
> 
>         depends on PPC_PMAC || MAC || X86
>         default y if (PPC_PMAC || MAC)
> 

I'll second that.  The obvious gotcha is that on a G5, the windfarm
drivers don't get automatically selected, thus the fans run at full
speed, and my office becomes a windtunnel. :-) 

-Will

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Linus Torvalds]

On Thu, 21 Jun 2007, Will Schmidt wrote:
>
> I'll second that.  The obvious gotcha is that on a G5, the windfarm
> drivers don't get automatically selected, thus the fans run at full
> speed, and my office becomes a windtunnel. :-) 

Since when has "default" been anything but "default". It doesn't mean that 
you can't override it. And if "make oldconfig" doesn't take the _old_ 
setting into account over the new one, there's something wrong.

Of course, if there is no actual question, "default" ends up being what it 
always chosen (because no explicit choice is allowed), but in this case 
we're talking about:

	bool "Macintosh device drivers"

which definitely has that question.

		Linus

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

On Thu, Jun 21, Linus Torvalds wrote:

> 
> 
> On Thu, 21 Jun 2007, Will Schmidt wrote:
> >
> > I'll second that.  The obvious gotcha is that on a G5, the windfarm
> > drivers don't get automatically selected, thus the fans run at full
> > speed, and my office becomes a windtunnel. :-) 
> 
> Since when has "default" been anything but "default". It doesn't mean that 
> you can't override it. And if "make oldconfig" doesn't take the _old_ 
> setting into account over the new one, there's something wrong.

I said no to all new options (except IDE_PROC_FS and FIREWIRE), until
CONFIG_MACINTOSH_DRIVERS. If I say y, everything else was disabled.

  mkdir ../$$$$
  gzip  -cd  < /tmp/config.gz > ../$$$$/.config
  make -kj3 O=../$$$$ ARCH=powerpc


[-- Attachment #2: config.gz --]
[-- Type: application/x-gunzip, Size: 9412 bytes --]

Re: [PATCH for 2.6.22] [6/10] x86: Only make Macintosh drivers default on Macs

[Will Schmidt]

On Thu, 2007-06-21 at 20:54 +0200, Olaf Hering wrote:
> On Thu, Jun 21, Linus Torvalds wrote: 
> > 
> > On Thu, 21 Jun 2007, Will Schmidt wrote:
> > >
> > > I'll second that.  The obvious gotcha is that on a G5, the windfarm
> > > drivers don't get automatically selected, thus the fans run at full
> > > speed, and my office becomes a windtunnel. :-) 
> > 
> > Since when has "default" been anything but "default". It doesn't mean that 
> > you can't override it. And if "make oldconfig" doesn't take the _old_ 
> > setting into account over the new one, there's something wrong.

> I said no to all new options (except IDE_PROC_FS and FIREWIRE), until
> CONFIG_MACINTOSH_DRIVERS. If I say y, everything else was disabled.
> 
>   mkdir ../$$$$
>   gzip  -cd  < /tmp/config.gz > ../$$$$/.config
>   make -kj3 O=../$$$$ ARCH=powerpc
> 

I copy in the g5_defconfig and then do my "make oldconfig".   which
eventually prompts with:
	Macintosh device drivers (MACINTOSH_DRIVERS) [N/y] (NEW)     

But I see what got me..    The g5_defconfig hasnt been updated since
before the MACINTOSH_DRIVERS option was added back in April; so I have
no old setting to carry over into the new.

Unless someone beats me to it, I'll spin up a new g5_defconfig via the
ppc-dev list shortly.   :-)

-Will

[PATCH for 2.6.22] [7/10] x86: Disable KPROBES with DEBUG_RODATA for now

[Andi Kleen]

Right now Kprobes cannot write to the write protected kernel text when 
DEBUG_RODATA is enabled. Disallow this in Kconfig for now.

Temporary fix for 2.6.22. In .23 add code to temporarily
unprotect it.

Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/Kconfig.debug   |    1 +
 arch/x86_64/Kconfig.debug |    1 +
 2 files changed, 2 insertions(+)

Index: linux/arch/i386/Kconfig.debug
===================================================================
--- linux.orig/arch/i386/Kconfig.debug
+++ linux/arch/i386/Kconfig.debug
@@ -49,6 +49,7 @@ config DEBUG_PAGEALLOC
 config DEBUG_RODATA
 	bool "Write protect kernel read-only data structures"
 	depends on DEBUG_KERNEL
+	depends on !KPROBES # temporary for 2.6.22
 	help
 	  Mark the kernel read-only data as write-protected in the pagetables,
 	  in order to catch accidental (and incorrect) writes to such const
Index: linux/arch/x86_64/Kconfig.debug
===================================================================
--- linux.orig/arch/x86_64/Kconfig.debug
+++ linux/arch/x86_64/Kconfig.debug
@@ -9,6 +9,7 @@ source "lib/Kconfig.debug"
 config DEBUG_RODATA
        bool "Write protect kernel read-only data structures"
        depends on DEBUG_KERNEL
+       depends on !KPROBES # temporary for 2.6.22
        help
 	 Mark the kernel read-only data as write-protected in the pagetables,
 	 in order to catch accidental (and incorrect) writes to such const data.

[PATCH for 2.6.22] [8/10] x86: change_page_attr bandaids

[Andi Kleen]

- Disable CLFLUSH again; it is still broken. Always do WBINVD.
- Always flush in the i386 case, not only when there are deferred pages.

These are both brute-force inefficient fixes, to be improved
next release cycle.

The changes to i386 are a little more extensive than strictly 
needed (some dead code added), but it is more similar to the x86-64 version 
now and the dead code will be used soon.

Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/mm/pageattr.c   |   30 ++++++++++++++++++------------
 arch/x86_64/mm/pageattr.c |    7 ++++---
 2 files changed, 22 insertions(+), 15 deletions(-)

Index: linux/arch/i386/mm/pageattr.c
===================================================================
--- linux.orig/arch/i386/mm/pageattr.c
+++ linux/arch/i386/mm/pageattr.c
@@ -68,14 +68,23 @@ static struct page *split_large_page(uns
 	return base;
 } 
 
-static void flush_kernel_map(void *arg)
+static void cache_flush_page(struct page *p)
 { 
-	unsigned long adr = (unsigned long)arg;
+	unsigned long adr = (unsigned long)page_address(p);
+	int i;
+	for (i = 0; i < PAGE_SIZE; i += boot_cpu_data.x86_clflush_size)
+		asm volatile("clflush (%0)" :: "r" (adr + i));
+}
+
+static void flush_kernel_map(void *arg)
+{
+	struct list_head *lh = (struct list_head *)arg;
+	struct page *p;
 
-	if (adr && cpu_has_clflush) {
-		int i;
-		for (i = 0; i < PAGE_SIZE; i += boot_cpu_data.x86_clflush_size)
-			asm volatile("clflush (%0)" :: "r" (adr + i));
+	/* High level code is not ready for clflush yet */
+	if (0 && cpu_has_clflush) {
+		list_for_each_entry (p, lh, lru)
+			cache_flush_page(p);
 	} else if (boot_cpu_data.x86_model >= 4)
 		wbinvd();
 
@@ -181,9 +190,9 @@ __change_page_attr(struct page *page, pg
 	return 0;
 } 
 
-static inline void flush_map(void *adr)
+static inline void flush_map(struct list_head *l)
 {
-	on_each_cpu(flush_kernel_map, adr, 1, 1);
+	on_each_cpu(flush_kernel_map, l, 1, 1);
 }
 
 /*
@@ -225,11 +234,8 @@ void global_flush_tlb(void)
 	spin_lock_irq(&cpa_lock);
 	list_replace_init(&df_list, &l);
 	spin_unlock_irq(&cpa_lock);
-	if (!cpu_has_clflush)
-		flush_map(NULL);
+	flush_map(&l);
 	list_for_each_entry_safe(pg, next, &l, lru) {
-		if (cpu_has_clflush)
-			flush_map(page_address(pg));
 		__free_page(pg);
 	}
 }
Index: linux/arch/x86_64/mm/pageattr.c
===================================================================
--- linux.orig/arch/x86_64/mm/pageattr.c
+++ linux/arch/x86_64/mm/pageattr.c
@@ -74,10 +74,11 @@ static void flush_kernel_map(void *arg)
 	struct page *pg;
 
 	/* When clflush is available always use it because it is
-	   much cheaper than WBINVD */
-	if (!cpu_has_clflush)
+	   much cheaper than WBINVD. Disable clflush for now because
+	   the high level code is not ready yet */
+	if (1 || !cpu_has_clflush)
 		asm volatile("wbinvd" ::: "memory");
-	list_for_each_entry(pg, l, lru) {
+	else list_for_each_entry(pg, l, lru) {
 		void *adr = page_address(pg);
 		if (cpu_has_clflush)
 			cache_flush_page(adr);

[PATCH for 2.6.22] [9/10] i386: Disable alternative() patching after boot with DEBUG_RODATA

[Andi Kleen]

Kernel text is protected now so this won't work.

We'll fix it better next time.

Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/kernel/alternative.c |    5 +++++
 1 file changed, 5 insertions(+)

Index: linux/arch/i386/kernel/alternative.c
===================================================================
--- linux.orig/arch/i386/kernel/alternative.c
+++ linux/arch/i386/kernel/alternative.c
@@ -308,6 +308,11 @@ void alternatives_smp_switch(int smp)
 	printk("lockdep: not fixing up alternatives.\n");
 	return;
 #endif
+#ifdef CONFIG_DEBUG_RODATA
+	/* To be fixed properly post 2.6.22 -- need to get writable
+ 	   mappings of the kernel text */
+	return;
+#endif
 
 	if (noreplace_smp || smp_alt_once)
 		return;

Re: [patches] [PATCH for 2.6.22] [9/10] i386: Disable alternative()patching after boot with DEBUG_RO

[Jan Beulich]

>>> Andi Kleen <ak@suse.de> 20.06.07 12:23 >>>
>
>Kernel text is protected now so this won't work.
>
>We'll fix it better next time.
>
>Signed-off-by: Andi Kleen <ak@suse.de>
>
>---
> arch/i386/kernel/alternative.c |    5 +++++
> 1 file changed, 5 insertions(+)
>
>Index: linux/arch/i386/kernel/alternative.c
>===================================================================
>--- linux.orig/arch/i386/kernel/alternative.c
>+++ linux/arch/i386/kernel/alternative.c
>@@ -308,6 +308,11 @@ void alternatives_smp_switch(int smp)
> 	printk("lockdep: not fixing up alternatives.\n");
> 	return;
> #endif
>+#ifdef CONFIG_DEBUG_RODATA
>+	/* To be fixed properly post 2.6.22 -- need to get writable
>+ 	   mappings of the kernel text */
>+	return;
>+#endif
> 
> 	if (noreplace_smp || smp_alt_once)
> 		return;

Why would we need this? mark_rodata_ro() already accounts for the
CONFIG_HOTPLUG_CPU case in that it doesn't write protect .text then.

Jan

Re: [patches] [PATCH for 2.6.22] [9/10] i386: Disable alternative()patching after boot with DEBUG_RO

[Andi Kleen]

		return;
> 
> Why would we need this? mark_rodata_ro() already accounts for the
> CONFIG_HOTPLUG_CPU case in that it doesn't write protect .text then.

True, I missed that. The other code could be removed or this patch be
dropped.

-Andi

[PATCH for 2.6.22] [10/10] x86_64: fix link warning between for .text and .init.text

[Andi Kleen]

From: "Yinghai Lu" <yhlu.kernel@gmail.com>

WARNING: arch/x86_64/kernel/built-in.o(.text+0xace9): Section
mismatch: reference to .init.text: (between 'get_mtrr_state' and
'mtrr_wrmsr')
WARNING: arch/x86_64/kernel/built-in.o(.text+0xad09): Section
mismatch: reference to .init.text: (between 'get_mtrr_state' and
'mtrr_wrmsr')
WARNING: arch/x86_64/kernel/built-in.o(.text+0xad38): Section
mismatch: reference to .init.text: (between 'get_mtrr_state' and
'mtrr_wrmsr')
WARNING: drivers/built-in.o(.text+0x3a680): Section mismatch:
reference to .init.text:acpi_map_pxm_to_node (between 'acpi_get_node'
and 'acpi_lock_ac_dir')

AK: also marked mtrr_bp_init __init to avoid some more warnings

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/kernel/cpu/mtrr/generic.c |    4 ++--
 arch/i386/kernel/cpu/mtrr/main.c    |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux/arch/i386/kernel/cpu/mtrr/generic.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/generic.c
+++ linux/arch/i386/kernel/cpu/mtrr/generic.c
@@ -42,7 +42,7 @@ static int mtrr_show;
 module_param_named(show, mtrr_show, bool, 0);
 
 /*  Get the MSR pair relating to a var range  */
-static void __init
+static void
 get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr)
 {
 	rdmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
@@ -68,7 +68,7 @@ void mtrr_save_fixed_ranges(void *info)
 	get_fixed_ranges(mtrr_state.fixed_ranges);
 }
 
-static void __cpuinit print_fixed(unsigned base, unsigned step, const mtrr_type*types)
+static void print_fixed(unsigned base, unsigned step, const mtrr_type*types)
 {
 	unsigned i;
 
Index: linux/arch/i386/kernel/cpu/mtrr/main.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux/arch/i386/kernel/cpu/mtrr/main.c
@@ -644,7 +644,7 @@ static struct sysdev_driver mtrr_sysdev_
  * initialized (i.e. before smp_init()).
  * 
  */
-void mtrr_bp_init(void)
+__init void mtrr_bp_init(void)
 {
 	init_ifs();
 

Re: [patches] [PATCH for 2.6.22] [10/10] x86_64: fix link warningbetween for .text and .init.text

[Jan Beulich]

This is the right way I think. With mtrr_bp_init being __init, get_mtrr_state
can then also be __init, making the other two changes unnecessary. I had
submitted a patch to that effect about a week ago. Beyond that patch, as
I now looked at this again, it would seem to me that print_fixed can then in
fact also be __init (rather than being __cpuinit).

Jan

>>> Andi Kleen <ak@suse.de> 20.06.07 12:23 >>>

From: "Yinghai Lu" <yhlu.kernel@gmail.com>

WARNING: arch/x86_64/kernel/built-in.o(.text+0xace9): Section
mismatch: reference to .init.text: (between 'get_mtrr_state' and
'mtrr_wrmsr')
WARNING: arch/x86_64/kernel/built-in.o(.text+0xad09): Section
mismatch: reference to .init.text: (between 'get_mtrr_state' and
'mtrr_wrmsr')
WARNING: arch/x86_64/kernel/built-in.o(.text+0xad38): Section
mismatch: reference to .init.text: (between 'get_mtrr_state' and
'mtrr_wrmsr')
WARNING: drivers/built-in.o(.text+0x3a680): Section mismatch:
reference to .init.text:acpi_map_pxm_to_node (between 'acpi_get_node'
and 'acpi_lock_ac_dir')

AK: also marked mtrr_bp_init __init to avoid some more warnings

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Andi Kleen <ak@suse.de>

---
 arch/i386/kernel/cpu/mtrr/generic.c |    4 ++--
 arch/i386/kernel/cpu/mtrr/main.c    |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux/arch/i386/kernel/cpu/mtrr/generic.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/generic.c
+++ linux/arch/i386/kernel/cpu/mtrr/generic.c
@@ -42,7 +42,7 @@ static int mtrr_show;
 module_param_named(show, mtrr_show, bool, 0);
 
 /*  Get the MSR pair relating to a var range  */
-static void __init
+static void
 get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr)
 {
 	rdmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
@@ -68,7 +68,7 @@ void mtrr_save_fixed_ranges(void *info)
 	get_fixed_ranges(mtrr_state.fixed_ranges);
 }
 
-static void __cpuinit print_fixed(unsigned base, unsigned step, const mtrr_type*types)
+static void print_fixed(unsigned base, unsigned step, const mtrr_type*types)
 {
 	unsigned i;
 
Index: linux/arch/i386/kernel/cpu/mtrr/main.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux/arch/i386/kernel/cpu/mtrr/main.c
@@ -644,7 +644,7 @@ static struct sysdev_driver mtrr_sysdev_
  * initialized (i.e. before smp_init()).
  * 
  */
-void mtrr_bp_init(void)
+__init void mtrr_bp_init(void)
 {
 	init_ifs();
 

_______________________________________________
patches mailing list
patches@x86-64.org 
https://www.x86-64.org/mailman/listinfo/patches 

Re: [patches] [PATCH for 2.6.22] [10/10] x86_64: fix link warningbetween for .text and .init.text

[Andi Kleen]

On Wednesday 20 June 2007 14:02:49 Jan Beulich wrote:
> This is the right way I think. With mtrr_bp_init being __init, get_mtrr_state
> can then also be __init, making the other two changes unnecessary. I had
> submitted a patch to that effect about a week ago. Beyond that patch, as
> I now looked at this again, it would seem to me that print_fixed can then in
> fact also be __init (rather than being __cpuinit).

Possible. I'm inclined to just leave it as it is now, don't really
care about some more or less bytes in the init section.

This whole new __init checking is a constant annoyance; nearly
all of these warnings are false positives and it is actually
CONFIG dependent.

-Andi