Oops: ptrace fix buggy

Oops: ptrace fix buggy

[Michael Lampe]

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

Re: Oops: ptrace fix buggy

[Ken Brownfield]

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/

Re: Oops: ptrace fix buggy

[Marc-Christian Petersen]

[-- 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

Re: Oops: ptrace fix buggy

[James Bourne]

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  

Re: Oops: ptrace fix buggy

[Jörn Engel]

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

Re: Oops: ptrace fix buggy

[James Bourne]

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  

Re: Oops: ptrace fix buggy

[Jörn Engel]

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")

Re: Oops: ptrace fix buggy

[Martin Schlemmer]

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

Re: Oops: ptrace fix buggy

[Jörn Engel]

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 

Re: Oops: ptrace fix buggy

[James Bourne]

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  

Re: Oops: ptrace fix buggy

[Jörn Engel]

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

Re: Oops: ptrace fix buggy

[Russell King]

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

Re: Oops: ptrace fix buggy

[Martin Schlemmer]

[-- 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 --]

Re: Oops: ptrace fix buggy

[James Bourne]

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  

Re: Oops: ptrace fix buggy

[Jörn Engel]

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

Re: Oops: ptrace fix buggy

[Valdis.Kletnieks]

[-- 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 --]

Re: Oops: ptrace fix buggy

[James Bourne]

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  

Re: Oops: ptrace fix buggy

[Jörn Engel]

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

Re: Oops: ptrace fix buggy

[Martin Schlemmer]

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

Re: Oops: ptrace fix buggy

[Martin Schlemmer]

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