* Oops: ptrace fix buggy
@ 2003-04-07 12:22 Michael Lampe
2003-04-12 7:13 ` Ken Brownfield
0 siblings, 1 reply; 20+ messages in thread
From: Michael Lampe @ 2003-04-07 12:22 UTC (permalink / raw)
To: linux-kernel
Since I upgraded from 2.4.20 to 2.4.21-pre6, totalview dies with a
segfault right after reading symbol information. The interesting
thing is that it also reproducibly triggers the following Oops.
-----------------
ksymoops 2.4.3 on i686 2.4.21-pre6. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-pre6/ (default)
-m /boot/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Apr 6 00:28:18 sam kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000007c
Apr 6 00:28:18 sam kernel: c0118c33
Apr 6 00:28:18 sam kernel: *pde = 00000000
Apr 6 00:28:18 sam kernel: Oops: 0000
Apr 6 00:28:18 sam kernel: CPU: 0
Apr 6 00:28:18 sam kernel: EIP: 0010:[<c0118c33>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Apr 6 00:28:18 sam kernel: EFLAGS: 00010202
Apr 6 00:28:18 sam kernel: eax: 00000000 ebx: 00000001 ecx: 00000476 edx: cba1e000
Apr 6 00:28:18 sam kernel: esi: 00000007 edi: cba1e000 ebp: ffffffff esp: c44d3f98
Apr 6 00:28:18 sam kernel: ds: 0018 es: 0018 ss: 0018
Apr 6 00:28:18 sam kernel: Process tv6main (pid: 1137, stackpage=c44d3000)
Apr 6 00:28:18 sam kernel: Stack: c0109bd3 cba1e000 00000000 c44d2000 00000009 00000007 bfffef64 00000000
Apr 6 00:28:18 sam kernel: c0106cc4 c44d3fc4 c0106bd3 00000007 00000476 00000001 00000009 00000007
Apr 6 00:28:18 sam kernel: bfffef64 0000001a 0000002b 0000002b 0000001a 400e92b6 00000023 00000202
Apr 6 00:28:18 sam kernel: Call Trace: [<c0109bd3>] [<c0106cc4>] [<c0106bd3>]
Apr 6 00:28:18 sam kernel: Code: f6 40 7c 01 75 07 b8 ff ff ff ff c3 90 f6 42 18 01 75 0a b8
>>EIP; c0118c32 <ptrace_check_attach+12/50> <=====
Trace; c0109bd2 <sys_ptrace+b6/580>
Trace; c0106cc4 <error_code+34/3c>
Trace; c0106bd2 <system_call+32/38>
Code; c0118c32 <ptrace_check_attach+12/50>
00000000 <_EIP>:
Code; c0118c32 <ptrace_check_attach+12/50> <=====
0: f6 40 7c 01 testb $0x1,0x7c(%eax) <=====
Code; c0118c36 <ptrace_check_attach+16/50>
4: 75 07 jne d <_EIP+0xd> c0118c3e <ptrace_check_attach+1e/50>
Code; c0118c38 <ptrace_check_attach+18/50>
6: b8 ff ff ff ff mov $0xffffffff,%eax
Code; c0118c3c <ptrace_check_attach+1c/50>
b: c3 ret
Code; c0118c3e <ptrace_check_attach+1e/50>
c: 90 nop
Code; c0118c3e <ptrace_check_attach+1e/50>
d: f6 42 18 01 testb $0x1,0x18(%edx)
Code; c0118c42 <ptrace_check_attach+22/50>
11: 75 0a jne 1d <_EIP+0x1d> c0118c4e <ptrace_check_attach+2e/50>
Code; c0118c44 <ptrace_check_attach+24/50>
13: b8 00 00 00 00 mov $0x0,%eax
1 warning issued. Results may not be reliable.
-----------------
/usr/src/linux# sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux sam 2.4.21-pre6 #2 Tue Mar 4 04:19:42 CET 2003 i686 unknown
Gnu C 2.95.3
Gnu make 3.79.1
util-linux 2.11q
mount 2.11q
modutils 2.4.18
e2fsprogs 1.32
reiserfsprogs 3.6.5
Linux C Library x 1 root root 1371591 Nov 10 19:17 /lib/libc.so.6
Dynamic linker (ldd) 2.2.5
Procps 2.0.7
Net-tools 1.60
Kbd 0.99
Sh-utils 2.0
Modules Loaded mga agpgart
-----------------
/usr/src/linux# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Celeron (Mendocino)
stepping : 5
cpu MHz : 434.323
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 865.07
-----------------
-Michael
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: Oops: ptrace fix buggy 2003-04-07 12:22 Oops: ptrace fix buggy Michael Lampe @ 2003-04-12 7:13 ` Ken Brownfield 2003-04-12 9:54 ` Marc-Christian Petersen 0 siblings, 1 reply; 20+ messages in thread From: Ken Brownfield @ 2003-04-12 7:13 UTC (permalink / raw) To: linux-kernel I'm reproducing this as well when using gdb. Two oopses attached. This is with the ptrace patch applied to 2.4.20 (SMP/i386/P3). Thanks, -- Ken. brownfld@irridia.com Code: f6 40 7c 01 75 07 b8 ff ff ff ff c3 90 f6 42 18 01 74 1d b8 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: f6 40 7c 01 testb $0x1,0x7c(%eax) Code; 00000004 Before first symbol 4: 75 07 jne d <_EIP+0xd> 0000000d Before first symbol Code; 00000006 Before first symbol 6: b8 ff ff ff ff mov $0xffffffff,%eax Code; 0000000b Before first symbol b: c3 ret Code; 0000000c Before first symbol c: 90 nop Code; 0000000d Before first symbol d: f6 42 18 01 testb $0x1,0x18(%edx) Code; 00000011 Before first symbol 11: 74 1d je 30 <_EIP+0x30> 00000030 Before first symbol Code; 00000013 Before first symbol 13: b8 00 00 00 00 mov $0x0,%eax Unable to handle kernel NULL pointer dereference at virtual address 0000007c c01211a3 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[<c01211a3>] Not tainted EFLAGS: 00010202 eax: 00000000 ebx: ffffffff ecx: e75a0000 edx: d2746000 esi: 00000000 edi: d2746000 ebp: 40036110 esp: e75a1f8c ds: 0018 es: 0018 ss: 0018 Process gdb (pid: 28490, stackpage=e75a1000) Stack: c010c576 d2746000 00000000 e75a0000 00000000 00000005 bffff17c 00000004 bfffeed8 e75a0000 00000000 e75a0000 e75a1fc4 c0108b97 00000005 0000469b 40036110 00000000 00000005 bffff17c 0000001a 0000002b 0000002b 0000001a Call Trace: [<c010c576>] [<c0108b97>] Code: f6 40 7c 01 75 07 b8 ff ff ff ff c3 90 f6 42 18 01 74 1d b8 >>EIP; c01211a3 <ptrace_check_attach+13/84> <===== Trace; c010c576 <sys_ptrace+10a/608> Trace; c0108b97 <system_call+2f/34> Code; c01211a3 <ptrace_check_attach+13/84> 00000000 <_EIP>: Code; c01211a3 <ptrace_check_attach+13/84> <===== 0: f6 40 7c 01 testb $0x1,0x7c(%eax) <===== Code; c01211a7 <ptrace_check_attach+17/84> 4: 75 07 jne d <_EIP+0xd> c01211b0 <ptrace_check_attach+20/84> Code; c01211a9 <ptrace_check_attach+19/84> 6: b8 ff ff ff ff mov $0xffffffff,%eax Code; c01211ae <ptrace_check_attach+1e/84> b: c3 ret Code; c01211af <ptrace_check_attach+1f/84> c: 90 nop Code; c01211b0 <ptrace_check_attach+20/84> d: f6 42 18 01 testb $0x1,0x18(%edx) Code; c01211b4 <ptrace_check_attach+24/84> 11: 74 1d je 30 <_EIP+0x30> c01211d3 <ptrace_check_attach+43/84> Code; c01211b6 <ptrace_check_attach+26/84> 13: b8 00 00 00 00 mov $0x0,%eax On Mon, Apr 07, 2003 at 02:22:05PM +0200, Michael Lampe wrote: | Since I upgraded from 2.4.20 to 2.4.21-pre6, totalview dies with a | segfault right after reading symbol information. The interesting | thing is that it also reproducibly triggers the following Oops. | | ----------------- | | ksymoops 2.4.3 on i686 2.4.21-pre6. Options used | -V (default) | -k /proc/ksyms (default) | -l /proc/modules (default) | -o /lib/modules/2.4.21-pre6/ (default) | -m /boot/System.map (default) | | Warning: You did not tell me where to find symbol information. I will | assume that the log matches the kernel and modules that are running | right now and I'll use the default options above for symbol resolution. | If the current kernel and/or modules do not match the log, you can get | more accurate output by telling me the kernel version and where to find | map, modules, ksyms etc. ksymoops -h explains the options. | | Apr 6 00:28:18 sam kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000007c | Apr 6 00:28:18 sam kernel: c0118c33 | Apr 6 00:28:18 sam kernel: *pde = 00000000 | Apr 6 00:28:18 sam kernel: Oops: 0000 | Apr 6 00:28:18 sam kernel: CPU: 0 | Apr 6 00:28:18 sam kernel: EIP: 0010:[<c0118c33>] Not tainted | Using defaults from ksymoops -t elf32-i386 -a i386 | Apr 6 00:28:18 sam kernel: EFLAGS: 00010202 | Apr 6 00:28:18 sam kernel: eax: 00000000 ebx: 00000001 ecx: 00000476 edx: cba1e000 | Apr 6 00:28:18 sam kernel: esi: 00000007 edi: cba1e000 ebp: ffffffff esp: c44d3f98 | Apr 6 00:28:18 sam kernel: ds: 0018 es: 0018 ss: 0018 | Apr 6 00:28:18 sam kernel: Process tv6main (pid: 1137, stackpage=c44d3000) | Apr 6 00:28:18 sam kernel: Stack: c0109bd3 cba1e000 00000000 c44d2000 00000009 00000007 bfffef64 00000000 | Apr 6 00:28:18 sam kernel: c0106cc4 c44d3fc4 c0106bd3 00000007 00000476 00000001 00000009 00000007 | Apr 6 00:28:18 sam kernel: bfffef64 0000001a 0000002b 0000002b 0000001a 400e92b6 00000023 00000202 | Apr 6 00:28:18 sam kernel: Call Trace: [<c0109bd3>] [<c0106cc4>] [<c0106bd3>] | Apr 6 00:28:18 sam kernel: Code: f6 40 7c 01 75 07 b8 ff ff ff ff c3 90 f6 42 18 01 75 0a b8 | | >>EIP; c0118c32 <ptrace_check_attach+12/50> <===== | Trace; c0109bd2 <sys_ptrace+b6/580> | Trace; c0106cc4 <error_code+34/3c> | Trace; c0106bd2 <system_call+32/38> | Code; c0118c32 <ptrace_check_attach+12/50> | 00000000 <_EIP>: | Code; c0118c32 <ptrace_check_attach+12/50> <===== | 0: f6 40 7c 01 testb $0x1,0x7c(%eax) <===== | Code; c0118c36 <ptrace_check_attach+16/50> | 4: 75 07 jne d <_EIP+0xd> c0118c3e <ptrace_check_attach+1e/50> | Code; c0118c38 <ptrace_check_attach+18/50> | 6: b8 ff ff ff ff mov $0xffffffff,%eax | Code; c0118c3c <ptrace_check_attach+1c/50> | b: c3 ret | Code; c0118c3e <ptrace_check_attach+1e/50> | c: 90 nop | Code; c0118c3e <ptrace_check_attach+1e/50> | d: f6 42 18 01 testb $0x1,0x18(%edx) | Code; c0118c42 <ptrace_check_attach+22/50> | 11: 75 0a jne 1d <_EIP+0x1d> c0118c4e <ptrace_check_attach+2e/50> | Code; c0118c44 <ptrace_check_attach+24/50> | 13: b8 00 00 00 00 mov $0x0,%eax | | | 1 warning issued. Results may not be reliable. | | ----------------- | | /usr/src/linux# sh scripts/ver_linux | If some fields are empty or look unusual you may have an old version. | Compare to the current minimal requirements in Documentation/Changes. | | Linux sam 2.4.21-pre6 #2 Tue Mar 4 04:19:42 CET 2003 i686 unknown | | Gnu C 2.95.3 | Gnu make 3.79.1 | util-linux 2.11q | mount 2.11q | modutils 2.4.18 | e2fsprogs 1.32 | reiserfsprogs 3.6.5 | Linux C Library x 1 root root 1371591 Nov 10 19:17 /lib/libc.so.6 | Dynamic linker (ldd) 2.2.5 | Procps 2.0.7 | Net-tools 1.60 | Kbd 0.99 | Sh-utils 2.0 | Modules Loaded mga agpgart | | ----------------- | | /usr/src/linux# cat /proc/cpuinfo | processor : 0 | vendor_id : GenuineIntel | cpu family : 6 | model : 6 | model name : Celeron (Mendocino) | stepping : 5 | cpu MHz : 434.323 | cache size : 128 KB | fdiv_bug : no | hlt_bug : no | f00f_bug : no | coma_bug : no | fpu : yes | fpu_exception : yes | cpuid level : 2 | wp : yes | flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr | bogomips : 865.07 | | ----------------- | | -Michael | - | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in | the body of a message to majordomo@vger.kernel.org | More majordomo info at http://vger.kernel.org/majordomo-info.html | Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-12 7:13 ` Ken Brownfield @ 2003-04-12 9:54 ` Marc-Christian Petersen 2003-04-14 13:34 ` James Bourne 0 siblings, 1 reply; 20+ messages in thread From: Marc-Christian Petersen @ 2003-04-12 9:54 UTC (permalink / raw) To: Ken Brownfield, linux-kernel [-- Attachment #1: Type: text/plain, Size: 251 bytes --] On Saturday 12 April 2003 09:13, Ken Brownfield wrote: Hi Ken, > I'm reproducing this as well when using gdb. Two oopses attached. > This is with the ptrace patch applied to 2.4.20 (SMP/i386/P3). Does the attached patch fixes the issue? ciao, Marc [-- Attachment #2: ptrace-oops-fix.patch --] [-- Type: text/x-diff, Size: 618 bytes --] diff -Naurp linux-2.4.20/include/linux/sched.h linux-2.4.20-ptrace/include/linux/sched.h --- linux-2.4.20/include/linux/sched.h 2003-03-20 14:35:49.000000000 +0100 +++ linux-2.4.20-ptrace/include/linux/sched.h 2003-04-07 18:20:45.000000000 +0200 @@ -478,7 +479,7 @@ struct task_struct { #define PT_TRACESYSGOOD 0x00000008 #define PT_PTRACE_CAP 0x00000010 /* ptracer can follow suid-exec */ -#define is_dumpable(tsk) ((tsk)->task_dumpable && (tsk)->mm->dumpable) +#define is_dumpable(tsk) ((tsk)->task_dumpable && (tsk)->mm && (tsk)->mm->dumpable) /* * Limit the stack by to some sane default: root can always ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-12 9:54 ` Marc-Christian Petersen @ 2003-04-14 13:34 ` James Bourne 2003-04-14 13:46 ` Jörn Engel 0 siblings, 1 reply; 20+ messages in thread From: James Bourne @ 2003-04-14 13:34 UTC (permalink / raw) To: Ken Brownfield; +Cc: Marc-Christian Petersen, linux-kernel On Sat, 12 Apr 2003, Marc-Christian Petersen wrote: > On Saturday 12 April 2003 09:13, Ken Brownfield wrote: > > Hi Ken, > > > I'm reproducing this as well when using gdb. Two oopses attached. > > This is with the ptrace patch applied to 2.4.20 (SMP/i386/P3). > Does the attached patch fixes the issue? Hi, This patch has also been added to the update patch available at http://www.hardrock.org/kernel/current-updates/linux-2.4.20-updates.patch This patch includes the ptrace patch, tg3 patch, and ext3 patches. It also changes the EXTRAVERSION to -uv2. Regards James Bourne > > ciao, Marc -- James Bourne | Email: jbourne@hardrock.org Unix Systems Administrator | WWW: http://www.hardrock.org Custom Unix Programming | Linux: The choice of a GNU generation ---------------------------------------------------------------------- "All you need's an occasional kick in the philosophy." Frank Herbert ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 13:34 ` James Bourne @ 2003-04-14 13:46 ` Jörn Engel 2003-04-14 13:56 ` James Bourne 2003-04-14 14:31 ` Martin Schlemmer 0 siblings, 2 replies; 20+ messages in thread From: Jörn Engel @ 2003-04-14 13:46 UTC (permalink / raw) To: James Bourne; +Cc: Ken Brownfield, Marc-Christian Petersen, linux-kernel On Mon, 14 April 2003 07:34:54 -0600, James Bourne wrote: > > This patch has also been added to the update patch available at > http://www.hardrock.org/kernel/current-updates/linux-2.4.20-updates.patch > > This patch includes the ptrace patch, tg3 patch, and ext3 patches. It also > changes the EXTRAVERSION to -uv2. Privately, I have introduced a variable FIXLEVEL for this. The resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo is more suiting for a fixed stable kernel. Are you interested in this patch? Jörn -- If you're willing to restrict the flexibility of your approach, you can almost always do something better. -- John Carmack ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 13:46 ` Jörn Engel @ 2003-04-14 13:56 ` James Bourne 2003-04-14 14:22 ` Jörn Engel 2003-04-14 14:31 ` Martin Schlemmer 1 sibling, 1 reply; 20+ messages in thread From: James Bourne @ 2003-04-14 13:56 UTC (permalink / raw) To: Jörn Engel; +Cc: Ken Brownfield, Marc-Christian Petersen, linux-kernel On Mon, 14 Apr 2003, Jörn Engel wrote: > On Mon, 14 April 2003 07:34:54 -0600, James Bourne wrote: > > > > This patch has also been added to the update patch available at > > http://www.hardrock.org/kernel/current-updates/linux-2.4.20-updates.patch > > > > This patch includes the ptrace patch, tg3 patch, and ext3 patches. It also > > changes the EXTRAVERSION to -uv2. > > Privately, I have introduced a variable FIXLEVEL for this. The > resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo > is more suiting for a fixed stable kernel. > > Are you interested in this patch? Hi, Sure, if you have the patch already please send it along. I think this was suggested once before as well. Thanks and regards James Bourne > > Jörn > > -- James Bourne | Email: jbourne@hardrock.org Unix Systems Administrator | WWW: http://www.hardrock.org Custom Unix Programming | Linux: The choice of a GNU generation ---------------------------------------------------------------------- "All you need's an occasional kick in the philosophy." Frank Herbert ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 13:56 ` James Bourne @ 2003-04-14 14:22 ` Jörn Engel 0 siblings, 0 replies; 20+ messages in thread From: Jörn Engel @ 2003-04-14 14:22 UTC (permalink / raw) To: James Bourne; +Cc: linux-kernel, Marcelo Tosatti On Mon, 14 April 2003 07:56:45 -0600, James Bourne wrote: > On Mon, 14 Apr 2003, Jörn Engel wrote: > > On Mon, 14 April 2003 07:34:54 -0600, James Bourne wrote: > > > > > > This patch has also been added to the update patch available at > > > http://www.hardrock.org/kernel/current-updates/linux-2.4.20-updates.patch > > > > > > This patch includes the ptrace patch, tg3 patch, and ext3 patches. It also > > > changes the EXTRAVERSION to -uv2. > > > > Privately, I have introduced a variable FIXLEVEL for this. The > > resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo > > is more suiting for a fixed stable kernel. > > > > Are you interested in this patch? > > Sure, if you have the patch already please send it along. I think this was > suggested once before as well. Must have lost it, but it was simple to recreate. :) The fixlevel must also include the leading dot, so it will fold into nothing for normal (non-fixed) kernels. Marcelo, would/should this be included in Mainline as well? Jörn -- Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. -- Doug MacIlroy --- linux-2.4.20/Makefile~FIXLEVEL 2002-11-29 00:53:16.000000000 +0100 +++ linux-2.4.20/Makefile 2003-04-14 16:14:18.000000000 +0200 @@ -1,9 +1,10 @@ VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 20 +FIXLEVEL = EXTRAVERSION = -KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) +KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(FIXLEVEL)$(EXTRAVERSION) ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/) KERNELPATH=kernel-$(shell echo $(KERNELRELEASE) | sed -e "s/-//g") ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 13:46 ` Jörn Engel 2003-04-14 13:56 ` James Bourne @ 2003-04-14 14:31 ` Martin Schlemmer 2003-04-14 14:47 ` Jörn Engel 1 sibling, 1 reply; 20+ messages in thread From: Martin Schlemmer @ 2003-04-14 14:31 UTC (permalink / raw) To: Jörn Engel Cc: James Bourne, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 2003-04-14 at 15:46, Jörn Engel wrote: > Privately, I have introduced a variable FIXLEVEL for this. The > resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo > is more suiting for a fixed stable kernel. > This is not a good idea ... especially if its a box that you compile a lot of software on. Reason is that everything expects it to be MAJ.MIN.MIC ... If you add now another version, then things start to break. A good example is mozilla ... -- Martin Schlemmer ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 14:31 ` Martin Schlemmer @ 2003-04-14 14:47 ` Jörn Engel 2003-04-14 17:09 ` James Bourne 2003-04-14 18:10 ` Martin Schlemmer 0 siblings, 2 replies; 20+ messages in thread From: Jörn Engel @ 2003-04-14 14:47 UTC (permalink / raw) To: Martin Schlemmer Cc: James Bourne, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 April 2003 16:31:08 +0200, Martin Schlemmer wrote: > On Mon, 2003-04-14 at 15:46, Jörn Engel wrote: > > > Privately, I have introduced a variable FIXLEVEL for this. The > > resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo > > is more suiting for a fixed stable kernel. > > This is not a good idea ... especially if its a box that you > compile a lot of software on. Reason is that everything expects > it to be MAJ.MIN.MIC ... If you add now another version, then > things start to break. A good example is mozilla ... That doesn't convince me (yet?). Why doesn't 2.4.20-pre5-ac3 break mozilla, but 2.4.20.1 does? If mozilla depends on this information, it should at least have a robust parser for it. Can you give me a little more details on this? Did anyone ever declare that userspace can expect kernel versions to fit this regex? \d+\.\d+\.\d+(-.+)? Jörn -- More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity. -- W. A. Wulf ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 14:47 ` Jörn Engel @ 2003-04-14 17:09 ` James Bourne 2003-04-14 17:21 ` Jörn Engel 2003-04-14 17:50 ` Russell King 2003-04-14 18:10 ` Martin Schlemmer 1 sibling, 2 replies; 20+ messages in thread From: James Bourne @ 2003-04-14 17:09 UTC (permalink / raw) To: Jörn Engel Cc: Martin Schlemmer, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 Apr 2003, Jörn Engel wrote: > On Mon, 14 April 2003 16:31:08 +0200, Martin Schlemmer wrote: > > On Mon, 2003-04-14 at 15:46, Jörn Engel wrote: > > > > > Privately, I have introduced a variable FIXLEVEL for this. The > > > resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo > > > is more suiting for a fixed stable kernel. > > > > This is not a good idea ... especially if its a box that you > > compile a lot of software on. Reason is that everything expects > > it to be MAJ.MIN.MIC ... If you add now another version, then > > things start to break. A good example is mozilla ... > > That doesn't convince me (yet?). Why doesn't 2.4.20-pre5-ac3 break > mozilla, but 2.4.20.1 does? If mozilla depends on this information, it > should at least have a robust parser for it. > > Can you give me a little more details on this? Did anyone ever declare > that userspace can expect kernel versions to fit this regex? > \d+\.\d+\.\d+(-.+)? Hi, If you only change the one line and add the new variable I'm afraid it won't work due to other things changing as well... At least the files Makefile Rules.make arch/ppc/boot/Makefile arch/arm/boot/Makefile scripts/patch-kernel scripts/mkspec scripts/Menuconfig will need to be looked at as these are ones which contain references to SUBVERSION... References to EXTRAVERSION also reside in these files. It would just be better to do the "right thing" IMHO. I will take a look at this and produce a patch for the same. Regards James Bourne > Jörn -- James Bourne | Email: jbourne@hardrock.org Unix Systems Administrator | WWW: http://www.hardrock.org Custom Unix Programming | Linux: The choice of a GNU generation ---------------------------------------------------------------------- "All you need's an occasional kick in the philosophy." Frank Herbert ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 17:09 ` James Bourne @ 2003-04-14 17:21 ` Jörn Engel 2003-04-14 18:16 ` James Bourne 2003-04-14 17:50 ` Russell King 1 sibling, 1 reply; 20+ messages in thread From: Jörn Engel @ 2003-04-14 17:21 UTC (permalink / raw) To: James Bourne Cc: Martin Schlemmer, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 April 2003 11:09:02 -0600, James Bourne wrote: > > If you only change the one line and add the new variable I'm afraid it won't > work due to other things changing as well... At least the files > Makefile > Rules.make > arch/ppc/boot/Makefile > arch/arm/boot/Makefile > scripts/patch-kernel > scripts/mkspec > scripts/Menuconfig > > will need to be looked at as these are ones which contain references to > SUBVERSION... References to EXTRAVERSION also reside in these files. It > would just be better to do the "right thing" IMHO. > > I will take a look at this and produce a patch for the same. Ok. But the patch I lost really didn't do anything else and works for me (TM). joern@Limerick:~$ uname -a Linux Limerick 2.4.20.1-je1 #3 Sun Apr 6 22:20:45 CEST 2003 i686 unknown unknown GNU/Linux joern@Limerick:~$ Jörn -- Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. -- Rob Pike ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 17:21 ` Jörn Engel @ 2003-04-14 18:16 ` James Bourne 0 siblings, 0 replies; 20+ messages in thread From: James Bourne @ 2003-04-14 18:16 UTC (permalink / raw) To: Jörn Engel Cc: Martin Schlemmer, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 Apr 2003, Jörn Engel wrote: > On Mon, 14 April 2003 11:09:02 -0600, James Bourne wrote: > > ... > > will need to be looked at as these are ones which contain references to > > SUBVERSION... References to EXTRAVERSION also reside in these files. It > > would just be better to do the "right thing" IMHO. > > > > I will take a look at this and produce a patch for the same. > > Ok. But the patch I lost really didn't do anything else and works for > me (TM). > > joern@Limerick:~$ uname -a > Linux Limerick 2.4.20.1-je1 #3 Sun Apr 6 22:20:45 CEST 2003 i686 unknown unknown GNU/Linux > joern@Limerick:~$ Hi, The problem comes in when you bump the FIXLEVEL for example, by one. At that point the LINUX_VERSION_CODE would not change even though you have a new kernel and modules compiled for the previous version may not load or may load and not work correctly (just one example). EXTRAVERSION on the other hand is not used for LINUX_VERSION_CODE calculation. Regards James Bourne > Jörn -- James Bourne | Email: jbourne@hardrock.org Unix Systems Administrator | WWW: http://www.hardrock.org Custom Unix Programming | Linux: The choice of a GNU generation ---------------------------------------------------------------------- "All you need's an occasional kick in the philosophy." Frank Herbert ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 17:09 ` James Bourne 2003-04-14 17:21 ` Jörn Engel @ 2003-04-14 17:50 ` Russell King 1 sibling, 0 replies; 20+ messages in thread From: Russell King @ 2003-04-14 17:50 UTC (permalink / raw) To: James Bourne Cc: Jörn Engel, Martin Schlemmer, Ken Brownfield, Marc-Christian Petersen, KML On Mon, Apr 14, 2003 at 11:09:02AM -0600, James Bourne wrote: > will need to be looked at as these are ones which contain references to > SUBVERSION... References to EXTRAVERSION also reside in these files. It > would just be better to do the "right thing" IMHO. Note that EXTRAVERSION is not numeric. A kernel version string can be like: 2.4.19-rmk7-pxa2 which definitely is not numeric. Anything which assumes it is would be broken. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 14:47 ` Jörn Engel 2003-04-14 17:09 ` James Bourne @ 2003-04-14 18:10 ` Martin Schlemmer 2003-04-14 18:58 ` Jörn Engel 1 sibling, 1 reply; 20+ messages in thread From: Martin Schlemmer @ 2003-04-14 18:10 UTC (permalink / raw) To: Jörn Engel Cc: James Bourne, Ken Brownfield, Marc-Christian Petersen, KML [-- Attachment #1: Type: text/plain, Size: 1739 bytes --] On Mon, 2003-04-14 at 16:47, Jörn Engel wrote: > On Mon, 14 April 2003 16:31:08 +0200, Martin Schlemmer wrote: > > On Mon, 2003-04-14 at 15:46, Jörn Engel wrote: > > > > > Privately, I have introduced a variable FIXLEVEL for this. The > > > resulting kernel version is 2.4.20.2 instead of 2.4.20-uv2, which imo > > > is more suiting for a fixed stable kernel. > > > > This is not a good idea ... especially if its a box that you > > compile a lot of software on. Reason is that everything expects > > it to be MAJ.MIN.MIC ... If you add now another version, then > > things start to break. A good example is mozilla ... > > That doesn't convince me (yet?). Why doesn't 2.4.20-pre5-ac3 break > mozilla, but 2.4.20.1 does? If mozilla depends on this information, it > should at least have a robust parser for it. > > Can you give me a little more details on this? Did anyone ever declare > that userspace can expect kernel versions to fit this regex? > \d+\.\d+\.\d+(-.+)? > From include/linux/version.h: --------------------------------------------------------------- #define UTS_RELEASE "2.5.67-bk2" #define LINUX_VERSION_CODE 132419 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) --------------------------------------------------------------- Your changes will definitely break things that do: #if ((LINUX_VERSION_CODE > KERNEL_VERSION(2.4.0)) && \ (LINUX_VERSION_CODE < KERNEL_VERSION(2.5.0))) Also, most docs explaining the version format, refer to major.minor.micro Anyhow, I did not say it was set in stone, I just said if you start getting breakage when compiling/configuring things, do not wonder why =) Regards, -- Martin Schlemmer [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 18:10 ` Martin Schlemmer @ 2003-04-14 18:58 ` Jörn Engel 2003-04-14 19:20 ` Valdis.Kletnieks ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Jörn Engel @ 2003-04-14 18:58 UTC (permalink / raw) To: Martin Schlemmer Cc: James Bourne, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 April 2003 20:10:25 +0200, Martin Schlemmer wrote: > > From include/linux/version.h: > > --------------------------------------------------------------- > #define UTS_RELEASE "2.5.67-bk2" > #define LINUX_VERSION_CODE 132419 > #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) > --------------------------------------------------------------- > > Your changes will definitely break things that do: > > #if ((LINUX_VERSION_CODE > KERNEL_VERSION(2.4.0)) && \ > (LINUX_VERSION_CODE < KERNEL_VERSION(2.5.0))) > > Also, most docs explaining the version format, refer to > > major.minor.micro > > Anyhow, I did not say it was set in stone, I just said if you > start getting breakage when compiling/configuring things, do > not wonder why =) James Bourne: > The problem comes in when you bump the FIXLEVEL for example, by one. At > that point the LINUX_VERSION_CODE would not change even though you have a > new kernel and modules compiled for the previous version may not load or > may load and not work correctly (just one example). > > EXTRAVERSION on the other hand is not used for LINUX_VERSION_CODE > calculation. So basically, neither the existing EXTRAVERSION nor my new FIXLEVEL are checked. Any code could potentially break with -ac1 to -ac2 or with .1 to .2. Did anyone experience such problems with -ac already? There are far more changes in -ac than there are in your patch. Driver compilation should not be an issue. Change the Makefile and version.h should be changed as well, so any code depending on version.h will be rebuild, whether necessary or not. Module load sounds unrealistic for .[123...], as you shouldn't change any interfaces with fixes. But it might be a real problem for -ac. Jörn PS: Or for -aa, -dj, -mm or whatever. It's just an example. -- Do not stop an army on its way home. -- Sun Tzu ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 18:58 ` Jörn Engel @ 2003-04-14 19:20 ` Valdis.Kletnieks 2003-04-14 21:19 ` James Bourne 2003-04-15 6:00 ` Martin Schlemmer 2 siblings, 0 replies; 20+ messages in thread From: Valdis.Kletnieks @ 2003-04-14 19:20 UTC (permalink / raw) To: Jörn Engel; +Cc: KML [-- Attachment #1: Type: text/plain, Size: 848 bytes --] On Mon, 14 Apr 2003 20:58:06 +0200, =?iso-8859-1?Q?J=F6rn?= Engel said: > Module load sounds unrealistic for .[123...], as you shouldn't change > any interfaces with fixes. But it might be a real problem for -ac. I'm reading this, and looking at a patch from Russell King that entirely nukes several functions, and adds several new ones: -static int setup_socket(socket_info_t *); static void shutdown_socket(socket_info_t *); -static void reset_socket(socket_info_t *); -static void unreset_socket(socket_info_t *); static void parse_events(void *info, u_int events); +static void sm_init(socket_info_t *s); +static void sm_exit(socket_info_t *s); And yes, that's in something that could be a module (pcmcia/cs.c). (Yes Russell, I'll test it when I get home - the offending card is there and I'm here at the moment.. ;) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 18:58 ` Jörn Engel 2003-04-14 19:20 ` Valdis.Kletnieks @ 2003-04-14 21:19 ` James Bourne 2003-04-14 21:41 ` Jörn Engel 2003-04-15 6:10 ` Martin Schlemmer 2003-04-15 6:00 ` Martin Schlemmer 2 siblings, 2 replies; 20+ messages in thread From: James Bourne @ 2003-04-14 21:19 UTC (permalink / raw) To: Jörn Engel Cc: Martin Schlemmer, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 Apr 2003, Jörn Engel wrote: > So basically, neither the existing EXTRAVERSION nor my new FIXLEVEL > are checked. Any code could potentially break with -ac1 to -ac2 or > with .1 to .2. > > Did anyone experience such problems with -ac already? There are far > more changes in -ac than there are in your patch. Which brings the point as to why use a new variable unless you are going to actually modify LINUX_VERSION_CODE with it. It actually makes more sense to just use EXTRAVERSION for this then. Now, using EXTRAVERSION = .2 wouldn't be unrealistic... Regards James Bourne > > Driver compilation should not be an issue. Change the Makefile and > version.h should be changed as well, so any code depending on > version.h will be rebuild, whether necessary or not. > > Module load sounds unrealistic for .[123...], as you shouldn't change > any interfaces with fixes. But it might be a real problem for -ac. > > Jörn > > PS: Or for -aa, -dj, -mm or whatever. It's just an example. > > -- James Bourne | Email: jbourne@hardrock.org Unix Systems Administrator | WWW: http://www.hardrock.org Custom Unix Programming | Linux: The choice of a GNU generation ---------------------------------------------------------------------- "All you need's an occasional kick in the philosophy." Frank Herbert ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 21:19 ` James Bourne @ 2003-04-14 21:41 ` Jörn Engel 2003-04-15 6:10 ` Martin Schlemmer 1 sibling, 0 replies; 20+ messages in thread From: Jörn Engel @ 2003-04-14 21:41 UTC (permalink / raw) To: James Bourne Cc: Martin Schlemmer, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 14 April 2003 15:19:27 -0600, James Bourne wrote: > On Mon, 14 Apr 2003, Jörn Engel wrote: > > > So basically, neither the existing EXTRAVERSION nor my new FIXLEVEL > > are checked. Any code could potentially break with -ac1 to -ac2 or > > with .1 to .2. > > > > Did anyone experience such problems with -ac already? There are far > > more changes in -ac than there are in your patch. > > Which brings the point as to why use a new variable unless you are going to > actually modify LINUX_VERSION_CODE with it. It actually makes more sense to > just use EXTRAVERSION for this then. > > Now, using EXTRAVERSION = .2 wouldn't be unrealistic... Good point. My two (weak) arguments for the new variable are: - A fixes-only tree is imo different from any other patchset and should be marked as such. 2.4.20.2 sounds more official than 2.4.20-jb2. Whether this should be underscored for the developers as well - not sure. - It makes things like 2.4.20.1-je1 easier. But then again, someone will come up with 2.4.21-pre7-ac1-je2-something_else5-even_more. Sound a little too weak for the extra variable. Could have been a sign that I lost the patch. Jörn -- Anything that can go wrong, will. -- Finagle's Law ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 21:19 ` James Bourne 2003-04-14 21:41 ` Jörn Engel @ 2003-04-15 6:10 ` Martin Schlemmer 1 sibling, 0 replies; 20+ messages in thread From: Martin Schlemmer @ 2003-04-15 6:10 UTC (permalink / raw) To: James Bourne Cc: Jörn Engel, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 2003-04-14 at 23:19, James Bourne wrote: > On Mon, 14 Apr 2003, Jörn Engel wrote: > > > So basically, neither the existing EXTRAVERSION nor my new FIXLEVEL > > are checked. Any code could potentially break with -ac1 to -ac2 or > > with .1 to .2. > > > > Did anyone experience such problems with -ac already? There are far > > more changes in -ac than there are in your patch. > > Which brings the point as to why use a new variable unless you are going to > actually modify LINUX_VERSION_CODE with it. It actually makes more sense to > just use EXTRAVERSION for this then. > > Now, using EXTRAVERSION = .2 wouldn't be unrealistic... > True, but then, most things expect a version with two '.' s. And adding the extra '.2' breaks how they calculate the version. Mozilla for example, strip off all non numbers and '.' s, and then just cut the last '.' and number. What ever is left, is used to check what makefile should be used in the NSS stuff ... Meaning, with a normal version, it would be: Makefile-2.4 With Jörn's, it would try to use: Makefile-2.4.20 which do not exits ... Yes, mozilla is broken ;) I never said you cannot set EXTRAVERSION to '.2'. All I said, was that its going to break stuff, as many things expect, and only work with a two '.' version .... Regards, -- Martin Schlemmer ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Oops: ptrace fix buggy 2003-04-14 18:58 ` Jörn Engel 2003-04-14 19:20 ` Valdis.Kletnieks 2003-04-14 21:19 ` James Bourne @ 2003-04-15 6:00 ` Martin Schlemmer 2 siblings, 0 replies; 20+ messages in thread From: Martin Schlemmer @ 2003-04-15 6:00 UTC (permalink / raw) To: Jörn Engel Cc: James Bourne, Ken Brownfield, Marc-Christian Petersen, KML On Mon, 2003-04-14 at 20:58, Jörn Engel wrote: > So basically, neither the existing EXTRAVERSION nor my new FIXLEVEL > are checked. Any code could potentially break with -ac1 to -ac2 or > with .1 to .2. > > Did anyone experience such problems with -ac already? There are far > more changes in -ac than there are in your patch. > No, -ac[12] do not break. Its only when you have something like 2.4.20.1 (ie. three '.' s). -- Martin Schlemmer ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-04-15 6:03 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-04-07 12:22 Oops: ptrace fix buggy Michael Lampe 2003-04-12 7:13 ` Ken Brownfield 2003-04-12 9:54 ` Marc-Christian Petersen 2003-04-14 13:34 ` James Bourne 2003-04-14 13:46 ` Jörn Engel 2003-04-14 13:56 ` James Bourne 2003-04-14 14:22 ` Jörn Engel 2003-04-14 14:31 ` Martin Schlemmer 2003-04-14 14:47 ` Jörn Engel 2003-04-14 17:09 ` James Bourne 2003-04-14 17:21 ` Jörn Engel 2003-04-14 18:16 ` James Bourne 2003-04-14 17:50 ` Russell King 2003-04-14 18:10 ` Martin Schlemmer 2003-04-14 18:58 ` Jörn Engel 2003-04-14 19:20 ` Valdis.Kletnieks 2003-04-14 21:19 ` James Bourne 2003-04-14 21:41 ` Jörn Engel 2003-04-15 6:10 ` Martin Schlemmer 2003-04-15 6:00 ` Martin Schlemmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).