Kernel OOPS:Badness in map_area_pte at mm/vmalloc.c:126 - Why should it misbehave? Linux 2.6.11

[Ashish Gupta]

Hi,

On configuring an ARM based gateway with a large number of iptables
rules, in the kernel, memory allocation (vmalloc) in the kernel half
of IPTABLES issues the following warning

Badness in map_area_pte at mm/vmalloc.c:126
Badness in map_area_pte at mm/vmalloc.c:126
Badness in map_area_pte at mm/vmalloc.c:126
Badness in map_area_pte at mm/vmalloc.c:126

Seemingly since 4 pages are requested for allocation. I retraced this
back in the kernel to iptables in the function do_replace in
ip_tables.c. This causes corruption of the filter table data structure
which cause a subsequent Kernel OOPS on trying to handle packets via
the tables.

The question is, under what conditions will a page table entry be
present in the first level page directory table, if the pages it
refers to its has just been freshly allocated in vmalloc?

Suprisingly, if, after bootup I wait for some time, say about 30
seconds and start creating the rules, this warning does not occur, and
neither does the crash !!. The start and end for VMALLOC are at
0xc280 and 0xd000 where as the memory address allocated by
vmalloc is 0xc3811000, which is well within the range. Considering is
a 4K hole is left between subsequent vmalloc areas, an overlap seems
quite unlikely.

The crash was traced, back to the translation fault generated on
accessing memory on the same data structure for which the errors
appeared above. The  kernel in question is 2.6.11.

Although not required for the question - The crash dump is given
below. The code has been isolated to ipt_do_table in ip_tables.c. The
code crashes on trying to access the hook_entry for the iptables
filter table for Local out hook.

The target on which I am testing does not have any debug facility (due
to memory constraints in the system). But I have isolated the reason
for the crash.
Misc. Details on the Ooops is:-
1) Isolation of code causing the crash - As below
2) Hardware : ARM based running linux 2.6.11 with 32 MB of RAM
4) Crash Dump : - As below.

Isolation of code causing the crash:-
___
The target on which it is running does not have any other debug
mechanism. Hence I am also sending the dump of the faulty instruction
in question.
c01355a4 :
c01355a4:   e1a0c00dmov ip, sp
c01355a8:   e92ddff0stmdb   sp!, {r4, r5, r6, r7, r8, r9,
sl, fp, ip,
lr, pc}
c01355ac:   e24cb004sub fp, ip, #4  ; 0x4
c01355b0:   e24dd02csub sp, sp, #44 ; 0x2c
c01355b4:   e3a06000mov r6, #0  ; 0x0
c01355b8:   e1a08000mov r8, r0
c01355bc:   e50b1044str r1, [fp, #-68]
c01355c0:   e50b2048str r2, [fp, #-72]
c01355c4:   e50b304cstr r3, [fp, #-76]
c01355c8:   e50b602cstr r6, [fp, #-44]
c01355cc:   e59b5004ldr r5, [fp, #4]
c01355d0:   e5903000ldr r3, [r0]
c01355d4:   e1a02001mov r2, r1
c01355d8:   e59f03b4ldr r0, [pc, #948]  ; c0135994
<.text+0x10c994>
c01355dc:   e5931018ldr r1, [r3, #24]
c01355e0:   ebfbfbb7bl  c00344c4 
c01355e4:   e598ldr r0, [r8]
c01355e8:   ebfffe21bl  c0134e74 
c01355ec:   e51b004cldr r0, [fp, #-76]
c01355f0:   e59f33a0ldr r3, [pc, #928]  ; c0135998
<.text+0x10c998>
c01355f4:   e156cmp r0, r6
c01355f8:   01a3moveq   r0, r3
c01355fc:   e5982000ldr r2, [r8]
c0135600:   e50b0030str r0, [fp, #-48]
c0135604:   e51b0048ldr r0, [fp, #-72]
c0135608:   e156cmp r0, r6
c013560c:   01a3moveq   r0, r3
c0135610:   e50b0034str r0, [fp, #-52]
c0135614:   e5922028ldr r2, [r2, #40]
c0135618:   e50b203cstr r2, [fp, #-60]
c013561c:   e59f0378ldr r0, [pc, #888]  ; c013599c
<.text+0x10c99c>
c0135620:   ebfbfba7bl  c00344c4 
c0135624:   e59f0374ldr r0, [pc, #884]  ; c01359a0
<.text+0x10c9a0>
c0135628:   e51b1044ldr r1, [fp, #-68]
c013562c:   ebfbfba4bl  c00344c4 
c0135630:   e59f036cldr r0, [pc, #876]  ; c01359a4
<.text+0x10c9a4>
c0135634:   e1a01005mov r1, r5
c0135638:   ebfbfba1bl  c00344c4 
c013563c:   e59f0364ldr r0, [pc, #868]  ; c01359a8
<.text+0x10c9a8>
c0135640:   e595102cldr r1, [r5, #44]
c0135644:   ebfbfb9ebl  c00344c4 
c0135648:   e595102cldr r1, [r5, #44]
c013564c:   e59f0358ldr r0, [pc, #856]  ; c01359ac
<.text+0x10c9ac>
c0135650:   e2811040add r1, r1, #64 ; 0x40
c0135654:   ebfbfb9abl  c00344c4 
c0135658:   e51b2044ldr r2, [fp, #-68]
c013565c:   e595302cldr r3, [r5, #44]

Kernel OOPS:Badness in map_area_pte at mm/vmalloc.c:126 - Why should it misbehave? Linux 2.6.11

[Ashish Gupta]

Hi,

On configuring an ARM based gateway with a large number of iptables
rules, in the kernel, memory allocation (vmalloc) in the kernel half
of IPTABLES issues the following warning

Badness in map_area_pte at mm/vmalloc.c:126
Badness in map_area_pte at mm/vmalloc.c:126
Badness in map_area_pte at mm/vmalloc.c:126
Badness in map_area_pte at mm/vmalloc.c:126

Seemingly since 4 pages are requested for allocation. I retraced this
back in the kernel to iptables in the function do_replace in
ip_tables.c. This causes corruption of the filter table data structure
which cause a subsequent Kernel OOPS on trying to handle packets via
the tables.

The question is, under what conditions will a page table entry be
present in the first level page directory table, if the pages it
refers to its has just been freshly allocated in vmalloc?

Suprisingly, if, after bootup I wait for some time, say about 30
seconds and start creating the rules, this warning does not occur, and
neither does the crash !!. The start and end for VMALLOC are at
0xc280 and 0xd000 where as the memory address allocated by
vmalloc is 0xc3811000, which is well within the range. Considering is
a 4K hole is left between subsequent vmalloc areas, an overlap seems
quite unlikely.

The crash was traced, back to the translation fault generated on
accessing memory on the same data structure for which the errors
appeared above. The  kernel in question is 2.6.11.

Although not required for the question - The crash dump is given
below. The code has been isolated to ipt_do_table in ip_tables.c. The
code crashes on trying to access the hook_entry for the iptables
filter table for Local out hook.

The target on which I am testing does not have any debug facility (due
to memory constraints in the system). But I have isolated the reason
for the crash.
Misc. Details on the Ooops is:-
1) Isolation of code causing the crash - As below
2) Hardware : ARM based running linux 2.6.11 with 32 MB of RAM
4) Crash Dump : - As below.

Isolation of code causing the crash:-
___
The target on which it is running does not have any other debug
mechanism. Hence I am also sending the dump of the faulty instruction
in question.
c01355a4 ipt_do_table:
c01355a4:   e1a0c00dmov ip, sp
c01355a8:   e92ddff0stmdb   sp!, {r4, r5, r6, r7, r8, r9,
sl, fp, ip,
lr, pc}
c01355ac:   e24cb004sub fp, ip, #4  ; 0x4
c01355b0:   e24dd02csub sp, sp, #44 ; 0x2c
c01355b4:   e3a06000mov r6, #0  ; 0x0
c01355b8:   e1a08000mov r8, r0
c01355bc:   e50b1044str r1, [fp, #-68]
c01355c0:   e50b2048str r2, [fp, #-72]
c01355c4:   e50b304cstr r3, [fp, #-76]
c01355c8:   e50b602cstr r6, [fp, #-44]
c01355cc:   e59b5004ldr r5, [fp, #4]
c01355d0:   e5903000ldr r3, [r0]
c01355d4:   e1a02001mov r2, r1
c01355d8:   e59f03b4ldr r0, [pc, #948]  ; c0135994
.text+0x10c994
c01355dc:   e5931018ldr r1, [r3, #24]
c01355e0:   ebfbfbb7bl  c00344c4 printk
c01355e4:   e598ldr r0, [r8]
c01355e8:   ebfffe21bl  c0134e74 dump_tcpudp_packet
c01355ec:   e51b004cldr r0, [fp, #-76]
c01355f0:   e59f33a0ldr r3, [pc, #928]  ; c0135998
.text+0x10c998
c01355f4:   e156cmp r0, r6
c01355f8:   01a3moveq   r0, r3
c01355fc:   e5982000ldr r2, [r8]
c0135600:   e50b0030str r0, [fp, #-48]
c0135604:   e51b0048ldr r0, [fp, #-72]
c0135608:   e156cmp r0, r6
c013560c:   01a3moveq   r0, r3
c0135610:   e50b0034str r0, [fp, #-52]
c0135614:   e5922028ldr r2, [r2, #40]
c0135618:   e50b203cstr r2, [fp, #-60]
c013561c:   e59f0378ldr r0, [pc, #888]  ; c013599c
.text+0x10c99c
c0135620:   ebfbfba7bl  c00344c4 printk
c0135624:   e59f0374ldr r0, [pc, #884]  ; c01359a0
.text+0x10c9a0
c0135628:   e51b1044ldr r1, [fp, #-68]
c013562c:   ebfbfba4bl  c00344c4 printk
c0135630:   e59f036cldr r0, [pc, #876]  ; c01359a4
.text+0x10c9a4
c0135634:   e1a01005mov r1, r5
c0135638:   ebfbfba1bl  c00344c4 printk
c013563c:   e59f0364ldr r0, [pc, #868]  ; c01359a8
.text+0x10c9a8
c0135640:   e595102cldr r1, [r5, #44]
c0135644:   ebfbfb9ebl  c00344c4 printk
c0135648:   e595102cldr r1, [r5, #44]
c013564c:   e59f0358ldr r0, [pc, #856]  ; c01359ac
.text+0x10c9ac
c0135650:   e2811040add r1, r1, #64 ; 0x40
c0135654:   ebfbfb9abl  c00344c4 printk
c0135658:   e51b2044ldr r2, [fp, #-68]
c013565c:   e595302cldr r3, [r5

Re: lirc and Linux 2.6.11

[Greg KH]

On Thu, Apr 21, 2005 at 03:26:37PM -0700, Shaun Jackman wrote:
> I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
> 2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
> the new kernel. This did not work. I then tried compiling the lirc
> 0.7.1 modules for the new kernel. This didn't work either. The error
> message lircd gives is...
> 
> Apr 21 14:57:29 quince lircd 0.7.1: lircd(hauppauge) ready
> Apr 21 14:57:52 quince lircd 0.7.1: accepted new client on /dev/lircd
> Apr 21 14:57:52 quince lircd 0.7.1: could not open /dev/lirc0
> Apr 21 14:57:52 quince lircd 0.7.1: default_init(): No such device
> Apr 21 14:57:52 quince lircd 0.7.1: caught signal
> 
> I've also asked the lirc mailing list this question, but has anyone
> else run into this trouble with lirc and Linux 2.6.11?

As the lirc developers have no intention of ever merging with the
mainline kernel code, you will have to ask all lirc questions to them,
we can not help you out at all, sorry.

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/

lirc and Linux 2.6.11

[Shaun Jackman]

I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
the new kernel. This did not work. I then tried compiling the lirc
0.7.1 modules for the new kernel. This didn't work either. The error
message lircd gives is...

Apr 21 14:57:29 quince lircd 0.7.1: lircd(hauppauge) ready
Apr 21 14:57:52 quince lircd 0.7.1: accepted new client on /dev/lircd
Apr 21 14:57:52 quince lircd 0.7.1: could not open /dev/lirc0
Apr 21 14:57:52 quince lircd 0.7.1: default_init(): No such device
Apr 21 14:57:52 quince lircd 0.7.1: caught signal

I've also asked the lirc mailing list this question, but has anyone
else run into this trouble with lirc and Linux 2.6.11?

Please cc me in your reply. Thanks,
Shaun
-
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/

lirc and Linux 2.6.11

[Shaun Jackman]

I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
the new kernel. This did not work. I then tried compiling the lirc
0.7.1 modules for the new kernel. This didn't work either. The error
message lircd gives is...

Apr 21 14:57:29 quince lircd 0.7.1: lircd(hauppauge) ready
Apr 21 14:57:52 quince lircd 0.7.1: accepted new client on /dev/lircd
Apr 21 14:57:52 quince lircd 0.7.1: could not open /dev/lirc0
Apr 21 14:57:52 quince lircd 0.7.1: default_init(): No such device
Apr 21 14:57:52 quince lircd 0.7.1: caught signal

I've also asked the lirc mailing list this question, but has anyone
else run into this trouble with lirc and Linux 2.6.11?

Please cc me in your reply. Thanks,
Shaun
-
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: lirc and Linux 2.6.11

[Greg KH]

On Thu, Apr 21, 2005 at 03:26:37PM -0700, Shaun Jackman wrote:
 I was using lirc 0.7.0 with Linux 2.6.8.1. Upon upgrading to Linux
 2.6.11, I recompiled the lirc 0.7.0 hauppauge (lirc_i2c) modules for
 the new kernel. This did not work. I then tried compiling the lirc
 0.7.1 modules for the new kernel. This didn't work either. The error
 message lircd gives is...
 
 Apr 21 14:57:29 quince lircd 0.7.1: lircd(hauppauge) ready
 Apr 21 14:57:52 quince lircd 0.7.1: accepted new client on /dev/lircd
 Apr 21 14:57:52 quince lircd 0.7.1: could not open /dev/lirc0
 Apr 21 14:57:52 quince lircd 0.7.1: default_init(): No such device
 Apr 21 14:57:52 quince lircd 0.7.1: caught signal
 
 I've also asked the lirc mailing list this question, but has anyone
 else run into this trouble with lirc and Linux 2.6.11?

As the lirc developers have no intention of ever merging with the
mainline kernel code, you will have to ask all lirc questions to them,
we can not help you out at all, sorry.

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.11 can't disable CAD

[Richard B. Johnson]

It wasn't the kernel.
Many thanks to those who helped me track down this problem.
It seems that the 'C' runtime library was trapping the call
to reboot() which probably should have been _reboot() in
earlier code to prevent this. Anyway, the fix is to call
the kernel directly so it doesn't get blamed for something
it didn't do.
Simple external procedure is attached if anybody else is
interested. It ends up being only 0x30 bytes in length.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#
#  Copyright(c)  2005  Analogic Corporation
#
#  This program may be distributed under the GNU Public License
#  version 2, as published by the Free Software Foundation, Inc.,
#  59 Temple Place, Suite 330 Boston, MA, 02111.
#
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#
#   Disable Ctl-Alt-Del
#   Test environment 'C' runtime libraries are screwing with
#   this so I have to call the kernel directly. This is now
#   handled in assembly.
#
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

.extern __set_errno
.LREBOOT = 88
.LMAGIC1 = 0xfee1dead
.LMAGIC2 = 672274793
.LCADOFF = 0x

disable_shutdown:
pushl   %ebx# Save precious registers
pushl   %esi
movl$.LREBOOT, %eax # Reboot command
movl$.LMAGIC1, %ebx # First magic parameter
movl$.LMAGIC2, %ecx # Second magic parameter
movl$.LCADOFF, %edx # Command
xorl%esi, %esi  # Zero ignored pointer
int $0x80   # Make the call
popl%esi# Restore precious registers
popl%ebx
orl %eax,%eax   # Check return value
jns 1f  # It's okay
negl%eax# Make positive
pushl   %eax
call__set_errno # Set new errno
addl$0x04, %esp # Level stack
movl$-1, %eax
1:  ret

.size   disable_shutdown,.-disable_shutdown
.type   disable_shutdown,@function
.global disable_shutdown
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.end

Re: Linux-2.6.11 can't disable CAD

[Richard B. Johnson]

On Fri, 8 Apr 2005, Daniel Jacobowitz wrote:
On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will still execute the shutdown-order (INIT 0).
Actually, if CAD is enabled in the kernel, it will just reboot.
If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).
No, that's not how it ever worked. There are parameters that are
available in the reboot-system call that define the operation that
will occur when the 3-finger salute occurs.
Execute man 2 reboot.
Take your own advice.  From the man page:
  LINUX_REBOOT_CMD_CAD_ON
 (RB_ENABLE_CAD, 0x89abcdef).  CAD is enabled.  This means
 that the CAD keystroke will immediately cause the action
 associated with LINUX_REBOOT_CMD_RESTART.
  LINUX_REBOOT_CMD_CAD_OFF
 (RB_DISABLE_CAD, 0).  CAD is disabled. This means that the CAD
 keystroke will cause a SIGINT signal to be sent to init
 (process 1), whereupon this process may decide upon a
 proper action (maybe: kill all processes, sync, reboot).
--
Daniel Jacobowitz
CodeSourcery, LLC
The 'init' in use is not SYS-V init. Instead, it is the startup
program, mother-of-all-programs, of a complete embedded system
that has no shells, etc. It's just a system that's designed to
make images.
There are handlers in place for all signals, either to ignore
signals or to perform things like X-ON and X-OFF. This 'init'
will never shut down the system. It doesn't know how. It also
ignores any "harmful" signals and, in fact, will never exit
the main program. Again, it doesn't know how. It just forks off
some processes and then sleeps, occasionally waking to
get and throw away the exit-status of some child's
children.
Also, this has been working for many years. It is unknown
how many linux-versions this worked with since it was first
tested with 2.4.x circa 2000 to 2001.
It appears that the 'C' runtime library is now trapping
reboot() and turning it into a single-parameter function
call. It is possible that the correct 4-parameter reboot()
is not even making it to the kernel. I am investigating this.
I made another function called disable() that will directly
make a system-call, thereby bypassing the 'C' runtime library
altogether. I am working on this.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Daniel Jacobowitz]

On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
> On Thu, 7 Apr 2005, Jan Harkes wrote:
> 
> >On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
> >>In the not-too distant past, one could disable Ctl-Alt-DEL.
> >>Can't do it anymore.
> >...
> >>Observe that reboot() returns 0 and `strace` understands what
> >>parameters were passed. The result is that, if I hit Ctl-Alt-Del,
> >>`init` will still execute the shutdown-order (INIT 0).
> >
> >Actually, if CAD is enabled in the kernel, it will just reboot.
> >If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).
> >
> 
> No, that's not how it ever worked. There are parameters that are
> available in the reboot-system call that define the operation that
> will occur when the 3-finger salute occurs.
> 
> Execute man 2 reboot.

Take your own advice.  From the man page:

   LINUX_REBOOT_CMD_CAD_ON
  (RB_ENABLE_CAD, 0x89abcdef).  CAD is enabled.  This means
  that the CAD keystroke will immediately cause the action
  associated with LINUX_REBOOT_CMD_RESTART.

   LINUX_REBOOT_CMD_CAD_OFF
  (RB_DISABLE_CAD, 0).  CAD is disabled. This means that the CAD
  keystroke will cause a SIGINT signal to be sent to init
  (process 1), whereupon this process may decide upon a
  proper action (maybe: kill all processes, sync, reboot).

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
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.11 can't disable CAD

[Daniel Jacobowitz]

On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
 On Thu, 7 Apr 2005, Jan Harkes wrote:
 
 On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
 In the not-too distant past, one could disable Ctl-Alt-DEL.
 Can't do it anymore.
 ...
 Observe that reboot() returns 0 and `strace` understands what
 parameters were passed. The result is that, if I hit Ctl-Alt-Del,
 `init` will still execute the shutdown-order (INIT 0).
 
 Actually, if CAD is enabled in the kernel, it will just reboot.
 If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).
 
 
 No, that's not how it ever worked. There are parameters that are
 available in the reboot-system call that define the operation that
 will occur when the 3-finger salute occurs.
 
 Execute man 2 reboot.

Take your own advice.  From the man page:

   LINUX_REBOOT_CMD_CAD_ON
  (RB_ENABLE_CAD, 0x89abcdef).  CAD is enabled.  This means
  that the CAD keystroke will immediately cause the action
  associated with LINUX_REBOOT_CMD_RESTART.

   LINUX_REBOOT_CMD_CAD_OFF
  (RB_DISABLE_CAD, 0).  CAD is disabled. This means that the CAD
  keystroke will cause a SIGINT signal to be sent to init
  (process 1), whereupon this process may decide upon a
  proper action (maybe: kill all processes, sync, reboot).

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
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.11 can't disable CAD

[Richard B. Johnson]

On Fri, 8 Apr 2005, Daniel Jacobowitz wrote:
On Thu, Apr 07, 2005 at 04:50:32PM -0400, Richard B. Johnson wrote:
On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will still execute the shutdown-order (INIT 0).
Actually, if CAD is enabled in the kernel, it will just reboot.
If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).
No, that's not how it ever worked. There are parameters that are
available in the reboot-system call that define the operation that
will occur when the 3-finger salute occurs.
Execute man 2 reboot.
Take your own advice.  From the man page:
  LINUX_REBOOT_CMD_CAD_ON
 (RB_ENABLE_CAD, 0x89abcdef).  CAD is enabled.  This means
 that the CAD keystroke will immediately cause the action
 associated with LINUX_REBOOT_CMD_RESTART.
  LINUX_REBOOT_CMD_CAD_OFF
 (RB_DISABLE_CAD, 0).  CAD is disabled. This means that the CAD
 keystroke will cause a SIGINT signal to be sent to init
 (process 1), whereupon this process may decide upon a
 proper action (maybe: kill all processes, sync, reboot).
--
Daniel Jacobowitz
CodeSourcery, LLC
The 'init' in use is not SYS-V init. Instead, it is the startup
program, mother-of-all-programs, of a complete embedded system
that has no shells, etc. It's just a system that's designed to
make images.
There are handlers in place for all signals, either to ignore
signals or to perform things like X-ON and X-OFF. This 'init'
will never shut down the system. It doesn't know how. It also
ignores any harmful signals and, in fact, will never exit
the main program. Again, it doesn't know how. It just forks off
some processes and then sleeps, occasionally waking to
get and throw away the exit-status of some child's
children.
Also, this has been working for many years. It is unknown
how many linux-versions this worked with since it was first
tested with 2.4.x circa 2000 to 2001.
It appears that the 'C' runtime library is now trapping
reboot() and turning it into a single-parameter function
call. It is possible that the correct 4-parameter reboot()
is not even making it to the kernel. I am investigating this.
I made another function called disable() that will directly
make a system-call, thereby bypassing the 'C' runtime library
altogether. I am working on this.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Richard B. Johnson]

It wasn't the kernel.
Many thanks to those who helped me track down this problem.
It seems that the 'C' runtime library was trapping the call
to reboot() which probably should have been _reboot() in
earlier code to prevent this. Anyway, the fix is to call
the kernel directly so it doesn't get blamed for something
it didn't do.
Simple external procedure is attached if anybody else is
interested. It ends up being only 0x30 bytes in length.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#
#  Copyright(c)  2005  Analogic Corporation
#
#  This program may be distributed under the GNU Public License
#  version 2, as published by the Free Software Foundation, Inc.,
#  59 Temple Place, Suite 330 Boston, MA, 02111.
#
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
#
#   Disable Ctl-Alt-Del
#   Test environment 'C' runtime libraries are screwing with
#   this so I have to call the kernel directly. This is now
#   handled in assembly.
#
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

.extern __set_errno
.LREBOOT = 88
.LMAGIC1 = 0xfee1dead
.LMAGIC2 = 672274793
.LCADOFF = 0x

disable_shutdown:
pushl   %ebx# Save precious registers
pushl   %esi
movl$.LREBOOT, %eax # Reboot command
movl$.LMAGIC1, %ebx # First magic parameter
movl$.LMAGIC2, %ecx # Second magic parameter
movl$.LCADOFF, %edx # Command
xorl%esi, %esi  # Zero ignored pointer
int $0x80   # Make the call
popl%esi# Restore precious registers
popl%ebx
orl %eax,%eax   # Check return value
jns 1f  # It's okay
negl%eax# Make positive
pushl   %eax
call__set_errno # Set new errno
addl$0x04, %esp # Level stack
movl$-1, %eax
1:  ret

.size   disable_shutdown,.-disable_shutdown
.type   disable_shutdown,@function
.global disable_shutdown
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
.end

Re: Linux-2.6.11 can't disable CAD

[Richard B. Johnson]

On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will still execute the shutdown-order (INIT 0).
Actually, if CAD is enabled in the kernel, it will just reboot.
If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).
No, that's not how it ever worked. There are parameters that are
available in the reboot-system call that define the operation that
will occur when the 3-finger salute occurs.
Execute man 2 reboot.
So what you probably had in the not-too-distant past was a disabled CAD
in the kernel _and_ you had modified the following line in /etc/inittab,
The systems to which I refer do not, and never even had a file-system,
much-less any inittab. That's SYS-V init stuff for interactive access.
   # What to do when CTRL-ALT-DEL is pressed.
   ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
AFAIK this hasn't ever really changed.
Jan
The kernel's response (or the 'C' runtime-library interface) has
changed so that it is now possible for somebody at the keyboard
of a machine to destroy the machine's operation by executing
Ctl-Alt-Del. I don't know how long this potential catastrophe
has existed, but when the machine(s) were initially certified
there was no possible way for a user to kill the machine from
the keyboard.
It is possible that a 'C' runtime library was changed in the
tarket so it's not a kernel problem. I'm checking it out now.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Richard B. Johnson]

On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
| > On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
| >
| > |
| > | In the not-too distant past, one could disable Ctl-Alt-DEL.
| > | Can't do it anymore.
| >
| > What should disabling C_A_D do?
| >
| > | Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| > | [SNIPPED leading stuff...]
| > |
| > | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
| > | brk(0)  = 0x804a000
| > | brk(0x8053000)  = 0x8053000
| > | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF)
| > = 0
| > | pause( 
| > | _exit(0)= ?
| > | # exit
| > | Script done on Thu 07 Apr 2005 10:58:21 AM EDT
| >
|
| It's a program that executes the __NR_reboot syscall (88) after
| putting the documented values into the appropriate registers.
Yeah, I understood that much.  Just wondering if it was
available somewhere...
| > What program is that?  I'm just echoing 0 | 1 into
| > /proc/sys/kernel/ctrl-alt-del , is that equivalent?
| > or have you tried that?
| >
|
| Doesn't matter. Many embedded systems don't have /proc because
| they don't have any file-systems.
It matters if they are equivalent (and I don't have that
program above).
| > | Observe that reboot() returns 0 and `strace` understands what
| > | parameters were passed. The result is that, if I hit Ctl-Alt-Del,
| > | `init` will still execute the shutdown-order (INIT 0).
| >
| > echo 0 > /proc/sys/kernel/ctrl-alt-del
| >  is same as CAD_OFF
| > echo 1
| >  is same as CAD_ON
| >
| > I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
| > the same way for me.  If it's an issue with using a syscall
| > to change the setting, I'll be glad to look into that too.
| >
| > observed behaviors:
| > CAD enabled + C_A_D keys => call machine_reboot()
| >  to reboot quickly, no normal shutdown sequence;
| > CAD disabled + C_A_D keys => kill init, go thru normal
| >  clean shutdown sequence;
| > are these the expected behaviors?
|
| The expected behavior of the reported operation is for
| Ctl-Alt-Del to no longer do anything. If the system-call
| has been depreciated, then the call should return -1 and
| errno should be ENOSYS. In such a case, I would have
| to trap the key-sequence in some other way, not that
| I know how without modifying the kernel.
Have you looked at 'man 2 reboot'?  It seems to agree with
the observed behavior (above).
or where should I look to find documentation of the
expected behavior that you described?
man 2 reboot on my system documents the system call interface
through the C runtime library.
Bbuuu then tells how glib-C munged it into a one-parameter
'C' call.   Hmmm. Maybe it's screwing me.  I will check into
this.  I don't know why `strace` shows the correct stuff when
I am making the 4-parameter call. Maybe something is really
confused
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Jan Harkes]

On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
> In the not-too distant past, one could disable Ctl-Alt-DEL.
> Can't do it anymore.
...
> Observe that reboot() returns 0 and `strace` understands what
> parameters were passed. The result is that, if I hit Ctl-Alt-Del,
> `init` will still execute the shutdown-order (INIT 0).

Actually, if CAD is enabled in the kernel, it will just reboot.
If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).

So what you probably had in the not-too-distant past was a disabled CAD
in the kernel _and_ you had modified the following line in /etc/inittab,

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

AFAIK this hasn't ever really changed.

Jan

-
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.11 can't disable CAD

[Randy.Dunlap]

On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:

| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
| 
| > On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
| >
| > |
| > | In the not-too distant past, one could disable Ctl-Alt-DEL.
| > | Can't do it anymore.
| >
| > What should disabling C_A_D do?
| >
| > | Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| > | [SNIPPED leading stuff...]
| > |
| > | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
| > | brk(0)  = 0x804a000
| > | brk(0x8053000)  = 0x8053000
| > | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF)
| > = 0
| > | pause( 
| > | _exit(0)= ?
| > | # exit
| > | Script done on Thu 07 Apr 2005 10:58:21 AM EDT
| >
| 
| It's a program that executes the __NR_reboot syscall (88) after
| putting the documented values into the appropriate registers.

Yeah, I understood that much.  Just wondering if it was
available somewhere...

| > What program is that?  I'm just echoing 0 | 1 into
| > /proc/sys/kernel/ctrl-alt-del , is that equivalent?
| > or have you tried that?
| >
| 
| Doesn't matter. Many embedded systems don't have /proc because
| they don't have any file-systems.

It matters if they are equivalent (and I don't have that
program above).

| > | Observe that reboot() returns 0 and `strace` understands what
| > | parameters were passed. The result is that, if I hit Ctl-Alt-Del,
| > | `init` will still execute the shutdown-order (INIT 0).
| >
| > echo 0 > /proc/sys/kernel/ctrl-alt-del
| >  is same as CAD_OFF
| > echo 1
| >  is same as CAD_ON
| >
| > I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
| > the same way for me.  If it's an issue with using a syscall
| > to change the setting, I'll be glad to look into that too.
| >
| > observed behaviors:
| > CAD enabled + C_A_D keys => call machine_reboot()
| >  to reboot quickly, no normal shutdown sequence;
| > CAD disabled + C_A_D keys => kill init, go thru normal
| >  clean shutdown sequence;
| > are these the expected behaviors?
| 
| The expected behavior of the reported operation is for
| Ctl-Alt-Del to no longer do anything. If the system-call
| has been depreciated, then the call should return -1 and
| errno should be ENOSYS. In such a case, I would have
| to trap the key-sequence in some other way, not that
| I know how without modifying the kernel.

Have you looked at 'man 2 reboot'?  It seems to agree with
the observed behavior (above).
or where should I look to find documentation of the
expected behavior that you described?

---
~Randy
-
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.11 can't disable CAD

[Richard B. Johnson]

On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.
What should disabling C_A_D do?
| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading stuff...]
|
| mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
| brk(0)  = 0x804a000
| brk(0x8053000)  = 0x8053000
| reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF)
= 0
| pause( 
| _exit(0)= ?
| # exit
| Script done on Thu 07 Apr 2005 10:58:21 AM EDT
It's a program that executes the __NR_reboot syscall (88) after
putting the documented values into the appropriate registers.
What program is that?  I'm just echoing 0 | 1 into
/proc/sys/kernel/ctrl-alt-del , is that equivalent?
or have you tried that?
Doesn't matter. Many embedded systems don't have /proc because
they don't have any file-systems.
| Observe that reboot() returns 0 and `strace` understands what
| parameters were passed. The result is that, if I hit Ctl-Alt-Del,
| `init` will still execute the shutdown-order (INIT 0).
echo 0 > /proc/sys/kernel/ctrl-alt-del
 is same as CAD_OFF
echo 1
 is same as CAD_ON
I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
the same way for me.  If it's an issue with using a syscall
to change the setting, I'll be glad to look into that too.
observed behaviors:
CAD enabled + C_A_D keys => call machine_reboot()
 to reboot quickly, no normal shutdown sequence;
CAD disabled + C_A_D keys => kill init, go thru normal
 clean shutdown sequence;
are these the expected behaviors?
The expected behavior of the reported operation is for
Ctl-Alt-Del to no longer do anything. If the system-call
has been depreciated, then the call should return -1 and
errno should be ENOSYS. In such a case, I would have
to trap the key-sequence in some other way, not that
I know how without modifying the kernel.
| A side note, while researching this problem, I think I found
| that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe
| the problem is that he no longer observes his birthday?
---
~Randy
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Randy.Dunlap]

On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:

| 
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.

What should disabling C_A_D do?

| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading stuff...]
| 
| mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
| brk(0)  = 0x804a000
| brk(0x8053000)  = 0x8053000
| reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0
| pause( 
| _exit(0)= ?
| # exit
| Script done on Thu 07 Apr 2005 10:58:21 AM EDT

What program is that?  I'm just echoing 0 | 1 into
/proc/sys/kernel/ctrl-alt-del , is that equivalent?
or have you tried that?

| Observe that reboot() returns 0 and `strace` understands what
| parameters were passed. The result is that, if I hit Ctl-Alt-Del,
| `init` will still execute the shutdown-order (INIT 0).

echo 0 > /proc/sys/kernel/ctrl-alt-del
  is same as CAD_OFF
echo 1
  is same as CAD_ON

I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
the same way for me.  If it's an issue with using a syscall
to change the setting, I'll be glad to look into that too.

observed behaviors:
CAD enabled + C_A_D keys => call machine_reboot()
  to reboot quickly, no normal shutdown sequence;
CAD disabled + C_A_D keys => kill init, go thru normal
  clean shutdown sequence;
are these the expected behaviors?

| A side note, while researching this problem, I think I found
| that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe
| the problem is that he no longer observes his birthday?

---
~Randy
-
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/

Linux-2.6.11 can't disable CAD

[Richard B. Johnson]

In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
Script started on Thu 07 Apr 2005 10:58:11 AM EDT
[SNIPPED leading stuff...]
mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
brk(0)  = 0x804a000
brk(0x8053000)  = 0x8053000
reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0
pause( 
_exit(0)= ?
# exit
Script done on Thu 07 Apr 2005 10:58:21 AM EDT
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will still execute the shutdown-order (INIT 0).
A side note, while researching this problem, I think I found
that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe
the problem is that he no longer observes his birthday?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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/

Linux-2.6.11 can't disable CAD

[Richard B. Johnson]

In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
Script started on Thu 07 Apr 2005 10:58:11 AM EDT
[SNIPPED leading stuff...]
mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
brk(0)  = 0x804a000
brk(0x8053000)  = 0x8053000
reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0
pause( unfinished ...
_exit(0)= ?
# exit
Script done on Thu 07 Apr 2005 10:58:21 AM EDT
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will still execute the shutdown-order (INIT 0).
A side note, while researching this problem, I think I found
that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe
the problem is that he no longer observes his birthday?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Randy.Dunlap]

On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:

| 
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.

What should disabling C_A_D do?

| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading stuff...]
| 
| mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
| brk(0)  = 0x804a000
| brk(0x8053000)  = 0x8053000
| reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF) = 0
| pause( unfinished ...
| _exit(0)= ?
| # exit
| Script done on Thu 07 Apr 2005 10:58:21 AM EDT

What program is that?  I'm just echoing 0 | 1 into
/proc/sys/kernel/ctrl-alt-del , is that equivalent?
or have you tried that?

| Observe that reboot() returns 0 and `strace` understands what
| parameters were passed. The result is that, if I hit Ctl-Alt-Del,
| `init` will still execute the shutdown-order (INIT 0).

echo 0  /proc/sys/kernel/ctrl-alt-del
  is same as CAD_OFF
echo 1
  is same as CAD_ON

I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
the same way for me.  If it's an issue with using a syscall
to change the setting, I'll be glad to look into that too.

observed behaviors:
CAD enabled + C_A_D keys = call machine_reboot()
  to reboot quickly, no normal shutdown sequence;
CAD disabled + C_A_D keys = kill init, go thru normal
  clean shutdown sequence;
are these the expected behaviors?

| A side note, while researching this problem, I think I found
| that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe
| the problem is that he no longer observes his birthday?

---
~Randy
-
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.11 can't disable CAD

[Richard B. Johnson]

On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
|
| In the not-too distant past, one could disable Ctl-Alt-DEL.
| Can't do it anymore.
What should disabling C_A_D do?
| Script started on Thu 07 Apr 2005 10:58:11 AM EDT
| [SNIPPED leading stuff...]
|
| mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
| brk(0)  = 0x804a000
| brk(0x8053000)  = 0x8053000
| reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF)
= 0
| pause( unfinished ...
| _exit(0)= ?
| # exit
| Script done on Thu 07 Apr 2005 10:58:21 AM EDT
It's a program that executes the __NR_reboot syscall (88) after
putting the documented values into the appropriate registers.
What program is that?  I'm just echoing 0 | 1 into
/proc/sys/kernel/ctrl-alt-del , is that equivalent?
or have you tried that?
Doesn't matter. Many embedded systems don't have /proc because
they don't have any file-systems.
| Observe that reboot() returns 0 and `strace` understands what
| parameters were passed. The result is that, if I hit Ctl-Alt-Del,
| `init` will still execute the shutdown-order (INIT 0).
echo 0  /proc/sys/kernel/ctrl-alt-del
 is same as CAD_OFF
echo 1
 is same as CAD_ON
I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
the same way for me.  If it's an issue with using a syscall
to change the setting, I'll be glad to look into that too.
observed behaviors:
CAD enabled + C_A_D keys = call machine_reboot()
 to reboot quickly, no normal shutdown sequence;
CAD disabled + C_A_D keys = kill init, go thru normal
 clean shutdown sequence;
are these the expected behaviors?
The expected behavior of the reported operation is for
Ctl-Alt-Del to no longer do anything. If the system-call
has been depreciated, then the call should return -1 and
errno should be ENOSYS. In such a case, I would have
to trap the key-sequence in some other way, not that
I know how without modifying the kernel.
| A side note, while researching this problem, I think I found
| that LINUX_REBOOT_MAGIC2 is Linus' birthday (in hex). Maybe
| the problem is that he no longer observes his birthday?
---
~Randy
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Randy.Dunlap]

On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:

| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
| 
|  On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
| 
|  |
|  | In the not-too distant past, one could disable Ctl-Alt-DEL.
|  | Can't do it anymore.
| 
|  What should disabling C_A_D do?
| 
|  | Script started on Thu 07 Apr 2005 10:58:11 AM EDT
|  | [SNIPPED leading stuff...]
|  |
|  | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
|  | brk(0)  = 0x804a000
|  | brk(0x8053000)  = 0x8053000
|  | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF)
|  = 0
|  | pause( unfinished ...
|  | _exit(0)= ?
|  | # exit
|  | Script done on Thu 07 Apr 2005 10:58:21 AM EDT
| 
| 
| It's a program that executes the __NR_reboot syscall (88) after
| putting the documented values into the appropriate registers.

Yeah, I understood that much.  Just wondering if it was
available somewhere...

|  What program is that?  I'm just echoing 0 | 1 into
|  /proc/sys/kernel/ctrl-alt-del , is that equivalent?
|  or have you tried that?
| 
| 
| Doesn't matter. Many embedded systems don't have /proc because
| they don't have any file-systems.

It matters if they are equivalent (and I don't have that
program above).

|  | Observe that reboot() returns 0 and `strace` understands what
|  | parameters were passed. The result is that, if I hit Ctl-Alt-Del,
|  | `init` will still execute the shutdown-order (INIT 0).
| 
|  echo 0  /proc/sys/kernel/ctrl-alt-del
|   is same as CAD_OFF
|  echo 1
|   is same as CAD_ON
| 
|  I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
|  the same way for me.  If it's an issue with using a syscall
|  to change the setting, I'll be glad to look into that too.
| 
|  observed behaviors:
|  CAD enabled + C_A_D keys = call machine_reboot()
|   to reboot quickly, no normal shutdown sequence;
|  CAD disabled + C_A_D keys = kill init, go thru normal
|   clean shutdown sequence;
|  are these the expected behaviors?
| 
| The expected behavior of the reported operation is for
| Ctl-Alt-Del to no longer do anything. If the system-call
| has been depreciated, then the call should return -1 and
| errno should be ENOSYS. In such a case, I would have
| to trap the key-sequence in some other way, not that
| I know how without modifying the kernel.

Have you looked at 'man 2 reboot'?  It seems to agree with
the observed behavior (above).
or where should I look to find documentation of the
expected behavior that you described?

---
~Randy
-
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.11 can't disable CAD

[Jan Harkes]

On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
 In the not-too distant past, one could disable Ctl-Alt-DEL.
 Can't do it anymore.
...
 Observe that reboot() returns 0 and `strace` understands what
 parameters were passed. The result is that, if I hit Ctl-Alt-Del,
 `init` will still execute the shutdown-order (INIT 0).

Actually, if CAD is enabled in the kernel, it will just reboot.
If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).

So what you probably had in the not-too-distant past was a disabled CAD
in the kernel _and_ you had modified the following line in /etc/inittab,

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

AFAIK this hasn't ever really changed.

Jan

-
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.11 can't disable CAD

[Richard B. Johnson]

On Thu, 7 Apr 2005, Randy.Dunlap wrote:
On Thu, 7 Apr 2005 15:46:20 -0400 (EDT) Richard B. Johnson wrote:
| On Thu, 7 Apr 2005, Randy.Dunlap wrote:
|
|  On Thu, 7 Apr 2005 11:16:14 -0400 (EDT) Richard B. Johnson wrote:
| 
|  |
|  | In the not-too distant past, one could disable Ctl-Alt-DEL.
|  | Can't do it anymore.
| 
|  What should disabling C_A_D do?
| 
|  | Script started on Thu 07 Apr 2005 10:58:11 AM EDT
|  | [SNIPPED leading stuff...]
|  |
|  | mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
|  | brk(0)  = 0x804a000
|  | brk(0x8053000)  = 0x8053000
|  | reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_CAD_OFF)
|  = 0
|  | pause( unfinished ...
|  | _exit(0)= ?
|  | # exit
|  | Script done on Thu 07 Apr 2005 10:58:21 AM EDT
| 
|
| It's a program that executes the __NR_reboot syscall (88) after
| putting the documented values into the appropriate registers.
Yeah, I understood that much.  Just wondering if it was
available somewhere...
|  What program is that?  I'm just echoing 0 | 1 into
|  /proc/sys/kernel/ctrl-alt-del , is that equivalent?
|  or have you tried that?
| 
|
| Doesn't matter. Many embedded systems don't have /proc because
| they don't have any file-systems.
It matters if they are equivalent (and I don't have that
program above).
|  | Observe that reboot() returns 0 and `strace` understands what
|  | parameters were passed. The result is that, if I hit Ctl-Alt-Del,
|  | `init` will still execute the shutdown-order (INIT 0).
| 
|  echo 0  /proc/sys/kernel/ctrl-alt-del
|   is same as CAD_OFF
|  echo 1
|   is same as CAD_ON
| 
|  I tested 2.4.28, 2.6.3, 2.6.9, 2.6.11, and all of them behaved
|  the same way for me.  If it's an issue with using a syscall
|  to change the setting, I'll be glad to look into that too.
| 
|  observed behaviors:
|  CAD enabled + C_A_D keys = call machine_reboot()
|   to reboot quickly, no normal shutdown sequence;
|  CAD disabled + C_A_D keys = kill init, go thru normal
|   clean shutdown sequence;
|  are these the expected behaviors?
|
| The expected behavior of the reported operation is for
| Ctl-Alt-Del to no longer do anything. If the system-call
| has been depreciated, then the call should return -1 and
| errno should be ENOSYS. In such a case, I would have
| to trap the key-sequence in some other way, not that
| I know how without modifying the kernel.
Have you looked at 'man 2 reboot'?  It seems to agree with
the observed behavior (above).
or where should I look to find documentation of the
expected behavior that you described?
man 2 reboot on my system documents the system call interface
through the C runtime library.
Bbuuu then tells how glib-C munged it into a one-parameter
'C' call.   Hmmm. Maybe it's screwing me.  I will check into
this.  I don't know why `strace` shows the correct stuff when
I am making the 4-parameter call. Maybe something is really
confused
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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.11 can't disable CAD

[Richard B. Johnson]

On Thu, 7 Apr 2005, Jan Harkes wrote:
On Thu, Apr 07, 2005 at 11:16:14AM -0400, Richard B. Johnson wrote:
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
...
Observe that reboot() returns 0 and `strace` understands what
parameters were passed. The result is that, if I hit Ctl-Alt-Del,
`init` will still execute the shutdown-order (INIT 0).
Actually, if CAD is enabled in the kernel, it will just reboot.
If CAD is disabled in the kernel a SIGINT is sent to pid 1 (/sbin/init).
No, that's not how it ever worked. There are parameters that are
available in the reboot-system call that define the operation that
will occur when the 3-finger salute occurs.
Execute man 2 reboot.
So what you probably had in the not-too-distant past was a disabled CAD
in the kernel _and_ you had modified the following line in /etc/inittab,
The systems to which I refer do not, and never even had a file-system,
much-less any inittab. That's SYS-V init stuff for interactive access.
   # What to do when CTRL-ALT-DEL is pressed.
   ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
AFAIK this hasn't ever really changed.
Jan
The kernel's response (or the 'C' runtime-library interface) has
changed so that it is now possible for somebody at the keyboard
of a machine to destroy the machine's operation by executing
Ctl-Alt-Del. I don't know how long this potential catastrophe
has existed, but when the machine(s) were initially certified
there was no possible way for a user to kill the machine from
the keyboard.
It is possible that a 'C' runtime library was changed in the
tarket so it's not a kernel problem. I'm checking it out now.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: mmap/munmap on linux-2.6.11

[Aleksey Gorelov]

 >-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of linux-os
>Sent: Friday, March 25, 2005 1:19 PM
>To: Linux kernel
>Subject: mmap/munmap on linux-2.6.11
>
>Memory gurus,
>
>We have an application where a driver allocates DMA-able memory.
>This DMA-able memory is mmap()ed to user-space. To conserve
>DMA memory only single pages are obtained using
>  __get_dma_pages(GFP_KERNEL, 1) (one page at a time). These
>pages, that may be scattered all about, are mmap()ed into contiguous
>user data-space. The DMA engine uses a scatter-list so we can
>write DMA pages anywhere. They don't have to be contiguous.
>
>Here's a catch. It would be nice to release those DMA pages
>when we don't need them. However, there doesn't appear to
>be any way for driver code to know when munmap() has been
>called and those DMA pages are available to be released.
>
>How do I know that munmap() has been called? It turns out
>that if I release those pages before unmapping the user-mode,
>the system will crash. Therefore this could be a DOS attack
>if my driver ever allowed the DMA pages to be released.

munmap() should do the job for you and release those automatically.

Aleks.
-
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: mmap/munmap on linux-2.6.11

[Aleksey Gorelov]

 -Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of linux-os
Sent: Friday, March 25, 2005 1:19 PM
To: Linux kernel
Subject: mmap/munmap on linux-2.6.11

Memory gurus,

We have an application where a driver allocates DMA-able memory.
This DMA-able memory is mmap()ed to user-space. To conserve
DMA memory only single pages are obtained using
  __get_dma_pages(GFP_KERNEL, 1) (one page at a time). These
pages, that may be scattered all about, are mmap()ed into contiguous
user data-space. The DMA engine uses a scatter-list so we can
write DMA pages anywhere. They don't have to be contiguous.

Here's a catch. It would be nice to release those DMA pages
when we don't need them. However, there doesn't appear to
be any way for driver code to know when munmap() has been
called and those DMA pages are available to be released.

How do I know that munmap() has been called? It turns out
that if I release those pages before unmapping the user-mode,
the system will crash. Therefore this could be a DOS attack
if my driver ever allowed the DMA pages to be released.

munmap() should do the job for you and release those automatically.

Aleks.
-
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/

mmap/munmap on linux-2.6.11

[linux-os]

Memory gurus,
We have an application where a driver allocates DMA-able memory.
This DMA-able memory is mmap()ed to user-space. To conserve
DMA memory only single pages are obtained using
 __get_dma_pages(GFP_KERNEL, 1) (one page at a time). These
pages, that may be scattered all about, are mmap()ed into contiguous
user data-space. The DMA engine uses a scatter-list so we can
write DMA pages anywhere. They don't have to be contiguous.
Here's a catch. It would be nice to release those DMA pages
when we don't need them. However, there doesn't appear to
be any way for driver code to know when munmap() has been
called and those DMA pages are available to be released.
How do I know that munmap() has been called? It turns out
that if I release those pages before unmapping the user-mode,
the system will crash. Therefore this could be a DOS attack
if my driver ever allowed the DMA pages to be released.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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/

mmap/munmap on linux-2.6.11

[linux-os]

Memory gurus,
We have an application where a driver allocates DMA-able memory.
This DMA-able memory is mmap()ed to user-space. To conserve
DMA memory only single pages are obtained using
 __get_dma_pages(GFP_KERNEL, 1) (one page at a time). These
pages, that may be scattered all about, are mmap()ed into contiguous
user data-space. The DMA engine uses a scatter-list so we can
write DMA pages anywhere. They don't have to be contiguous.
Here's a catch. It would be nice to release those DMA pages
when we don't need them. However, there doesn't appear to
be any way for driver code to know when munmap() has been
called and those DMA pages are available to be released.
How do I know that munmap() has been called? It turns out
that if I release those pages before unmapping the user-mode,
the system will crash. Therefore this could be a DOS attack
if my driver ever allowed the DMA pages to be released.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: problem with linux 2.6.11 and sa

[George Georgalis]

On Mon, Mar 21, 2005 at 02:25:55PM -0800, Andrew Morton wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>>
>> I'm very defiantly seeing a problem with the 2.6.11
>> kernel and my spamassassin setup. However, it's not
>> clear exactly where the problem is, seems like sa
>> but it might be 2.6.11 with daemontools + qmail +
>> QMAIL_QUEUE.
>> 
>> A sure sign of it is no logs (with debug) for
>> remote sa connections which score "0/0" and correct
>> operation with local "cat spam.txt | spamc -R"; fix
>> is to use the older kernel.
>> 
>> SA has stopped stdout logging completely with 2.6.11
>> in addition to the all pass score. But the message
>> seems to go through my temp queue (for testing) and
>> sent on to my local MDA. I'm not sure if it's a sa
>> problem with the kernel or the new kernel doing
>> something new with pipes from tcp connections.
>> Maybe the new kernel is not making files available
>> (eg 0 bytes), until the writing pipe is closed?
>> That would make my SA test a zero byte file, which
>> would pass, close, become full, and the file piped
>> to local MDA is full? ...humm then I'd get a score
>> of "0/5"... this sounds like a SA problem with the
>> new kernel, ideas?
>
>George, did you end up getting to the bottom of this?  I'd be suspecting a
>bug in the new pipe code, or an application bug which was triggered by the
>new pipe code.

Hi! No resolution, I've been overloaded on a work related project.  The
best I can say is no problem noticed with 2.6.8.1, 2.6.10 works for smtp
code below but fails mplayer commands; 2.6.11 failed smtp code, didn't
test mplayer on 2.6.11 and haven't tried any newer kernels.

while read file; do mplayer $file ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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: problem with linux 2.6.11 and sa

[Andrew Morton]

"George Georgalis" <[EMAIL PROTECTED]> wrote:
>
> I'm very defiantly seeing a problem with the 2.6.11
> kernel and my spamassassin setup. However, it's not
> clear exactly where the problem is, seems like sa
> but it might be 2.6.11 with daemontools + qmail +
> QMAIL_QUEUE.
> 
> A sure sign of it is no logs (with debug) for
> remote sa connections which score "0/0" and correct
> operation with local "cat spam.txt | spamc -R"; fix
> is to use the older kernel.
> 
> SA has stopped stdout logging completely with 2.6.11
> in addition to the all pass score. But the message
> seems to go through my temp queue (for testing) and
> sent on to my local MDA. I'm not sure if it's a sa
> problem with the kernel or the new kernel doing
> something new with pipes from tcp connections.
> Maybe the new kernel is not making files available
> (eg 0 bytes), until the writing pipe is closed?
> That would make my SA test a zero byte file, which
> would pass, close, become full, and the file piped
> to local MDA is full? ...humm then I'd get a score
> of "0/5"... this sounds like a SA problem with the
> new kernel, ideas?

George, did you end up getting to the bottom of this?  I'd be suspecting a
bug in the new pipe code, or an application bug which was triggered by the
new pipe code.
-
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: problem with linux 2.6.11 and sa

[Andrew Morton]

George Georgalis [EMAIL PROTECTED] wrote:

 I'm very defiantly seeing a problem with the 2.6.11
 kernel and my spamassassin setup. However, it's not
 clear exactly where the problem is, seems like sa
 but it might be 2.6.11 with daemontools + qmail +
 QMAIL_QUEUE.
 
 A sure sign of it is no logs (with debug) for
 remote sa connections which score 0/0 and correct
 operation with local cat spam.txt | spamc -R; fix
 is to use the older kernel.
 
 SA has stopped stdout logging completely with 2.6.11
 in addition to the all pass score. But the message
 seems to go through my temp queue (for testing) and
 sent on to my local MDA. I'm not sure if it's a sa
 problem with the kernel or the new kernel doing
 something new with pipes from tcp connections.
 Maybe the new kernel is not making files available
 (eg 0 bytes), until the writing pipe is closed?
 That would make my SA test a zero byte file, which
 would pass, close, become full, and the file piped
 to local MDA is full? ...humm then I'd get a score
 of 0/5... this sounds like a SA problem with the
 new kernel, ideas?

George, did you end up getting to the bottom of this?  I'd be suspecting a
bug in the new pipe code, or an application bug which was triggered by the
new pipe code.
-
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: problem with linux 2.6.11 and sa

[George Georgalis]

On Mon, Mar 21, 2005 at 02:25:55PM -0800, Andrew Morton wrote:
George Georgalis [EMAIL PROTECTED] wrote:

 I'm very defiantly seeing a problem with the 2.6.11
 kernel and my spamassassin setup. However, it's not
 clear exactly where the problem is, seems like sa
 but it might be 2.6.11 with daemontools + qmail +
 QMAIL_QUEUE.
 
 A sure sign of it is no logs (with debug) for
 remote sa connections which score 0/0 and correct
 operation with local cat spam.txt | spamc -R; fix
 is to use the older kernel.
 
 SA has stopped stdout logging completely with 2.6.11
 in addition to the all pass score. But the message
 seems to go through my temp queue (for testing) and
 sent on to my local MDA. I'm not sure if it's a sa
 problem with the kernel or the new kernel doing
 something new with pipes from tcp connections.
 Maybe the new kernel is not making files available
 (eg 0 bytes), until the writing pipe is closed?
 That would make my SA test a zero byte file, which
 would pass, close, become full, and the file piped
 to local MDA is full? ...humm then I'd get a score
 of 0/5... this sounds like a SA problem with the
 new kernel, ideas?

George, did you end up getting to the bottom of this?  I'd be suspecting a
bug in the new pipe code, or an application bug which was triggered by the
new pipe code.

Hi! No resolution, I've been overloaded on a work related project.  The
best I can say is no problem noticed with 2.6.8.1, 2.6.10 works for smtp
code below but fails mplayer commands; 2.6.11 failed smtp code, didn't
test mplayer on 2.6.11 and haven't tried any newer kernels.

while read file; do mplayer $file ; done mediafiles.txt # fails

for file in `cat mediafiles.txt`; do mplayer $file ; done # works

mplayer foo.mpg # works 
mplayer foo.mpg  mediafiles.txt # confuses binary for keboard input

This is the code that seems to fail per quote above, stdin is the smtp
DATA

tmp=${scq}/`safecat ${scq}/tmp ${scq} /dev/stdin` \
|| { echo Error $?; exit 71; } # put the pipeline to disk, if possible
# ${scq}/tmp is a temp for this function ${scq} is temp for this
# program
score=`spamc -x -c $tmp` # score it with spamd
sce=$?

I saw some notes on the new multi page pipes, me thinks its related but
that's all I know...

Regards,
// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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: a problem with linux 2.6.11 and sa

[George Georgalis]

On Wed, Mar 16, 2005 at 05:37:59PM -0500, Paul Jarc wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>> On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>>> To simplify, what about these two:
>>> mplayer foo.mpg
>>> mplayer foo.mpg < mediafiles.txt
>>
>> The particular host does not have X support so mpg is out.
>
>Well, use any one of the files listed in mediafiles.txt.  I expect the
>first one would behave the same as your for loop, and the second would
>behave the same as your while loop.

zz.mtest contains the full path to 3 ogg files on 3 lines, no funny
characters, the following is one of them.

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg

plays fine, as expected. however, per your test:

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg 
176400 (112.0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
==
Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int 
AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Video: no video
Starting playback...
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key L 
No bind found for key _ 
No bind found for key B 
No bind found for key l 
A:   0.8 (00.8)  4.3%   
  =  PAUSE  =

Exiting... (End of file)


program crashes quickly, without any keyboard interaction.

>> I'm not sure that that test would work as mplayer requires filenames
>> as command arguments not stdin (exclusivly, I think);
>
>Note that I said to redirect input from mediafiles.txt, not from any
>of the filenames listed in it, but one of the files listed in it
>should also be passed ion the command line in both cases.
>
>Your test also had mplayer's stdin connected to mediafiles.txt.  It
>was just less explicit - mplayer inherits stdin from surrounding loop.
>So I'm suggesting simplifying the test so that stdin is the *only*
>difference between the two cases, and that will show whether it's
>relevant.  OTOH, if you can't reproduce the problem with the
>simplified pair of tests, then some interaction with the shell loops
>must be involved.

per above, the problem is reproduced with your example.

v>> this works fine
>> mplayer `cat zz.mtest `
>
>> Then I tried
>> while read file; do mplayer "$file" ; done 
>What's in zz.mtest?  E.g., if it contains a line "-", then that will
>tell mplayer to play the file on stdin, which in this case is
>zz.mtest.  Choosing one of the listed files and testing with that, as
>I suggested above, will eliminate this possibility.

zz.mtest is just 3 ogg files like the one above in my first run. Me
throws up hands, I know it is kernel api change, me thinks Linux is not
posix anymore (per lkml followup). Big concern is not my ability to play
songs, but *complex* scripts to check spam during smtp are broke in
2.6.11 (rc?) and forward.

tmp="${scq}/`safecat "${scq}/tmp" "${scq}" http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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: a problem with linux 2.6.11 and sa

[Paul Jarc]

"George Georgalis" <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>> To simplify, what about these two:
>> mplayer foo.mpg
>> mplayer foo.mpg < mediafiles.txt
>
> The particular host does not have X support so mpg is out.

Well, use any one of the files listed in mediafiles.txt.  I expect the
first one would behave the same as your for loop, and the second would
behave the same as your while loop.

> I'm not sure that that test would work as mplayer requires filenames
> as command arguments not stdin (exclusivly, I think);

Note that I said to redirect input from mediafiles.txt, not from any
of the filenames listed in it, but one of the files listed in it
should also be passed ion the command line in both cases.

Your test also had mplayer's stdin connected to mediafiles.txt.  It
was just less explicit - mplayer inherits stdin from surrounding loop.
So I'm suggesting simplifying the test so that stdin is the *only*
difference between the two cases, and that will show whether it's
relevant.  OTOH, if you can't reproduce the problem with the
simplified pair of tests, then some interaction with the shell loops
must be involved.

> this works fine
> mplayer `cat zz.mtest `
>
> Then I tried
> mplayer /dev/stdin  Then I tried
> while read file; do mplayer "$file" ; done http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.6.11-ac4

[Alan Cox]

2.6.11-ac4
o   Merge with 2.6.11.4

2.6.11-ac3
o   Make SATA AHCI error recovery work  (Brett Russ)
o   Watchdog link order (Dave Jones)
o   Ressurect the epca driver   (Alan Cox)
o   Merge with 2.6.11.3

2.6.11-ac2
o   Merge 2.6.11.2  (Greg Kroah-Hartmann)
including epoll error handling  (Georgi Guninski)
| Theoretically security
o   Fix a couple of pwc warnings(Alan Cox)
o   Ressurect esp driver(Alan Cox)

2.6.11-ac1
o   Fix jbd race in ext3(Stephen Tweedie)

Carried over from 2.6.10-ac

Security
o   AF_ROSE security hole fix - still missing from base
o   Bridge failure to check kmalloc argument overflow

Functionality
o   PWC USB camera driver
o   Working ULI526X support (added to base in .11 but broken)
o   ATP88x support
o   Intelligent misrouted IRQ handlers
o   Fix PCI boxes that take minutes IDE probing
o   Remove bogus confusing XFree86 keyboard message
o   Support fibre AMD pcnet32
o   Runtime configurable clock
| So you can run laptops usefully. Set 100Hz to fix
| the power drain, clock sliding and other problems
| 1000Hz causes
o   Fix token ring locking so token ring can be used again
o   x86_64/32 cross build fixes
o   NetROM locking fixes (so NetROM actually works!)
o   SUID dumpable support
o   Don't log pointless CD messages
o   Minimal stallion driver functionality
o   IDE from 2.6-ac



-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

Brilliant! And it even works!
Now if the kernel hadn't screwed up in the first place, then
your expertise wouldn't have been needed.
Thanks.
On Wed, 16 Mar 2005, Eric Dumazet wrote:
linux-os wrote:

I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.

If you use a buggy program, that had a hidden bug now exposed because of 
different kernel checks, dont complain, and use your brain.

If you do
$ export VAR1=" A very very very very long chain just to be sure my 
environnement (which is placed at the top of the stack at exec() time) will 
use at least 4 Kb  : then my litle buggy program will run if I type few chars 
but destroy my stack if I type a long string or if I use : cat longfile | 
./xxx : So I wont complain again on lkml that I am so lazy. Oh what could 
I type now, I'm tired, maybe I can copy this string to others variables. 
Yes... sure"
$ export VAR2=$VAR1
$ export VAR3=$VAR1
$ export VAR4=$VAR1
$ export VAR5=$VAR1
Then check your env size is large enough
$ env|wc -c
  4508
$ ./xxx
./xxx 2>/dev/null

Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical machine. 
Ready to buffer overflow again.

Maybe you can pay me $1000 :)
Eric Dumazet
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
Cheers,
Dick Johnson

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[Eric Dumazet]

linux-os wrote:

I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.

If you use a buggy program, that had a hidden bug now exposed because 
of different kernel checks, dont complain, and use your brain.

If you do
$ export VAR1=" A very very very very long chain just to be sure my 
environnement (which is placed at the top of the stack at exec() time) 
will use at least 4 Kb  : then my litle buggy program will run if I 
type few chars but destroy my stack if I type a long string or if I 
use : cat longfile | ./xxx : So I wont complain again on lkml that I 
am so lazy. Oh what could I type now, I'm tired, maybe I can copy 
this string to others variables. Yes... sure"
$ export VAR2=$VAR1
$ export VAR3=$VAR1
$ export VAR4=$VAR1
$ export VAR5=$VAR1
Then check your env size is large enough
$ env|wc -c
   4508
$ ./xxx
./xxx 2>/dev/null

Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical 
machine. Ready to buffer overflow again.

Maybe you can pay me $1000 :)
Eric Dumazet
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
Cheers,
Dick Johnson
-
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: Bogus buffer length check in linux-2.6.11 read()

[Robert Hancock]

linux-os wrote:
I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
It appears this was added by the patch shown here:
http://lwn.net/Articles/122581/
The reason given was that if the read or write doesn't use all of the 
available space due to end-of-file, etc. the remaining part of the 
buffer given by the user is not checked for accessibility, thereby 
hiding bugs. It makes little sense for an app to do a read or write with 
a buffer larger than the space that they've actually allocated.

I can see how this might be a problem when using gets, since there is no 
way to know how big the buffer that has been allocated by the 
application is.

Note that access_ok only does a rudimentary check to determine if the 
address might be a valid user-space address, it does not check every 
page to determine if it is accessible or not like verify_area did (and 
copy_to/from_user does).

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

On Wed, 16 Mar 2005, Ian Campbell wrote:
On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added "check in software" claims to prevent this, but
is wrong anyway because it can't possibly know how much
data area is available.
The manpage for read(2) that I've got says
  EFAULT buf is outside your accessible address space.
which is exactly what it would appear
   if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
   return -EFAULT;
checks for. Assuming this is the check you are bitching about -- you
could be a little more precise if you are going to complain about stuff.
Ian.

I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[Ian Campbell]

On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:

> This means that the read() is no longer perfectly happy
> to corrupt all of the user's memory which is the defacto
> correct response for a bad buffer as shown. Instead, some
> added "check in software" claims to prevent this, but
> is wrong anyway because it can't possibly know how much
> data area is available.

The manpage for read(2) that I've got says

   EFAULT buf is outside your accessible address space.

which is exactly what it would appear
if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
return -EFAULT;
checks for. Assuming this is the check you are bitching about -- you
could be a little more precise if you are going to complain about stuff.

Ian.

-- 
Ian Campbell

flannister, n.:
The plastic yoke that holds a six-pack of beer together.
-- "Sniglets", Rich Hall & Friends

-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

On Tue, 15 Mar 2005, Tom Felker wrote:
On Tuesday 15 March 2005 11:59 am, linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?

Again. Assume NOTHING. Execute the code. There is NO data
being obtained from standard input. The blocking read from
standard input returns immediately without anybody hitting
any keys whatsover. No data are generated or read.
This is because somebody wrongly added code that they
wrongly thought would prevent writing beyond a user's
allocated space.
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added "check in software" claims to prevent this, but
is wrong anyway because it can't possibly know how much
data area is available.
I don't think that's what's happening.  The kernel is perfectly happy to read
data into any virtual address range that your process can legally write to -
this includes any part of the heap and any part of the stack.  The kernel
can't check whether writing to the given address would clobber the stack or
heap - it's your memory, you manage it.  The kernel's notion of an "invalid
address" is very simple, and doesn't include every address that you would
consider invalid from a C perspective.
So what's probably happening is that your stack is (1632+256) bytes tall,
including the buffer you allocated.  (Stack grows downward on i386.)  So
ideally you read less than 256 bytes.  If you read more than 256 but less
than 1888 bytes, the read would damage other elements on the stack, but it is
OK as far as the kernel is concerned.  But if you read more than that, you're
asking the kernel to write to an address that is higher than the highest
address of the stack (the address of the bottom element), and this address
isn't mapped into your process, so you get EINVAL.
If you were to type more than 256 (but less than 1888) characters before
pressing enter, the read would silently overflow the buffer, thus clobbering
the stack, including the return address of main().  So when main tried to
return, you'd get a segfault.  Somebody with assembly skills could probably
craft a string which, when your program reads it, would take control of the
program.
--
Tom Felker, <[EMAIL PROTECTED]>
 - Stop fiddling with the volume knob.
No army can withstand the strength of an idea whose time has come.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

On Tue, 15 Mar 2005, Robert Hancock wrote:
linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Likely because only 1632 bytes of memory is accessible after the start of the 
buf buffer, and trying to read in more than that results in copy_to_user 
failing to write some data.

There was NO DATA read or written! The read() call returns immediately
without reading anything. Look at the code, assume nothing. This
is a blocking read from standard-input.
Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?
What additional check?
Somebody added some very dumb check of the input value
of a read() length that occurs before anything is
actually read.
Previously, a read(), which is a kernel write to user-data
space, would seg-fault if the read exceeded the data-space
that had been mapped. It is done by the CPU, it generates
a trap. The performance cost, when done by the CPU, if
the data doesn't exceed bounds, is zero. Now, there is
a beginning check (a wrong check BTW), in software,
before the data is even obtained from the device.
--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

On Tue, 15 Mar 2005, Robert Hancock wrote:
linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Likely because only 1632 bytes of memory is accessible after the start of the 
buf buffer, and trying to read in more than that results in copy_to_user 
failing to write some data.

There was NO DATA read or written! The read() call returns immediately
without reading anything. Look at the code, assume nothing. This
is a blocking read from standard-input.
Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?
What additional check?
Somebody added some very dumb check of the input value
of a read() length that occurs before anything is
actually read.
Previously, a read(), which is a kernel write to user-data
space, would seg-fault if the read exceeded the data-space
that had been mapped. It is done by the CPU, it generates
a trap. The performance cost, when done by the CPU, if
the data doesn't exceed bounds, is zero. Now, there is
a beginning check (a wrong check BTW), in software,
before the data is even obtained from the device.
--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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/
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

On Tue, 15 Mar 2005, Tom Felker wrote:
On Tuesday 15 March 2005 11:59 am, linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?

Again. Assume NOTHING. Execute the code. There is NO data
being obtained from standard input. The blocking read from
standard input returns immediately without anybody hitting
any keys whatsover. No data are generated or read.
This is because somebody wrongly added code that they
wrongly thought would prevent writing beyond a user's
allocated space.
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added check in software claims to prevent this, but
is wrong anyway because it can't possibly know how much
data area is available.
I don't think that's what's happening.  The kernel is perfectly happy to read
data into any virtual address range that your process can legally write to -
this includes any part of the heap and any part of the stack.  The kernel
can't check whether writing to the given address would clobber the stack or
heap - it's your memory, you manage it.  The kernel's notion of an invalid
address is very simple, and doesn't include every address that you would
consider invalid from a C perspective.
So what's probably happening is that your stack is (1632+256) bytes tall,
including the buffer you allocated.  (Stack grows downward on i386.)  So
ideally you read less than 256 bytes.  If you read more than 256 but less
than 1888 bytes, the read would damage other elements on the stack, but it is
OK as far as the kernel is concerned.  But if you read more than that, you're
asking the kernel to write to an address that is higher than the highest
address of the stack (the address of the bottom element), and this address
isn't mapped into your process, so you get EINVAL.
If you were to type more than 256 (but less than 1888) characters before
pressing enter, the read would silently overflow the buffer, thus clobbering
the stack, including the return address of main().  So when main tried to
return, you'd get a segfault.  Somebody with assembly skills could probably
craft a string which, when your program reads it, would take control of the
program.
--
Tom Felker, [EMAIL PROTECTED]
http://vlevel.sourceforge.net - Stop fiddling with the volume knob.
No army can withstand the strength of an idea whose time has come.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[Ian Campbell]

On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:

 This means that the read() is no longer perfectly happy
 to corrupt all of the user's memory which is the defacto
 correct response for a bad buffer as shown. Instead, some
 added check in software claims to prevent this, but
 is wrong anyway because it can't possibly know how much
 data area is available.

The manpage for read(2) that I've got says

   EFAULT buf is outside your accessible address space.

which is exactly what it would appear
if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
return -EFAULT;
checks for. Assuming this is the check you are bitching about -- you
could be a little more precise if you are going to complain about stuff.

Ian.

-- 
Ian Campbell

flannister, n.:
The plastic yoke that holds a six-pack of beer together.
-- Sniglets, Rich Hall  Friends

-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

On Wed, 16 Mar 2005, Ian Campbell wrote:
On Wed, 2005-03-16 at 07:29 -0500, linux-os wrote:
This means that the read() is no longer perfectly happy
to corrupt all of the user's memory which is the defacto
correct response for a bad buffer as shown. Instead, some
added check in software claims to prevent this, but
is wrong anyway because it can't possibly know how much
data area is available.
The manpage for read(2) that I've got says
  EFAULT buf is outside your accessible address space.
which is exactly what it would appear
   if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
   return -EFAULT;
checks for. Assuming this is the check you are bitching about -- you
could be a little more precise if you are going to complain about stuff.
Ian.

I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: Bogus buffer length check in linux-2.6.11 read()

[Robert Hancock]

linux-os wrote:
I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
It appears this was added by the patch shown here:
http://lwn.net/Articles/122581/
The reason given was that if the read or write doesn't use all of the 
available space due to end-of-file, etc. the remaining part of the 
buffer given by the user is not checked for accessibility, thereby 
hiding bugs. It makes little sense for an app to do a read or write with 
a buffer larger than the space that they've actually allocated.

I can see how this might be a problem when using gets, since there is no 
way to know how big the buffer that has been allocated by the 
application is.

Note that access_ok only does a rudimentary check to determine if the 
address might be a valid user-space address, it does not check every 
page to determine if it is accessible or not like verify_area did (and 
copy_to/from_user does).

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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: Bogus buffer length check in linux-2.6.11 read()

[Eric Dumazet]

linux-os wrote:

I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.

If you use a buggy program, that had a hidden bug now exposed because 
of different kernel checks, dont complain, and use your brain.

If you do
$ export VAR1= A very very very very long chain just to be sure my 
environnement (which is placed at the top of the stack at exec() time) 
will use at least 4 Kb  : then my litle buggy program will run if I 
type few chars but destroy my stack if I type a long string or if I 
use : cat longfile | ./xxx : So I wont complain again on lkml that I 
am so lazy. Oh what could I type now, I'm tired, maybe I can copy 
this string to others variables. Yes... sure
$ export VAR2=$VAR1
$ export VAR3=$VAR1
$ export VAR4=$VAR1
$ export VAR5=$VAR1
Then check your env size is large enough
$ env|wc -c
   4508
$ ./xxx
./xxx 2/dev/null

Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical 
machine. Ready to buffer overflow again.

Maybe you can pay me $1000 :)
Eric Dumazet
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
Cheers,
Dick Johnson
-
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: Bogus buffer length check in linux-2.6.11 read()

[linux-os]

Brilliant! And it even works!
Now if the kernel hadn't screwed up in the first place, then
your expertise wouldn't have been needed.
Thanks.
On Wed, 16 Mar 2005, Eric Dumazet wrote:
linux-os wrote:

I don't know how much more precise I could have been. I show the
code that will cause the observed condition. I explain that this
condition is new, that it doesn't correspond to the previous
behavior.
Never before was some buffer checked for length before some data
was written to it. The EFAULT is supposed to occur IFF a write
attempt occurs outside the caller's accessible address space.
This used to be done by hardware during the write to user-space.
This had zero impact upon performance. Now there is some
software added that adds CPU cycles, subtracts performance,
and cannot possibly do anything useful.
Also, the code was written to show the problem. The code
is not designed to be an example of good coding practice.
The actual problem observed with the new kernel was
when some legacy code used gets() instead of fgets().
The call returned immediately with an EFAULT because
the 'C' runtime library put some value that the kernel
didn't 'like' (4096 bytes) in the subsequent read.

If you use a buggy program, that had a hidden bug now exposed because of 
different kernel checks, dont complain, and use your brain.

If you do
$ export VAR1= A very very very very long chain just to be sure my 
environnement (which is placed at the top of the stack at exec() time) will 
use at least 4 Kb  : then my litle buggy program will run if I type few chars 
but destroy my stack if I type a long string or if I use : cat longfile | 
./xxx : So I wont complain again on lkml that I am so lazy. Oh what could 
I type now, I'm tired, maybe I can copy this string to others variables. 
Yes... sure
$ export VAR2=$VAR1
$ export VAR3=$VAR1
$ export VAR4=$VAR1
$ export VAR5=$VAR1
Then check your env size is large enough
$ env|wc -c
  4508
$ ./xxx
./xxx 2/dev/null

Apparently the kernel thinks 4096 is a good length!
So what ? Your program works well now, on a linux-2.6.11 typical machine. 
Ready to buffer overflow again.

Maybe you can pay me $1000 :)
Eric Dumazet
This is code for which there are no sources available
and it is required to be used, cannot be replaced,
cannot be thrown away and costs about US$ 10,000
from a company that is no longer in business.
Somebody's arbitrary and capricious addition of spook
code destroyed an application's functionality.
Cheers,
Dick Johnson

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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/

Linux 2.6.11-ac4

[Alan Cox]

2.6.11-ac4
o   Merge with 2.6.11.4

2.6.11-ac3
o   Make SATA AHCI error recovery work  (Brett Russ)
o   Watchdog link order (Dave Jones)
o   Ressurect the epca driver   (Alan Cox)
o   Merge with 2.6.11.3

2.6.11-ac2
o   Merge 2.6.11.2  (Greg Kroah-Hartmann)
including epoll error handling  (Georgi Guninski)
| Theoretically security
o   Fix a couple of pwc warnings(Alan Cox)
o   Ressurect esp driver(Alan Cox)

2.6.11-ac1
o   Fix jbd race in ext3(Stephen Tweedie)

Carried over from 2.6.10-ac

Security
o   AF_ROSE security hole fix - still missing from base
o   Bridge failure to check kmalloc argument overflow

Functionality
o   PWC USB camera driver
o   Working ULI526X support (added to base in .11 but broken)
o   ATP88x support
o   Intelligent misrouted IRQ handlers
o   Fix PCI boxes that take minutes IDE probing
o   Remove bogus confusing XFree86 keyboard message
o   Support fibre AMD pcnet32
o   Runtime configurable clock
| So you can run laptops usefully. Set 100Hz to fix
| the power drain, clock sliding and other problems
| 1000Hz causes
o   Fix token ring locking so token ring can be used again
o   x86_64/32 cross build fixes
o   NetROM locking fixes (so NetROM actually works!)
o   SUID dumpable support
o   Don't log pointless CD messages
o   Minimal stallion driver functionality
o   IDE from 2.6-ac



-
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: a problem with linux 2.6.11 and sa

[Paul Jarc]

George Georgalis [EMAIL PROTECTED] wrote:
 On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
 To simplify, what about these two:
 mplayer foo.mpg
 mplayer foo.mpg  mediafiles.txt

 The particular host does not have X support so mpg is out.

Well, use any one of the files listed in mediafiles.txt.  I expect the
first one would behave the same as your for loop, and the second would
behave the same as your while loop.

 I'm not sure that that test would work as mplayer requires filenames
 as command arguments not stdin (exclusivly, I think);

Note that I said to redirect input from mediafiles.txt, not from any
of the filenames listed in it, but one of the files listed in it
should also be passed ion the command line in both cases.

Your test also had mplayer's stdin connected to mediafiles.txt.  It
was just less explicit - mplayer inherits stdin from surrounding loop.
So I'm suggesting simplifying the test so that stdin is the *only*
difference between the two cases, and that will show whether it's
relevant.  OTOH, if you can't reproduce the problem with the
simplified pair of tests, then some interaction with the shell loops
must be involved.

 this works fine
 mplayer `cat zz.mtest `

 Then I tried
 mplayer /dev/stdin zz.mtest

In the first case, mplayer is processing the files listed in
zz.mtest.  In the second case, it's processing zz.mtest itself.  So
it's not surprising that you get different results here.

 Then I tried
 while read file; do mplayer $file ; done zz.mtest

What's in zz.mtest?  E.g., if it contains a line -, then that will
tell mplayer to play the file on stdin, which in this case is
zz.mtest.  Choosing one of the listed files and testing with that, as
I suggested above, will eliminate this possibility.


paul
-
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: a problem with linux 2.6.11 and sa

[George Georgalis]

On Wed, Mar 16, 2005 at 05:37:59PM -0500, Paul Jarc wrote:
George Georgalis [EMAIL PROTECTED] wrote:
 On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
 To simplify, what about these two:
 mplayer foo.mpg
 mplayer foo.mpg  mediafiles.txt

 The particular host does not have X support so mpg is out.

Well, use any one of the files listed in mediafiles.txt.  I expect the
first one would behave the same as your for loop, and the second would
behave the same as your while loop.

zz.mtest contains the full path to 3 ogg files on 3 lines, no funny
characters, the following is one of them.

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg

plays fine, as expected. however, per your test:

$ mplayer 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg 
zz.mtest 
MPlayer 1.0pre6-2.95.4 (C) 2000-2004 MPlayer Team
CPU: IDT/Centaur/VIA C3 Nehemiah (Family: 6, Stepping: 5)
Detected cache-line size is 32 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE


Playing 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg.
Ogg file format detected.
==
Opening audio decoder: [libvorbis] Ogg/Vorbis audio decoder
AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 14001-176400 (112.0 kbit)
Selected audio codec: [vorbis] afm:libvorbis (OggVorbis Audio Decoder)
==
Checking audio filter chain for 44100Hz/2ch/16bit - 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int 
AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit - 44100Hz/2ch/16bit...
Video: no video
Starting playback...
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key L 
No bind found for key _ 
No bind found for key B 
No bind found for key l 
A:   0.8 (00.8)  4.3%   
  =  PAUSE  =

Exiting... (End of file)


program crashes quickly, without any keyboard interaction.

 I'm not sure that that test would work as mplayer requires filenames
 as command arguments not stdin (exclusivly, I think);

Note that I said to redirect input from mediafiles.txt, not from any
of the filenames listed in it, but one of the files listed in it
should also be passed ion the command line in both cases.

Your test also had mplayer's stdin connected to mediafiles.txt.  It
was just less explicit - mplayer inherits stdin from surrounding loop.
So I'm suggesting simplifying the test so that stdin is the *only*
difference between the two cases, and that will show whether it's
relevant.  OTOH, if you can't reproduce the problem with the
simplified pair of tests, then some interaction with the shell loops
must be involved.

per above, the problem is reproduced with your example.

v this works fine
 mplayer `cat zz.mtest `

 Then I tried
 while read file; do mplayer $file ; done zz.mtest

What's in zz.mtest?  E.g., if it contains a line -, then that will
tell mplayer to play the file on stdin, which in this case is
zz.mtest.  Choosing one of the listed files and testing with that, as
I suggested above, will eliminate this possibility.

zz.mtest is just 3 ogg files like the one above in my first run. Me
throws up hands, I know it is kernel api change, me thinks Linux is not
posix anymore (per lkml followup). Big concern is not my ability to play
songs, but *complex* scripts to check spam during smtp are broke in
2.6.11 (rc?) and forward.

tmp=${scq}/`safecat ${scq}/tmp ${scq} /dev/stdin` \
|| { echo Error $?; exit 71; } # put the pipeline to disk, if possible
# ${scq}/tmp is a temp for this function ${scq} is temp for this program
score=`spamc -x -c $tmp` # score it with spamd
sce=$?

... Who knows what else won't be working.

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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: a problem with linux 2.6.11 and sa

[George Georgalis]

On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
>"George Georgalis" <[EMAIL PROTECTED]> wrote:
>> It (Gerrit Pape's technique) very defiantly stopped working a few revs
>> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
>> mplayer with 2.6.10, now too.
>
>The /proc/kmsg problem happens because the kernel now checks for
>permission at read() instead of open().  The /dev/rtc problem seems to
>be a different beast.

Thanks for the kmsg clairfication, Paul.

>> while read file; do mplayer $file ; done >
>> Failed to open /dev/rtc: Permission denied
>>
>> for file in `cat mediafiles.txt`; do mplayer $file ; done
>>
>> works.
>
>To simplify, what about these two:
>mplayer foo.mpg
>mplayer foo.mpg < mediafiles.txt
>
>You might try strace'ing both cases and see how they compare.

The particular host does not have X support so mpg is out.
I'm not sure that that test would work as mplayer requires filenames
as command arguments not stdin (exclusivly, I think); my guess
is mplayer would try to decode stdin.

this works fine
mplayer `cat zz.mtest `

Then I tried
mplayer /dev/stdin  /proc/sys/dev/rtc/max-user-freq" to your system startup 
scripts.

the file almost played though...
Playing 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg.
Ogg file format detected.
...

But it seemed to take keyboard commands from the binary
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key R 
A:   0.8 (00.8)  4.2%   

and quit.  I tried the sysctl suggestion, no change, whenever a file list
is redirected to stdin, and a filename argument is given to mplayer, eg

while read file; do mplayer "$file" ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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: Bogus buffer length check in linux-2.6.11 read()

[Tom Felker]

On Tuesday 15 March 2005 11:59 am, linux-os wrote:
> The attached file shows that the kernel thinks it's doing
> something helpful by checking the length of the input
> buffer for a read(). It will return "Bad Address" until
> the length is 1632 bytes.  Apparently the kernel thinks
> 1632 is a good length!
>
> Did anybody consider the overhead necessary to do this
> and the fact that the kernel has no way of knowing if
> the pointer to the buffer is valid until it actually
> does the write. What was wrong with copy_to_user()?
> Why is there the additional bogus check?

I don't think that's what's happening.  The kernel is perfectly happy to read 
data into any virtual address range that your process can legally write to - 
this includes any part of the heap and any part of the stack.  The kernel 
can't check whether writing to the given address would clobber the stack or 
heap - it's your memory, you manage it.  The kernel's notion of an "invalid 
address" is very simple, and doesn't include every address that you would 
consider invalid from a C perspective.

So what's probably happening is that your stack is (1632+256) bytes tall, 
including the buffer you allocated.  (Stack grows downward on i386.)  So 
ideally you read less than 256 bytes.  If you read more than 256 but less 
than 1888 bytes, the read would damage other elements on the stack, but it is 
OK as far as the kernel is concerned.  But if you read more than that, you're 
asking the kernel to write to an address that is higher than the highest 
address of the stack (the address of the bottom element), and this address 
isn't mapped into your process, so you get EINVAL.

If you were to type more than 256 (but less than 1888) characters before 
pressing enter, the read would silently overflow the buffer, thus clobbering 
the stack, including the return address of main().  So when main tried to 
return, you'd get a segfault.  Somebody with assembly skills could probably 
craft a string which, when your program reads it, would take control of the 
program.

-- 
Tom Felker, <[EMAIL PROTECTED]>
 - Stop fiddling with the volume knob.

No army can withstand the strength of an idea whose time has come.
-
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: Bogus buffer length check in linux-2.6.11 read()

[Robert Hancock]

linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Likely because only 1632 bytes of memory is accessible after the start 
of the buf buffer, and trying to read in more than that results in 
copy_to_user failing to write some data.

Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?
What additional check?
--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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/

Bogus buffer length check in linux-2.6.11 read()

[linux-os]

The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return "Bad Address" until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
#include 
#include 
#include 

int main()
{
 char buf[0x100];
 size_t i;
 int val;
 for(i=0x1000; i > 0; i--)
 {
 if((val = read(STDIN_FILENO, buf, i)) == -1)
 perror("read");
 else
 {
 printf("Apparently the kernel thinks %u is a good length!\n", i);
 break;
 }
 }
return 0;
}

Bogus buffer length check in linux-2.6.11 read()

[linux-os]

The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
#include stdio.h
#include stdlib.h
#include unistd.h

int main()
{
 char buf[0x100];
 size_t i;
 int val;
 for(i=0x1000; i  0; i--)
 {
 if((val = read(STDIN_FILENO, buf, i)) == -1)
 perror(read);
 else
 {
 printf(Apparently the kernel thinks %u is a good length!\n, i);
 break;
 }
 }
return 0;
}

Re: Bogus buffer length check in linux-2.6.11 read()

[Robert Hancock]

linux-os wrote:
The attached file shows that the kernel thinks it's doing
something helpful by checking the length of the input
buffer for a read(). It will return Bad Address until
the length is 1632 bytes.  Apparently the kernel thinks
1632 is a good length!
Likely because only 1632 bytes of memory is accessible after the start 
of the buf buffer, and trying to read in more than that results in 
copy_to_user failing to write some data.

Did anybody consider the overhead necessary to do this
and the fact that the kernel has no way of knowing if
the pointer to the buffer is valid until it actually
does the write. What was wrong with copy_to_user()?
Why is there the additional bogus check?
What additional check?
--
Robert Hancock  Saskatoon, SK, Canada
To email, remove nospam from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
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: Bogus buffer length check in linux-2.6.11 read()

[Tom Felker]

On Tuesday 15 March 2005 11:59 am, linux-os wrote:
 The attached file shows that the kernel thinks it's doing
 something helpful by checking the length of the input
 buffer for a read(). It will return Bad Address until
 the length is 1632 bytes.  Apparently the kernel thinks
 1632 is a good length!

 Did anybody consider the overhead necessary to do this
 and the fact that the kernel has no way of knowing if
 the pointer to the buffer is valid until it actually
 does the write. What was wrong with copy_to_user()?
 Why is there the additional bogus check?

I don't think that's what's happening.  The kernel is perfectly happy to read 
data into any virtual address range that your process can legally write to - 
this includes any part of the heap and any part of the stack.  The kernel 
can't check whether writing to the given address would clobber the stack or 
heap - it's your memory, you manage it.  The kernel's notion of an invalid 
address is very simple, and doesn't include every address that you would 
consider invalid from a C perspective.

So what's probably happening is that your stack is (1632+256) bytes tall, 
including the buffer you allocated.  (Stack grows downward on i386.)  So 
ideally you read less than 256 bytes.  If you read more than 256 but less 
than 1888 bytes, the read would damage other elements on the stack, but it is 
OK as far as the kernel is concerned.  But if you read more than that, you're 
asking the kernel to write to an address that is higher than the highest 
address of the stack (the address of the bottom element), and this address 
isn't mapped into your process, so you get EINVAL.

If you were to type more than 256 (but less than 1888) characters before 
pressing enter, the read would silently overflow the buffer, thus clobbering 
the stack, including the return address of main().  So when main tried to 
return, you'd get a segfault.  Somebody with assembly skills could probably 
craft a string which, when your program reads it, would take control of the 
program.

-- 
Tom Felker, [EMAIL PROTECTED]
http://vlevel.sourceforge.net - Stop fiddling with the volume knob.

No army can withstand the strength of an idea whose time has come.
-
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: a problem with linux 2.6.11 and sa

[George Georgalis]

On Wed, Mar 09, 2005 at 06:28:35PM -0500, Paul Jarc wrote:
George Georgalis [EMAIL PROTECTED] wrote:
 It (Gerrit Pape's technique) very defiantly stopped working a few revs
 back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
 mplayer with 2.6.10, now too.

The /proc/kmsg problem happens because the kernel now checks for
permission at read() instead of open().  The /dev/rtc problem seems to
be a different beast.

Thanks for the kmsg clairfication, Paul.

 while read file; do mplayer $file ; done mediafiles.txt

 Failed to open /dev/rtc: Permission denied

 for file in `cat mediafiles.txt`; do mplayer $file ; done

 works.

To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg  mediafiles.txt

You might try strace'ing both cases and see how they compare.

The particular host does not have X support so mpg is out.
I'm not sure that that test would work as mplayer requires filenames
as command arguments not stdin (exclusivly, I think); my guess
is mplayer would try to decode stdin.

this works fine
mplayer `cat zz.mtest `

Then I tried
mplayer /dev/stdin zz.mtest

I got
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)

so what the heck, I changed it...
$ ls -l /dev/rtc 
crw-rw1 root root  10, 135 Mar 14  2002 /dev/rtc
chmod o+r /dev/rtc

Then I tried
while read file; do mplayer $file ; done zz.mtest

and got
Linux RTC init error in ioctl (rtc_irqp_set 1024): Permission denied
Try adding echo 1024  /proc/sys/dev/rtc/max-user-freq to your system startup 
scripts.

the file almost played though...
Playing 
/usr/nfs/sandbox/media/audio/_the-party-has-just-begun/Lebanese_Blonde.ogg.
Ogg file format detected.
...

But it seemed to take keyboard commands from the binary
No bind found for key _ 
A:   0.1 (00.1) ??,?%   
No bind found for key R 
A:   0.8 (00.8)  4.2%   

and quit.  I tried the sysctl suggestion, no change, whenever a file list
is redirected to stdin, and a filename argument is given to mplayer, eg

while read file; do mplayer $file ; done zz.mtest

now I don't have rtc errors but mplayer is getting strange input it
doesn't grok.

Once again, this works fine without the changed rtc perms or the sysctl
echo:

mplayer `cat zz.mtest`

I've not had a chance to properly test - I still think there is a new
kernel bug/feature but cant find time to properly track it down.

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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/

Linux 2.6.11-ac3

[Alan Cox]

Almost entirely the 2.6.11.3 update this time. Nice and simple because the
2.6.11.x is working out wonderfully.

Alan


2.6.11-ac3
o   Merge in 2.6.11.3
o   Make SATA AHCI error recovery work  (Brett Russ)
o   Watchdog link order (Dave Jones)
o   Ressurect epca serial driver(Alan Cox)

2.6.11-ac2
o   Merge 2.6.11.2  (Greg Kroah-Hartmann)
including epoll error handling  (Georgi Guninski)
| Theoretically security
o   Fix a couple of pwc warnings(Alan Cox)
o   Ressurect esp serial driver (Alan Cox)

2.6.11-ac1
o   Fix jbd race in ext3(Stephen Tweedie)

Carried over from 2.6.10-ac

Security
o   AF_ROSE security hole fix - still missing from base
o   Bridge failure to check kmalloc argument overflow

Functionality
o   PWC USB camera driver
o   Working ULI526X support (added to base in .11 but broken)
o   ATP88x support
o   Intelligent misrouted IRQ handlers
o   Fix PCI boxes that take minutes IDE probing
o   Remove bogus confusing XFree86 keyboard message
o   Support fibre AMD pcnet32
o   Runtime configurable clock
| So you can run laptops usefully. Set 100Hz to fix
| the power drain, clock sliding and other problems
| 1000Hz causes
o   Fix token ring locking so token ring can be used again
o   x86_64/32 cross build fixes
o   NetROM locking fixes (so NetROM actually works!)
o   SUID dumpable support
o   Don't log pointless CD messages
o   Minimal stallion driver functionality
o   IDE from 2.6-ac

Misc
o   Correct LANANA URL


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

Linux 2.6.11-ac3

[Alan Cox]

Almost entirely the 2.6.11.3 update this time. Nice and simple because the
2.6.11.x is working out wonderfully.

Alan


2.6.11-ac3
o   Merge in 2.6.11.3
o   Make SATA AHCI error recovery work  (Brett Russ)
o   Watchdog link order (Dave Jones)
o   Ressurect epca serial driver(Alan Cox)

2.6.11-ac2
o   Merge 2.6.11.2  (Greg Kroah-Hartmann)
including epoll error handling  (Georgi Guninski)
| Theoretically security
o   Fix a couple of pwc warnings(Alan Cox)
o   Ressurect esp serial driver (Alan Cox)

2.6.11-ac1
o   Fix jbd race in ext3(Stephen Tweedie)

Carried over from 2.6.10-ac

Security
o   AF_ROSE security hole fix - still missing from base
o   Bridge failure to check kmalloc argument overflow

Functionality
o   PWC USB camera driver
o   Working ULI526X support (added to base in .11 but broken)
o   ATP88x support
o   Intelligent misrouted IRQ handlers
o   Fix PCI boxes that take minutes IDE probing
o   Remove bogus confusing XFree86 keyboard message
o   Support fibre AMD pcnet32
o   Runtime configurable clock
| So you can run laptops usefully. Set 100Hz to fix
| the power drain, clock sliding and other problems
| 1000Hz causes
o   Fix token ring locking so token ring can be used again
o   x86_64/32 cross build fixes
o   NetROM locking fixes (so NetROM actually works!)
o   SUID dumpable support
o   Don't log pointless CD messages
o   Minimal stallion driver functionality
o   IDE from 2.6-ac

Misc
o   Correct LANANA URL


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

[PATCH]: linux-2.6.11-uc0 (MMU-less fixups)

[Greg Ungerer]

Hi All,
An update of the uClinux (MMU-less) fixups against 2.6.11.
Most new changes center around the recent nommu changes to keep
the mm list as a vma list. Still a bunch of old changes I need
to push up stream in this patch too.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.11-uc0.patch.gz
Change log:
. import of linux-2.6.11   <[EMAIL PROTECTED]>
. change vma list setup for nommu  <[EMAIL PROTECTED]>
. fix MAGIC_ROMPTR nommu support   <[EMAIL PROTECTED]>
. remove unused semp3.h<[EMAIL PROTECTED]>
Regards
Greg


Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
SnapGear -- a CyberGuard CompanyPHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
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/

[PATCH]: linux-2.6.11-uc0 (MMU-less fixups)

[Greg Ungerer]

Hi All,
An update of the uClinux (MMU-less) fixups against 2.6.11.
Most new changes center around the recent nommu changes to keep
the mm list as a vma list. Still a bunch of old changes I need
to push up stream in this patch too.
http://www.uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.11-uc0.patch.gz
Change log:
. import of linux-2.6.11   [EMAIL PROTECTED]
. change vma list setup for nommu  [EMAIL PROTECTED]
. fix MAGIC_ROMPTR nommu support   [EMAIL PROTECTED]
. remove unused semp3.h[EMAIL PROTECTED]
Regards
Greg


Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
SnapGear -- a CyberGuard CompanyPHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
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/

[CHECKER] fsync doesn't sync data properly (JFS, Linux 2.6.11)

[Junfeng Yang]

Hi,

FiSC founds a potential error on JFS (Linux 2.6.11) where fsync doesn't
properly flushes out file data.  Crash after this fsync causes data loss.
The test case can be found at http://fisc.stanford.edu/bug9/crash.c

To reproduce it, download and compile crash.c, and run it on a fresh jfs
partition.  File /mnt/sbd0/0006/0010/0029/0033 should contain
-23,-69,101,-119, However, the crash-recovered version contains all 0s.

Please let me know if you need more information.

As usual, confirmations/clarifications are appreciated,
-Junfeng

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

[CHECKER] fsync doesn't sync data properly (JFS, Linux 2.6.11)

[Junfeng Yang]

Hi,

FiSC founds a potential error on JFS (Linux 2.6.11) where fsync doesn't
properly flushes out file data.  Crash after this fsync causes data loss.
The test case can be found at http://fisc.stanford.edu/bug9/crash.c

To reproduce it, download and compile crash.c, and run it on a fresh jfs
partition.  File /mnt/sbd0/0006/0010/0029/0033 should contain
-23,-69,101,-119, However, the crash-recovered version contains all 0s.

Please let me know if you need more information.

As usual, confirmations/clarifications are appreciated,
-Junfeng

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

x86-64 linux-2.6.11-mm2 - BUG: soft lockup detected on CPU#0! (ohci_hub_resume)

[Sam Elstob]

Just booted 2.6.11-mm2 with a new .config and ran into this BUG().  Here
is the snippet from dmesg.

[   25.088135] ohci_hcd :00:02.0: wakeup
[   25.113120] BUG: soft lockup detected on CPU#0!
[   25.113128]
[   25.113135] Modules linked in: ehci_hcd ohci_hcd usbcore i2c_nforce2
it87 eeprom i2c_sensor i2c_isa i2c_dev i2c_core cpufreq_userspace
powernow_k8 freq_table processor r8169 psmouse forcedeth unix
[   25.113216] Pid: 4, comm: events/0 Not tainted 2.6.11-mm2
[   25.113225] RIP: 0010:[] {__delay
+5}
[   25.113240] RSP: :810002145e20  EFLAGS: 0283
[   25.113255] RAX: 0005f88c RBX: 8015e88b RCX:
c355687a
[   25.113265] RDX: 000b RSI: 0001 RDI:
001e5d70
[   25.113274] RBP: 810001d888c8 R08: 0720 R09:
0004
[   25.113284] R10:  R11: 0001 R12:

[   25.113294] R13: 810002144000 R14: c2004000 R15:
81003fed8108
[   25.113305] FS:  2ae00520() GS:80459800()
knlGS:
[   25.113317] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[   25.113326] CR2: 005cec28 CR3: 3f31b000 CR4:
06e0
[   25.113335]
[   25.113336] Call Trace:{:ohci_hcd:ohci_hub_resume
+388} {:ohci_hcd:ohci_rh_resume+21}
[   25.113376]{worker_thread+497}
{default_wake_function+0}
[   25.113410]{thread_return+118}
{default_wake_function+0}
[   25.113444]{worker_thread+0}
{kthread+136}
[   25.113475]{child_rip+8}
{worker_thread+0}
[   25.113507]{kthread+0}
{child_rip+0}
[   25.113538]
[   25.548709] usb 1-4: new full speed USB device using ohci_hcd and
address 2

Attached is the .config.

Sam
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux EvilTwin 2.6.11-mm2 #1 Tue Mar 8 22:56:38 GMT 2005 x86_64 GNU/Linux
 
Gnu C  3.3.5
Gnu make   3.80
binutils   2.15
util-linux 2.12p
mount  2.12p
module-init-tools  3.2-pre1
e2fsprogs  1.36
reiserfsprogs  line
reiser4progs   line
nfs-utils  1.0.7
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.5
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
udev   054
Modules Loaded rfcomm l2cap ipv6 af_packet mousedev evdev floppy rtc 
usbhid usblp hci_usb bluetooth snd_emu10k1 snd_rawmidi snd_seq_device 
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd 
soundcore ehci_hcd ohci_hcd usbcore i2c_nforce2 it87 eeprom i2c_sensor i2c_isa 
i2c_dev i2c_core cpufreq_userspace powernow_k8 freq_table processor r8169 
psmouse forcedeth unix
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-mm2
# Thu Mar 10 16:08:54 2005
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_HPET_TIMER=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_PHYSICAL_START=0x10
# CONFIG_KEXEC is not set
CONFIG_SECCOMP=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION="/dev/hda1"

#
# ACPI (Advanced Configuration and Power Interface) Support
#

Re: Linux 2.6.11-ac1

[Alan Cox]

On Iau, 2005-03-10 at 09:06, Tupshin Harper wrote:
> Alan...since you disagreed with the earlier characterization of what it 
> would take to get into the mainline kernels, could you let us know what 
> it would take in your opinion? FWIW, I'm happily using it with a -ac kernel.

It needs some small changes in the base ide-disk code to handle drives
having only a logical geometry (legal but Linux can't cope). Most if not
all the other hooks are there to an extent the driver for the it821x can
work without core code changes. It might be cleaner with core changes
but it's better that the it821x code handles the weirdness of the
hardware.

Longer term it (and probably every other IDE PATA driver) should be
moved to the Jeff Garzik SATA layer. That's also Bart's position I
believe ?

-
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.11-ac1

[Tupshin Harper]

Alan Cox wrote:
On Mer, 2005-03-09 at 22:22, CaT wrote:
 

Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
   

Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1 performance is very good and it can do hotplug IDE
transparently in hardware raid modes. Its a good solid little
controller. 

Alan
Alan...since you disagreed with the earlier characterization of what it 
would take to get into the mainline kernels, could you let us know what 
it would take in your opinion? FWIW, I'm happily using it with a -ac kernel.

-Tupshin
-
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.11-ac1

[Denis Vlasenko]

On Wednesday 09 March 2005 17:51, Alan Cox wrote:
> On Mer, 2005-03-09 at 07:26, CaT wrote:
> > > Carried over from 2.6.10-ac
> > 
> > BTW. What's the probability of the ITE driver making it into the stock
> > kernel?
> 
> I have given up caring about the base kernel IDE code. I've tried to get
> stuff submitted and failed. I've no plan to waste further time on it.

Whee, boring times are over? I miss good old IDE flamewars :)
Let's add Andre in the mix, will be like lithium/hydrogen/fluorine
rocket fuel...

NB: this is a joke. In reality I wish Alan and Bart could
find a way to work together.
--
vda

-
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.11-ac1

[Denis Vlasenko]

On Wednesday 09 March 2005 17:51, Alan Cox wrote:
 On Mer, 2005-03-09 at 07:26, CaT wrote:
   Carried over from 2.6.10-ac
  
  BTW. What's the probability of the ITE driver making it into the stock
  kernel?
 
 I have given up caring about the base kernel IDE code. I've tried to get
 stuff submitted and failed. I've no plan to waste further time on it.

Whee, boring times are over? I miss good old IDE flamewars :)
Let's add Andre in the mix, will be like lithium/hydrogen/fluorine
rocket fuel...

NB: this is a joke. In reality I wish Alan and Bart could
find a way to work together.
--
vda

-
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.11-ac1

[Tupshin Harper]

Alan Cox wrote:
On Mer, 2005-03-09 at 22:22, CaT wrote:
 

Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(
   

Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1 performance is very good and it can do hotplug IDE
transparently in hardware raid modes. Its a good solid little
controller. 

Alan
Alan...since you disagreed with the earlier characterization of what it 
would take to get into the mainline kernels, could you let us know what 
it would take in your opinion? FWIW, I'm happily using it with a -ac kernel.

-Tupshin
-
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.11-ac1

[Alan Cox]

On Iau, 2005-03-10 at 09:06, Tupshin Harper wrote:
 Alan...since you disagreed with the earlier characterization of what it 
 would take to get into the mainline kernels, could you let us know what 
 it would take in your opinion? FWIW, I'm happily using it with a -ac kernel.

It needs some small changes in the base ide-disk code to handle drives
having only a logical geometry (legal but Linux can't cope). Most if not
all the other hooks are there to an extent the driver for the it821x can
work without core code changes. It might be cleaner with core changes
but it's better that the it821x code handles the weirdness of the
hardware.

Longer term it (and probably every other IDE PATA driver) should be
moved to the Jeff Garzik SATA layer. That's also Bart's position I
believe ?

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

x86-64 linux-2.6.11-mm2 - BUG: soft lockup detected on CPU#0! (ohci_hub_resume)

[Sam Elstob]

Just booted 2.6.11-mm2 with a new .config and ran into this BUG().  Here
is the snippet from dmesg.

[   25.088135] ohci_hcd :00:02.0: wakeup
[   25.113120] BUG: soft lockup detected on CPU#0!
[   25.113128]
[   25.113135] Modules linked in: ehci_hcd ohci_hcd usbcore i2c_nforce2
it87 eeprom i2c_sensor i2c_isa i2c_dev i2c_core cpufreq_userspace
powernow_k8 freq_table processor r8169 psmouse forcedeth unix
[   25.113216] Pid: 4, comm: events/0 Not tainted 2.6.11-mm2
[   25.113225] RIP: 0010:[801f7db5] 801f7db5{__delay
+5}
[   25.113240] RSP: :810002145e20  EFLAGS: 0283
[   25.113255] RAX: 0005f88c RBX: 8015e88b RCX:
c355687a
[   25.113265] RDX: 000b RSI: 0001 RDI:
001e5d70
[   25.113274] RBP: 810001d888c8 R08: 0720 R09:
0004
[   25.113284] R10:  R11: 0001 R12:

[   25.113294] R13: 810002144000 R14: c2004000 R15:
81003fed8108
[   25.113305] FS:  2ae00520() GS:80459800()
knlGS:
[   25.113317] CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
[   25.113326] CR2: 005cec28 CR3: 3f31b000 CR4:
06e0
[   25.113335]
[   25.113336] Call Trace:8807f3c4{:ohci_hcd:ohci_hub_resume
+388} 8807f5e5{:ohci_hcd:ohci_rh_resume+21}
[   25.113376]801448c1{worker_thread+497}
8012e180{default_wake_function+0}
[   25.113410]802f96ba{thread_return+118}
8012e180{default_wake_function+0}
[   25.113444]801446d0{worker_thread+0}
80149438{kthread+136}
[   25.113475]8010edeb{child_rip+8}
801446d0{worker_thread+0}
[   25.113507]801493b0{kthread+0}
8010ede3{child_rip+0}
[   25.113538]
[   25.548709] usb 1-4: new full speed USB device using ohci_hcd and
address 2

Attached is the .config.

Sam
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux EvilTwin 2.6.11-mm2 #1 Tue Mar 8 22:56:38 GMT 2005 x86_64 GNU/Linux
 
Gnu C  3.3.5
Gnu make   3.80
binutils   2.15
util-linux 2.12p
mount  2.12p
module-init-tools  3.2-pre1
e2fsprogs  1.36
reiserfsprogs  line
reiser4progs   line
nfs-utils  1.0.7
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.5
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
udev   054
Modules Loaded rfcomm l2cap ipv6 af_packet mousedev evdev floppy rtc 
usbhid usblp hci_usb bluetooth snd_emu10k1 snd_rawmidi snd_seq_device 
snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd 
soundcore ehci_hcd ohci_hcd usbcore i2c_nforce2 it87 eeprom i2c_sensor i2c_isa 
i2c_dev i2c_core cpufreq_userspace powernow_k8 freq_table processor r8169 
psmouse forcedeth unix
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.11-mm2
# Thu Mar 10 16:08:54 2005
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_HPET_TIMER=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y

#
# General setup
#
CONFIG_LOCALVERSION=
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_MK8=y
# CONFIG_MPSC is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_NUMA is not set
CONFIG_GART_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_PHYSICAL_START=0x10
# CONFIG_KEXEC is not set
CONFIG_SECCOMP=y
CONFIG_GENERIC_HARDIRQS=y

Re: Linux 2.6.11-ac1

[Alan Cox]

On Mer, 2005-03-09 at 22:22, CaT wrote:
> Argh! Ok. I guess I shouldn't've just bought the card based on this
> driver then so that I could better debug my problems with my promise
> cards. 8(

Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1 performance is very good and it can do hotplug IDE
transparently in hardware raid modes. Its a good solid little
controller. 

Alan

-
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: a problem with linux 2.6.11 and sa

[Nix]

On Wed, 09 Mar 2005, Paul Jarc uttered the following:
> "George Georgalis" <[EMAIL PROTECTED]> wrote:
>> It (Gerrit Pape's technique) very defiantly stopped working a few revs
>> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
>> mplayer with 2.6.10, now too.
> 
> The /proc/kmsg problem happens because the kernel now checks for
> permission at read() instead of open().

Am I the only person who thinks `eee-ick, how utterly non-POSIX' at
that?

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
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: a problem with linux 2.6.11 and sa

[Paul Jarc]

"George Georgalis" <[EMAIL PROTECTED]> wrote:
> It (Gerrit Pape's technique) very defiantly stopped working a few revs
> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
> mplayer with 2.6.10, now too.

The /proc/kmsg problem happens because the kernel now checks for
permission at read() instead of open().  The /dev/rtc problem seems to
be a different beast.

> while read file; do mplayer $file ; done 
> Failed to open /dev/rtc: Permission denied
>
> for file in `cat mediafiles.txt`; do mplayer $file ; done
>
> works.

To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg < mediafiles.txt

You might try strace'ing both cases and see how they compare.


paul
-
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.11-ac1

[CaT]

On Wed, Mar 09, 2005 at 05:43:02PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Wed, 09 Mar 2005 16:38:43 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
> > > It can be merged if somebody fix it to always force controller into
> > > non-RAID mode and remove RAID mode support (which currently
> > > does nothing more besides complicating the driver and making special
> > > commands unusable).
> > 
> > Incorrect
> 
> Very helpful

Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(

-- 
Red herrings strewn hither and yon.
-
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.11-ac1

[Bartlomiej Zolnierkiewicz]

On Wed, 09 Mar 2005 16:38:43 +, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
> > It can be merged if somebody fix it to always force controller into
> > non-RAID mode and remove RAID mode support (which currently
> > does nothing more besides complicating the driver and making special
> > commands unusable).
> 
> Incorrect

Very helpful
-
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.11-ac1

[Alan Cox]

On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
> It can be merged if somebody fix it to always force controller into
> non-RAID mode and remove RAID mode support (which currently
> does nothing more besides complicating the driver and making special
> commands unusable).

Incorrect

-
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.11-ac1

[Bartlomiej Zolnierkiewicz]

On Wed, 9 Mar 2005 18:26:46 +1100, CaT <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote:
> > For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this
> > diff should actually apply to either right now.
> >
> > 2.6.11-ac1
> > o Fix jbd race in ext3(Stephen Tweedie)
> >
> > Carried over from 2.6.10-ac
> 
> BTW. What's the probability of the ITE driver making it into the stock
> kernel?

It can be merged if somebody fix it to always force controller into
non-RAID mode and remove RAID mode support (which currently
does nothing more besides complicating the driver and making special
commands unusable).
-
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.11-ac1

[Alan Cox]

On Mer, 2005-03-09 at 07:26, CaT wrote:
> > Carried over from 2.6.10-ac
> 
> BTW. What's the probability of the ITE driver making it into the stock
> kernel?

I have given up caring about the base kernel IDE code. I've tried to get
stuff submitted and failed. I've no plan to waste further time on it.

Alan

-
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: a problem with linux 2.6.11 and sa

[George Georgalis]

On Wed, Mar 09, 2005 at 01:06:11PM +, Nix wrote:

>> An interesting technique that allows a program (such as a log writer)
>> to run as an unprivileged user, while receiving privileged data. (taken
>> almost verbatim from Gerrit Pape's socklog)
>> 
>> #!/bin/sh
>> exec > exec 2>&1
>> exec softlimit -m 200 setuidgid nobody socklog ucspi
>> 
>> This script, run by root takes its stdin from /proc/kmsg then combines
>> its stdout and stderr, and exec-switches to the socklog program run
>> as an ucspi application listening to the domain stream socket, as
>> nobody:nogroup, with memory consumption limited to 2Mb. (and sends
>> log to stdout)
>
>This is definitely redirection, not piping. As far as I know the
>implementation of redirection in the kernel remains unchanged: certainly
>the need to buffer piped data doesn't exist in this case, and since the
>redesign was of the buffering, this is probably not your problem :)
>
>> It worked flawlessly until several kernel revs back when the kernel
>> started protecting kmsg and wouldn't allow the user program to receive
>> it,
>
>Indeed.
>
>>   result: nothing sent to the logging program and no error. The fix
>> was to run socklog as root instead of nobody.
>
>You should be able to open it as root and read from it as another user:
>i.e., your technique above shouldn't break. (I'd hope.)

Here is a nice proof that kmsg did become a problem around 2.6.0
http://article.gmane.org/gmane.comp.misc.pape.general/595
http://thread.gmane.org/gmane.comp.misc.pape.general/590


It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.

http://lkml.org/lkml/2005/3/8/226

while read file; do mplayer $file ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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: a problem with linux 2.6.11 and sa

[Nix]

On Tue, 8 Mar 2005, George Georgalis announced authoritatively:
> Here's what I'm doing that is broken. I use tcpserver (functionally
> similar to inetd) to receive an incoming smtp connection. While the
> smtp session is still open, the message is piped to a temp file which
> is then scanned for spam, if it passes the temp file is piped to my

Both of these sound like redirection, not piping.

>>(I don't see what you mean by `a pipe rom /proc/kmsg', though:
>>pipes connect processes, not files. File redirections are
>>quite different and should work unchanged in 2.6.11.)
> 
> An interesting technique that allows a program (such as a log writer)
> to run as an unprivileged user, while receiving privileged data. (taken
> almost verbatim from Gerrit Pape's socklog)
> 
> #!/bin/sh
> exec  exec 2>&1
> exec softlimit -m 200 setuidgid nobody socklog ucspi
> 
> This script, run by root takes its stdin from /proc/kmsg then combines
> its stdout and stderr, and exec-switches to the socklog program run
> as an ucspi application listening to the domain stream socket, as
> nobody:nogroup, with memory consumption limited to 2Mb. (and sends
> log to stdout)

This is definitely redirection, not piping. As far as I know the
implementation of redirection in the kernel remains unchanged: certainly
the need to buffer piped data doesn't exist in this case, and since the
redesign was of the buffering, this is probably not your problem :)

> It worked flawlessly until several kernel revs back when the kernel
> started protecting kmsg and wouldn't allow the user program to receive
> it,

Indeed.

>   result: nothing sent to the logging program and no error. The fix
> was to run socklog as root instead of nobody.

You should be able to open it as root and read from it as another user:
i.e., your technique above shouldn't break. (I'd hope.)

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
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: a problem with linux 2.6.11 and sa

[Nix]

On Tue, 8 Mar 2005, George Georgalis announced authoritatively:
 Here's what I'm doing that is broken. I use tcpserver (functionally
 similar to inetd) to receive an incoming smtp connection. While the
 smtp session is still open, the message is piped to a temp file which
 is then scanned for spam, if it passes the temp file is piped to my

Both of these sound like redirection, not piping.

(I don't see what you mean by `a pipe rom /proc/kmsg', though:
pipes connect processes, not files. File redirections are
quite different and should work unchanged in 2.6.11.)
 
 An interesting technique that allows a program (such as a log writer)
 to run as an unprivileged user, while receiving privileged data. (taken
 almost verbatim from Gerrit Pape's socklog)
 
 #!/bin/sh
 exec /proc/kmsg
 exec 21
 exec softlimit -m 200 setuidgid nobody socklog ucspi
 
 This script, run by root takes its stdin from /proc/kmsg then combines
 its stdout and stderr, and exec-switches to the socklog program run
 as an ucspi application listening to the domain stream socket, as
 nobody:nogroup, with memory consumption limited to 2Mb. (and sends
 log to stdout)

This is definitely redirection, not piping. As far as I know the
implementation of redirection in the kernel remains unchanged: certainly
the need to buffer piped data doesn't exist in this case, and since the
redesign was of the buffering, this is probably not your problem :)

 It worked flawlessly until several kernel revs back when the kernel
 started protecting kmsg and wouldn't allow the user program to receive
 it,

Indeed.

   result: nothing sent to the logging program and no error. The fix
 was to run socklog as root instead of nobody.

You should be able to open it as root and read from it as another user:
i.e., your technique above shouldn't break. (I'd hope.)

-- 
 ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
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: a problem with linux 2.6.11 and sa

[George Georgalis]

On Wed, Mar 09, 2005 at 01:06:11PM +, Nix wrote:

 An interesting technique that allows a program (such as a log writer)
 to run as an unprivileged user, while receiving privileged data. (taken
 almost verbatim from Gerrit Pape's socklog)
 
 #!/bin/sh
 exec /proc/kmsg
 exec 21
 exec softlimit -m 200 setuidgid nobody socklog ucspi
 
 This script, run by root takes its stdin from /proc/kmsg then combines
 its stdout and stderr, and exec-switches to the socklog program run
 as an ucspi application listening to the domain stream socket, as
 nobody:nogroup, with memory consumption limited to 2Mb. (and sends
 log to stdout)

This is definitely redirection, not piping. As far as I know the
implementation of redirection in the kernel remains unchanged: certainly
the need to buffer piped data doesn't exist in this case, and since the
redesign was of the buffering, this is probably not your problem :)

 It worked flawlessly until several kernel revs back when the kernel
 started protecting kmsg and wouldn't allow the user program to receive
 it,

Indeed.

   result: nothing sent to the logging program and no error. The fix
 was to run socklog as root instead of nobody.

You should be able to open it as root and read from it as another user:
i.e., your technique above shouldn't break. (I'd hope.)

Here is a nice proof that kmsg did become a problem around 2.6.0
http://article.gmane.org/gmane.comp.misc.pape.general/595
http://thread.gmane.org/gmane.comp.misc.pape.general/590


It (Gerrit Pape's technique) very defiantly stopped working a few revs
back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
mplayer with 2.6.10, now too.

http://lkml.org/lkml/2005/3/8/226

while read file; do mplayer $file ; done mediafiles.txt

Failed to open /dev/rtc: Permission denied

for file in `cat mediafiles.txt`; do mplayer $file ; done

works.

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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.11-ac1

[Alan Cox]

On Mer, 2005-03-09 at 07:26, CaT wrote:
  Carried over from 2.6.10-ac
 
 BTW. What's the probability of the ITE driver making it into the stock
 kernel?

I have given up caring about the base kernel IDE code. I've tried to get
stuff submitted and failed. I've no plan to waste further time on it.

Alan

-
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.11-ac1

[Bartlomiej Zolnierkiewicz]

On Wed, 9 Mar 2005 18:26:46 +1100, CaT [EMAIL PROTECTED] wrote:
 On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote:
  For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this
  diff should actually apply to either right now.
 
  2.6.11-ac1
  o Fix jbd race in ext3(Stephen Tweedie)
 
  Carried over from 2.6.10-ac
 
 BTW. What's the probability of the ITE driver making it into the stock
 kernel?

It can be merged if somebody fix it to always force controller into
non-RAID mode and remove RAID mode support (which currently
does nothing more besides complicating the driver and making special
commands unusable).
-
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.11-ac1

[Alan Cox]

On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
 It can be merged if somebody fix it to always force controller into
 non-RAID mode and remove RAID mode support (which currently
 does nothing more besides complicating the driver and making special
 commands unusable).

Incorrect

-
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.11-ac1

[Bartlomiej Zolnierkiewicz]

On Wed, 09 Mar 2005 16:38:43 +, Alan Cox [EMAIL PROTECTED] wrote:
 On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
  It can be merged if somebody fix it to always force controller into
  non-RAID mode and remove RAID mode support (which currently
  does nothing more besides complicating the driver and making special
  commands unusable).
 
 Incorrect

Very helpful
-
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.11-ac1

[CaT]

On Wed, Mar 09, 2005 at 05:43:02PM +0100, Bartlomiej Zolnierkiewicz wrote:
 On Wed, 09 Mar 2005 16:38:43 +, Alan Cox [EMAIL PROTECTED] wrote:
  On Mer, 2005-03-09 at 16:26, Bartlomiej Zolnierkiewicz wrote:
   It can be merged if somebody fix it to always force controller into
   non-RAID mode and remove RAID mode support (which currently
   does nothing more besides complicating the driver and making special
   commands unusable).
  
  Incorrect
 
 Very helpful

Argh! Ok. I guess I shouldn't've just bought the card based on this
driver then so that I could better debug my problems with my promise
cards. 8(

-- 
Red herrings strewn hither and yon.
-
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: a problem with linux 2.6.11 and sa

[Paul Jarc]

George Georgalis [EMAIL PROTECTED] wrote:
 It (Gerrit Pape's technique) very defiantly stopped working a few revs
 back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
 mplayer with 2.6.10, now too.

The /proc/kmsg problem happens because the kernel now checks for
permission at read() instead of open().  The /dev/rtc problem seems to
be a different beast.

 while read file; do mplayer $file ; done mediafiles.txt

 Failed to open /dev/rtc: Permission denied

 for file in `cat mediafiles.txt`; do mplayer $file ; done

 works.

To simplify, what about these two:
mplayer foo.mpg
mplayer foo.mpg  mediafiles.txt

You might try strace'ing both cases and see how they compare.


paul
-
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: a problem with linux 2.6.11 and sa

[Nix]

On Wed, 09 Mar 2005, Paul Jarc uttered the following:
 George Georgalis [EMAIL PROTECTED] wrote:
 It (Gerrit Pape's technique) very defiantly stopped working a few revs
 back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and
 mplayer with 2.6.10, now too.
 
 The /proc/kmsg problem happens because the kernel now checks for
 permission at read() instead of open().

Am I the only person who thinks `eee-ick, how utterly non-POSIX' at
that?

-- 
 ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford
-
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.11-ac1

[Alan Cox]

On Mer, 2005-03-09 at 22:22, CaT wrote:
 Argh! Ok. I guess I shouldn't've just bought the card based on this
 driver then so that I could better debug my problems with my promise
 cards. 8(

Its good hardware. It does lots of neat things providing you run -ac
anyway. The raid1 performance is very good and it can do hotplug IDE
transparently in hardware raid modes. Its a good solid little
controller. 

Alan

-
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.11-ac1

[CaT]

On Mon, Mar 07, 2005 at 09:34:22PM +, Alan Cox wrote:
> For a couple of reasons I've not yet merged Greg's 2.6.11.1 yet but this
> diff should actually apply to either right now.
> 
> 2.6.11-ac1
> o Fix jbd race in ext3(Stephen Tweedie)
> 
> Carried over from 2.6.10-ac

BTW. What's the probability of the ITE driver making it into the stock
kernel?

-- 
Red herrings strewn hither and yon.
-
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: a problem with linux 2.6.11 and sa

[Andre Tomt]

George Georgalis wrote:
Here is a problem with 2.6.10:
while read file; do mplayer $file ; done 
or
tail -n93  mediafiles.txt | while read file; do mplayer $file ; done
for each file path in that text file I get:
Failed to open /dev/rtc: Permission denied (it should be readable by the user.)
^- This is also emitted by mplayer. It usually does this on any standard 
system.

In addition the audio pcm level is set to zero (presumably by mplayer).
This does work:
for file in `cat mediafiles.txt`; do mplayer $file ; done
but discovering and fixing code now broke will be unpleasent.
What exactly is going on? 

// George
-
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/

[PATCH] relayfs for linux-2.6.11-mm2

[Tom Zanussi]

Hi Andrew,

Here's the latest version of relayfs, against linux-2.6.11-mm2.  I'm
hoping you'll consider putting this version back into your tree - the
previous rounds of comment seem to have shaken out all the API issues
and the number of comments on the code itself have also steadily
dwindled.

This patch is essentially the same as the relayfs redux part 5 patch,
with some minor changes based on reviewer comments.  Thanks again to
Pekka Enberg for those.  The patch size without documentation is now a
little smaller at just over 40k.  Here's a detailed list of the
changes:

- removed the attribute_flags in relay open and changed it to a
  boolean specifying either overwrite or no-overwrite mode, and removed
  everything referencing the attribute flags.
- added a check for NULL names in relayfs_create_entry()
- got rid of the unnecessary multiple labels in relay_create_buf()
- some minor simplification of relay_alloc_buf() which got rid of a
  couple params
- updated the Documentation

In addition, this version (through code contained in the relay-apps
tarball linked to below, not as part of the relayfs patch) tries to
make it as easy as possible to create the cooperating kernel/user
pieces of a typical and common type of logging application, one where
kernel logging is kicked off when a user space data collection app
starts and stops when the collection app exits, with the data being
automatically logged to disk in between.  To create this type of
application, you basically just include a header file (relay-app.h,
included in the relay-apps tarball) in your kernel module, define a
couple of callbacks and call an initialization function, and on the
user side call a single function that sets up and continuously
monitors the buffers, and writes data to files as it becomes
available.  Channels are created when the collection app is started
and destroyed when it exits, not when the kernel module is inserted,
so different channel buffer sizes can be specified for each separate
run via command-line options.  See the README in the relay-apps
tarball for details.

Also included in the relay-apps tarball are a couple examples
demonstrating how you can use this to create quick and dirty kernel
logging/debugging applications.  They are:

- tprintk, short for 'tee printk', which temporarily puts a kprobe on
  printk() and writes a duplicate stream of printk output to a relayfs
  channel.  This could be used anywhere there's printk() debugging code
  in the kernel which you'd like to exercise, but would rather not have
  your system logs cluttered with debugging junk.  You'd probably want
  to kill klogd while you do this, otherwise there wouldn't be much
  point (since putting a kprobe on printk() doesn't change the output
  of printk()).  I've used this method to temporarily divert the packet
  logging output of the iptables LOG target from the system logs to
  relayfs files instead, for instance.

- klog, which just provides a printk-like formatted logging function
  on top of relayfs.  Again, you can use this to keep stuff out of your
  system logs if used in place of printk.

The example applications can be found here:

http://prdownloads.sourceforge.net/dprobes/relay-apps.tar.gz?download


Thanks,

Tom


Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>

 Documentation/filesystems/relayfs.txt |  206 +
 fs/Kconfig|   12 
 fs/Makefile   |1 
 fs/relayfs/Makefile   |4 
 fs/relayfs/buffers.c  |  195 
 fs/relayfs/buffers.h  |   12 
 fs/relayfs/inode.c|  423 +++
 fs/relayfs/relay.c|  530 ++
 fs/relayfs/relay.h|   12 
 include/linux/relayfs_fs.h|  263 
 10 files changed, 1658 insertions(+)

diff -urpN -X dontdiff linux-2.6.11-mm2/Documentation/filesystems/relayfs.txt 
linux-2.6.11-mm2-cur/Documentation/filesystems/relayfs.txt
--- linux-2.6.11-mm2/Documentation/filesystems/relayfs.txt  1969-12-31 
18:00:00.0 -0600
+++ linux-2.6.11-mm2-cur/Documentation/filesystems/relayfs.txt  2005-03-04 
20:27:34.0 -0600
@@ -0,0 +1,206 @@
+
+relayfs - a high-speed data relay filesystem
+
+
+relayfs is a filesystem designed to provide an efficient mechanism for
+tools and facilities to relay large and potentially sustained streams
+of data from kernel space to user space.
+
+The main abstraction of relayfs is the 'channel'.  A channel consists
+of a set of per-cpu kernel buffers each represented by a file in the
+relayfs filesystem.  Kernel clients write into a channel using
+efficient write functions which automatically log to the current cpu's
+channel buffer.  User space applications mmap() the per-cpu files and
+retrieve the data as it becomes available.
+
+The format of the data logged into the c

Re: a problem with linux 2.6.11 and sa

[George Georgalis]

On Tue, 8 Mar 2005 12:19:53 -0500, George Georgalis <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 11:58:14AM -0500, George Georgalis wrote:
> >On Tue, Mar 08, 2005 at 01:37:03PM +, Nix wrote:
> >>On Thu, 3 Mar 2005, George Georgalis uttered the following:
> >>> I recall a problem a while back with a pipe from
> >>> /proc/kmsg that was sent by root to a program with a
> >>> user uid. The fix was to run the logging program as
> >>> root. Has that protected pipe method been extended
> >>> since 2.6.8.1?
> >>
> >>The entire implementation of pipes has been radically revised between
> >>2.6.10 and 2.6.11: see, e.g.,  and
> >>.
> >>
> >>Bugs have been spotted in this area in 2.6.10: this may be
> >>another one.
> >
> >Thanks, my issue is clearly between 2.6.10 and 2.6.11; though I won't be
> >able to drill down anything more specific, for a while. The links
> >do look relevant but I cannot say for sure.

Here is a problem with 2.6.10:

while read file; do mplayer $file ; done http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
-
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/