Skip to contentSkip to conversation

X86 late bug fixes for 2.6.22

PATCH In review Andi Kleen 6 participants 24 messages Jun 20, 2007 – Jun 22, 2007

Subsystems (3)
lore
Share & tools
lore

Andi Kleen

author
#0 lore raw

cover X86 late bug fixes for 2.6.22

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

author
#1 lore raw

PATCH 1/10 i386: bug in i386 MTRR initialization

From: Andrea Righi <[email protected]>

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.

---
 arch/i386/kernel/cpu/mtrr/generic.c |    3 +++
 arch/i386/kernel/cpu/mtrr/main.c    |    5 +++++
 2 files changed, 8 insertions(+)
arch/i386/kernel/cpu/mtrr/generic.c +3 -0
Index: 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);
arch/i386/kernel/cpu/mtrr/main.c +5 -0
Index: 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) {
#2 lore raw

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

Quoted 4 lines · Andi Kleen

From: Andrea Righi <[email protected]>

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

author
#3 lore raw

PATCH 2/10 x86_64: Fix readahead/sync_file_range/fadvise64 compat calls

In reply to 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.

---
 arch/x86_64/ia32/ia32entry.S |    6 +++---
 arch/x86_64/ia32/sys_ia32.c  |   19 +++++++++++++++++++
 2 files changed, 22 insertions(+), 3 deletions(-)
arch/x86_64/ia32/ia32entry.S +3 -3
Index: 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
arch/x86_64/ia32/sys_ia32.c +19 -0
Index: 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);
+}
author
#4 lore raw

PATCH 3/10 x86_64: Fix eventd/timerfd syscalls

In reply to Andi Kleen

They had the same syscall number.

Pointed out by Davide Libenzi

---
 include/asm-x86_64/unistd.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
include/asm-x86_64/unistd.h +2 -2
Index: 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
author
#5 lore raw

PATCH 4/10 x86: Disable DAC on VIA bridges

In reply to 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

---
 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(+)
arch/x86_64/kernel/pci-dma.c +12 -0
Index: 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);
arch/i386/kernel/pci-dma.c +27 -0
Index: 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
include/asm-i386/dma-mapping.h +6 -0
Index: 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;
 }
 
author
#6 lore raw

PATCH 5/10 x86_64: Quieten Atari keyboard warnings in Kconfig

In reply to 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.

---
 arch/m68k/Kconfig              |    3 ---
 drivers/input/keyboard/Kconfig |    3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/input/keyboard/Kconfig +3 -0
Index: 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
arch/m68k/Kconfig +0 -3
Index: 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
Acked-by on v1 5/10
#7 lore raw

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

Hi,

Quoted 8 lines · 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.

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

Quoted 1 line

bye, Roman

author
#8 lore raw

PATCH 6/10 x86: Only make Macintosh drivers default on Macs

In reply to 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.

---
 drivers/macintosh/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/macintosh/Kconfig +1 -1
Index: 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
 
#9 lore raw

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

Quoted 15 lines · 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.

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

Index: linux/drivers/macintosh/Kconfig
===================================================================

drivers/macintosh/Kconfig line 5

Quoted 5 lines
drivers/macintosh/Kconfig +1 -1
@@ -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)
#10 lore raw

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

Quoted 5 lines · Olaf Hering
Quoted 2 lines · 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.

Quoted 11 lines

Review line 5

Quoted 7 lines

+++ linux/drivers/macintosh/Kconfig

(quoted diff) +1 -1
@@ -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.

drivers/macintosh/Kconfig +1 -1
index 0852d33..dbe9626 100644
@@ -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
 
author
#11 lore raw

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

drivers/macintosh/Kconfig line 5

Quoted 11 lines
drivers/macintosh/Kconfig +1 -1
index 0852d33..dbe9626 100644
@@ -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

#12 lore raw

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

In reply to Olaf Hering
Quoted 27 lines · Olaf Hering
Quoted 15 lines · 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.

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

Index: linux/drivers/macintosh/Kconfig
===================================================================

drivers/macintosh/Kconfig line 5

Quoted 5 lines
drivers/macintosh/Kconfig +1 -1
@@ -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:

Quoted 3 lines
        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

#13 lore raw

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

Quoted 4 lines · Will Schmidt

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

#14 lore raw

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

Quoted 11 lines · Linus Torvalds
Quoted 4 lines · Will Schmidt

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

#15 lore raw

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

Quoted 12 lines · Olaf Hering
Quoted 10 lines · Linus Torvalds
Quoted 4 lines · Will Schmidt

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.

Quoted 7 lines

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

author
#16 lore raw

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

In reply to 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.

---
 arch/i386/Kconfig.debug   |    1 +
 arch/x86_64/Kconfig.debug |    1 +
 2 files changed, 2 insertions(+)
arch/i386/Kconfig.debug +1 -0
Index: 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
arch/x86_64/Kconfig.debug +1 -0
Index: 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.
author
#17 lore raw

PATCH 8/10 x86: change_page_attr bandaids

In reply to 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.

---
 arch/i386/mm/pageattr.c   |   30 ++++++++++++++++++------------
 arch/x86_64/mm/pageattr.c |    7 ++++---
 2 files changed, 22 insertions(+), 15 deletions(-)
arch/i386/mm/pageattr.c +18 -12
Index: 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);
 	}
 }
arch/x86_64/mm/pageattr.c +4 -3
Index: 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);
author
#18 lore raw

PATCH 9/10 i386: Disable alternative() patching after boot with DEBUG_RODATA

In reply to Andi Kleen

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

We'll fix it better next time.

---
 arch/i386/kernel/alternative.c |    5 +++++
 1 file changed, 5 insertions(+)
arch/i386/kernel/alternative.c +5 -0
Index: 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;
#19 lore raw

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

Quoted 18 lines
Quoted 1 line
Quoted 1 line

Andi Kleen <[email protected]> 20.06.07 12:23 >>>

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

We'll fix it better next time.

---
arch/i386/kernel/alternative.c | 5 +++++

1 file changed, 5 insertions(+)

Index: linux/arch/i386/kernel/alternative.c
===================================================================

arch/i386/kernel/alternative.c +0 -0
@@ -308,6 +308,11 @@ void alternatives_smp_switch(int smp)
 	printk("lockdep: not fixing up alternatives.\n");

arch/i386/kernel/alternative.c void alternatives_smp_switch(int smp) · line 318

Quoted 10 lines
arch/i386/kernel/alternative.c +5 -0
 	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

author
#20 lore raw

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

		return;
Quoted 3 lines

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

author
#21 lore raw

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

In reply to Andi Kleen

From: "Yinghai Lu" <[email protected]>

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

---
 arch/i386/kernel/cpu/mtrr/generic.c |    4 ++--
 arch/i386/kernel/cpu/mtrr/main.c    |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
arch/i386/kernel/cpu/mtrr/generic.c +2 -2
Index: 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;
 
arch/i386/kernel/cpu/mtrr/main.c +1 -1
Index: 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();
 
#22 lore raw

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

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

Quoted 1 line
Quoted 1 line
Quoted 1 line

Andi Kleen <[email protected]> 20.06.07 12:23 >>>

From: "Yinghai Lu" <[email protected]>

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

---
 arch/i386/kernel/cpu/mtrr/generic.c |    4 ++--
 arch/i386/kernel/cpu/mtrr/main.c    |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
arch/i386/kernel/cpu/mtrr/generic.c +2 -2
Index: 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;
 
arch/i386/kernel/cpu/mtrr/main.c +1 -1
Index: 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
[email protected]
https://www.x86-64.org/mailman/listinfo/patches

author
#23 lore raw

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

Quoted 5 lines · 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