Re: Linux 2.6.23.3
On Sat, Nov 17, 2007 at 02:15:11AM +0300, Michael Tokarev wrote: > Greg Kroah-Hartman wrote: > > We (the -stable team) are announcing the release of the 2.6.23.3 kernel. > > It contains a number of bugfixes for a number of architecture specific > > issues. > [.4, .5, .6 and .7 follows after .2 and .3] > > I've seen the bunch of patches posted for review - split to several > series. But - out of curiocity - what's the reason to roll each > series into each own stable release? Can't all .2...7 be combined > into a single release (not counting .8 wich contains urgent security > fixes)? (I mean, not with already rolled out stuff, but the original > reasoning for split-releasing them (as opposed to split-reviewing)) Is there something "sacred" about version numbers that we need to be stingy with them as they are a finite resource? :) This way, we have specific, easy to identify points in the development process to help users in case they report problems to let the developers easily narrow down the potential problem. That, and I couldn't think of some other way to name the -rc patches, so I used the minor version number. Because of that, I was forced to name the final releases with the same minor number to keep everyone sane over time. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.3
Greg Kroah-Hartman wrote: > We (the -stable team) are announcing the release of the 2.6.23.3 kernel. > It contains a number of bugfixes for a number of architecture specific > issues. [.4, .5, .6 and .7 follows after .2 and .3] I've seen the bunch of patches posted for review - split to several series. But - out of curiocity - what's the reason to roll each series into each own stable release? Can't all .2...7 be combined into a single release (not counting .8 wich contains urgent security fixes)? (I mean, not with already rolled out stuff, but the original reasoning for split-releasing them (as opposed to split-reviewing)) Thanks. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23.3
diff --git a/Makefile b/Makefile
index c6d545c..b0c2c32 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
-EXTRAVERSION = .2
+EXTRAVERSION = .3
NAME = Arr Matey! A Hairy Bilge Rat!
# *DOCUMENTATION*
diff --git a/arch/i386/boot/boot.h b/arch/i386/boot/boot.h
index 20bab94..3eeb9e5 100644
--- a/arch/i386/boot/boot.h
+++ b/arch/i386/boot/boot.h
@@ -17,6 +17,8 @@
#ifndef BOOT_BOOT_H
#define BOOT_BOOT_H
+#define STACK_SIZE 512 /* Minimum number of bytes for stack */
+
#ifndef __ASSEMBLY__
#include
@@ -198,8 +200,6 @@ static inline int isdigit(int ch)
}
/* Heap -- available for dynamic lists. */
-#define STACK_SIZE 512 /* Minimum number of bytes for stack */
-
extern char _end[];
extern char *HEAP;
extern char *heap_end;
@@ -216,9 +216,9 @@ static inline char *__get_heap(size_t s, size_t a, size_t n)
#define GET_HEAP(type, n) \
((type *)__get_heap(sizeof(type),__alignof__(type),(n)))
-static inline int heap_free(void)
+static inline bool heap_free(size_t n)
{
- return heap_end-HEAP;
+ return (int)(heap_end-HEAP) >= (int)n;
}
/* copy.S */
diff --git a/arch/i386/boot/header.S b/arch/i386/boot/header.S
index f3140e5..fff7059 100644
--- a/arch/i386/boot/header.S
+++ b/arch/i386/boot/header.S
@@ -173,7 +173,8 @@ ramdisk_size: .long 0 # its size in
bytes
bootsect_kludge:
.long 0 # obsolete
-heap_end_ptr: .word _end+1024 # (Header version 0x0201 or later)
+heap_end_ptr: .word _end+STACK_SIZE-512
+ # (Header version 0x0201 or later)
# space from here (exclusive) down to
# end of setup code can be used by setup
# for local heap purposes.
@@ -225,28 +226,53 @@ start_of_setup:
int $0x13
#endif
-# We will have entered with %cs = %ds+0x20, normalize %cs so
-# it is on par with the other segments.
- pushw %ds
- pushw $setup2
- lretw
-
-setup2:
# Force %es = %ds
movw%ds, %ax
movw%ax, %es
cld
-# Stack paranoia: align the stack and make sure it is good
-# for both 16- and 32-bit references. In particular, if we
-# were meant to have been using the full 16-bit segment, the
-# caller might have set %sp to zero, which breaks %esp-based
-# references.
- andw$~3, %sp# dword align (might as well...)
- jnz 1f
- movw$0xfffc, %sp# Make sure we're not zero
-1: movzwl %sp, %esp # Clear upper half of %esp
- sti
+# Apparently some ancient versions of LILO invoked the kernel
+# with %ss != %ds, which happened to work by accident for the
+# old code. If the CAN_USE_HEAP flag is set in loadflags, or
+# %ss != %ds, then adjust the stack pointer.
+
+ # Smallest possible stack we can tolerate
+ movw$(_end+STACK_SIZE), %cx
+
+ movwheap_end_ptr, %dx
+ addw$512, %dx
+ jnc 1f
+ xorw%dx, %dx# Wraparound - whole segment available
+1: testb $CAN_USE_HEAP, loadflags
+ jnz 2f
+
+ # No CAN_USE_HEAP
+ movw%ss, %dx
+ cmpw%ax, %dx# %ds == %ss?
+ movw%sp, %dx
+ # If so, assume %sp is reasonably set, otherwise use
+ # the smallest possible stack.
+ jne 4f # -> Smallest possible stack...
+
+ # Make sure the stack is at least minimum size. Take a value
+ # of zero to mean "full segment."
+2:
+ andw$~3, %dx# dword align (might as well...)
+ jnz 3f
+ movw$0xfffc, %dx# Make sure we're not zero
+3: cmpw%cx, %dx
+ jnb 5f
+4: movw%cx, %dx# Minimum value we can possibly use
+5: movw%ax, %ss
+ movzwl %dx, %esp # Clear upper half of %esp
+ sti # Now we should have a working stack
+
+# We will have entered with %cs = %ds+0x20, normalize %cs so
+# it is on par with the other segments.
+ pushw %ds
+ pushw $6f
+ lretw
+6:
# Check signature at end of setup
cmpl$0x5a5aaa55, setup_sig
diff --git a/arch/i386/boot/video-bios.c b/arch/i386/boot/video-bios.c
index 68e65d9..ed0672a 100644
--- a/arch/i386/boot/video-bios.c
+++ b/arch/i386/boot/video-bios.c
@@ -79,7 +79,7 @@ static int bios_probe(void)
video_bios.modes = GET_HEAP(struct mode_info, 0);
for (mode = 0x14; mode <= 0x7f; mode++) {
- if (heap_free() < sizeof(struct mode_info))
+ if (!heap_free(sizeof(struct mode_info)))
break;
if (mode_defined(VIDEO_FIRST_BIOS+mode))
diff --git a/arch/i386/boot/video-vesa.c b/arch/i386/boot/video-vesa.c
index 1921907..4716b9a 100644
--- a/arch/i386/boot/video-vesa.c
+++ b/arch/i386/boot/video-vesa.c
@@ -57,7 +57,7 @@
Linux 2.6.23.3
We (the -stable team) are announcing the release of the 2.6.23.3 kernel. It contains a number of bugfixes for a number of architecture specific issues. I'll also be replying to this message with a copy of the patch between 2.6.23.2 and 2.6.23.3 The updated 2.6.23.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=summary thanks, greg k-h Makefile |2 - arch/i386/boot/boot.h |8 ++-- arch/i386/boot/header.S| 62 +++-- arch/i386/boot/video-bios.c|2 - arch/i386/boot/video-vesa.c|2 - arch/i386/boot/video.c |2 - arch/i386/kernel/tsc.c |5 +- arch/i386/xen/enlighten.c | 57 -- arch/i386/xen/mmu.c| 29 +-- arch/i386/xen/multicalls.c | 29 +-- arch/i386/xen/multicalls.h |3 + arch/i386/xen/xen-ops.h|1 arch/mips/mm/c-r4k.c | 21 +-- arch/powerpc/math-emu/math.c | 13 -- arch/powerpc/platforms/cell/axon_msi.c |4 +- arch/sparc64/kernel/sys_sparc.c|2 - arch/sparc64/lib/xor.S | 12 +++--- arch/um/Makefile |3 + arch/um/include/common-offsets.h |1 arch/um/include/sysdep-i386/stub.h |3 - arch/um/kernel/skas/clone.c|1 arch/um/os-Linux/main.c|1 arch/um/os-Linux/skas/mem.c|1 arch/um/os-Linux/skas/process.c|2 - arch/um/os-Linux/start_up.c|1 arch/um/os-Linux/tt.c |1 arch/um/os-Linux/util.c| 38 arch/um/sys-i386/user-offsets.c|6 +-- arch/um/sys-x86_64/user-offsets.c |9 arch/x86_64/mm/init.c |6 --- arch/x86_64/mm/pageattr.c |9 +++- fs/xfs/linux-2.6/xfs_buf.c | 13 ++ include/asm-mips/hazards.h | 54 include/linux/bootmem.h|1 include/xen/interface/vcpu.h |5 +- mm/sparse.c| 11 - 36 files changed, 308 insertions(+), 112 deletions(-) Summary of changes from v2.6.23.2 to v2.6.23.3 == Chris Wright (1): Fix sparc64 MAP_FIXED handling of framebuffer mmaps Dave Johnson (1): x86: fix TSC clock source calibration error David Miller (1): Fix sparc64 niagara optimized RAID xor asm Greg Kroah-Hartman (1): Linux 2.6.23.3 H. Peter Anvin (2): x86 setup: handle boot loaders which set up the stack incorrectly x86 setup: sizeof() is unsigned, unbreak comparisons Ingo Molnar (1): x86: fix global_flush_tlb() bug Jeff Dike (3): UML - Stop using libc asm/page.h UML - Fix kernel vs libc symbols clash UML - stop using libc asm/user.h Jeremy Fitzhardinge (4): xen: add batch completion callbacks xen: deal with stale cr3 values when unpinning pagetables xen: fix incorrect vcpu_register_vcpu_info hypercall argument xfs: eagerly remove vmap mappings to avoid upsetting Xen Kumar Gala (1): POWERPC: Fix handling of stfiwx math emulation Lepton Wu (1): UML - kill subprocesses on exit Linus Torvalds (1): revert "x86_64: allocate sparsemem memmap above 4G" Michael Ellerman (1): POWERPC: Make sure to of_node_get() the result of pci_device_to_OF_node() Ralf Baechle (2): MIPS: MT: Fix bug in multithreaded kernels. MIPS: R1: Fix hazard barriers to make kernels work on R2 also. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
