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]

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/

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

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

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/

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: 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: 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;
}

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/

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

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

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

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/

Re: a problem with linux 2.6.11 and sa

[George Georgalis]

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.

My last post didn't actually describe what the problem is, which is
spamassassin always scores 0/0 under 2.6.11 but functions properly
(scoring x/5) under 2.6.10.

More details are in the thread of this post.
http://lkml.org/lkml/2005/3/3/513

// 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 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., <http://lwn.net/Articles/118750/> and
><http://lwn.net/Articles/119682/>.
>
>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'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
local delivery program. If it doesn't pass the spam test or the delivery
program fails (disk full etc), the respective error code, if any,
is passed to tcpserver. The corresponding accepted, temporary reject or
permanently reject signal is passed to the remote sender.

The temp file is then removed or, for spam, it is cataloged for
statistics and/or abuse reporting. An additional copy is kept in a
traditional maildir to check for false positives.

#!/bin/bash
# exit 31 = permanently refuse
# exit 71 = temporarily refuse
# pwd is /var/qmail
echo $0 # for the logs
scq="spamc-queue" # a maildir with qmaild write perms
tmp="${scq}/`safecat "${scq}/tmp" "${scq}" >$sipd/date # keep track of when they 
came
maildir "${sipd}" >/dev/null <"$tmp" # keep a copy for reporting
maildir "${scq}"  >/dev/null <"$tmp" # save it to verify no falseys
rm "$tmp"
exit 31
;;
*) # spamc error, 
echo "$0 error, spamc exit $sce"
exit 71
esac
exit 81 # Internal bug



>If you can reproduce it consistently, *please* report
>this to the linux-kernel list!

I did, but have had no response to my followup:

Date: Fri, 4 Mar 2005 15:58:43 -0500
Subject: Re: problem with linux 2.6.11 and sa


>(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 &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)

It worked flawlessly until several kernel revs back when the kernel
started protecting kmsg and wouldn't allow the user program to receive
it, result: nothing sent to the logging program and no error. The fix
was to run socklog as root instead of nobody.

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

[Stephen C. Tweedie]

Hi,

On Tue, 2005-03-08 at 06:49, Chris Wright wrote:

> Yes, we are intending to pick up bits from -ac (you might have missed
> that in another thread).

There's actually a successor patch to that which I'm just about to get
feedback on here and on ext2-devel.  It's higher-risk than the one Alan
has already picked up, but also hopefully closes the race much more
tightly throughout the whole of the jbd layer.

--Stephen


-
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

[Andre Tomt]

Alan Cox wrote:

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
Incomplete list? Seems like there is quite a bit of changes in the diff 
not mentioned "changelog" - HPT, generic ide, ide_dma rename, serio 
"spank" stuff, pci ids

--
Mvh,
André Tomt
-
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

[Clemens Schwaighofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/08/2005 03:49 PM, Chris Wright wrote:
> * Clemens Schwaighofer ([EMAIL PROTECTED]) wrote:
> 
>>>2.6.11-ac1
>>>oFix jbd race in ext3(Stephen Tweedie)
>>
>>will that patch actually appear in 2.6.11.2? At least it looks like a 
>>candidate for me ...
> 
> 
> Yes, we are intending to pick up bits from -ac (you might have missed
> that in another thread).

Probably. I am sorry :) I sort of got lost in the tons of RFD, etc
threads :)

- --
[ Clemens Schwaighofer  -=:~ ]
[ TBWA\ && TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCLUunjBz/yQjBxz8RArh2AJ4oMATN/P+9TPtFEDrGQhu2iox+MQCfZobG
kc+hXDhfKyHhGK7UF6dKw2I=
=CVCH
-END PGP SIGNATURE-
-
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

[Chris Wright]

* Clemens Schwaighofer ([EMAIL PROTECTED]) wrote:
> --On Monday, March 07, 2005 09:34:22 PM + Alan Cox 
> <[EMAIL PROTECTED]> 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
> >oFix jbd race in ext3(Stephen Tweedie)
> 
> will that patch actually appear in 2.6.11.2? At least it looks like a 
> candidate for me ...

Yes, we are intending to pick up bits from -ac (you might have missed
that in another thread).

thanks,
-chris
-- 
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
-
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

[Clemens Schwaighofer]

--On Monday, March 07, 2005 09:34:22 PM + Alan Cox 
<[EMAIL PROTECTED]> 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)
will that patch actually appear in 2.6.11.2? At least it looks like a 
candidate for me ...

[ Clemens Schwaighofer  -=:~ ]
[ TBWA\ && TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]


pgpzmcmZz0gRq.pgp
Description: PGP signature

Re: Linux 2.6.11-ac1

[Indrek Kruusa]

Yes yes yes! It almost seemed that your work on thesis stuff will kill 
-ac :(

Thank you!
Indrek
-
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-ac1

[Alan Cox]

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

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




-
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

[Neil Brown]

On Sunday March 6, [EMAIL PROTECTED] wrote:
> su den 06.03.2005 Klokka 00:19 (+) skreiv J.A. Magallon:
> 
> > static int __init init_nfsd(void)
> > {
> > ...
> > if (proc_mkdir("fs/nfs", NULL)) {
> > struct proc_dir_entry *entry;
> > entry = create_proc_entry("fs/nfs/exports", 0, NULL);
> > if (entry)
> > entry->proc_fops =  &exports_operations;
> > }
> > ...
> > 
> > But nfs-utils 1.0.7 say that you can mount nfsd at /proc/fs/nfsd.
> > What 'exports' would kernel use ? Just duplicate info or a bug ?
> 
> Not sure why /proc/fs/nfs was originally chosen (perhaps Neil
> knows?),

No, before my time.
/proc/fs/nfs/exports has "always" been a file listing the kernels
current understanding of the exports table.
The same information is provided by the "/exports" file in the nfsd
filesystem which (obviously) can be mounted anywhere you like, but
nfs-utils will only work with it if it is mounted on /proc/fs/nfsd
(the preferred location) or /proc/fs/nfs (because for a little while
/proc/fs/nfsd didn't exist).

> but the above code has nothing to do with where you mount the "nfsd"
> filesystem. It is rather part of the legacy support for older versions
> of nfs-utils.
> 
> We should aim to deprecate it at some point soon.

I would like to deprecate the nfssvc system call and /proc/fs/nfs, and
I was planning to do it when 2.7 came out .
Maybe June 2005 would be a good time to mark it 'deprecated' and June
2006 would be a good time to remove it.

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

[Trond Myklebust]

su den 06.03.2005 Klokka 00:19 (+) skreiv J.A. Magallon:

> static int __init init_nfsd(void)
> {
> ...
> if (proc_mkdir("fs/nfs", NULL)) {
> struct proc_dir_entry *entry;
> entry = create_proc_entry("fs/nfs/exports", 0, NULL);
> if (entry)
> entry->proc_fops =  &exports_operations;
> }
> ...
> 
> But nfs-utils 1.0.7 say that you can mount nfsd at /proc/fs/nfsd.
> What 'exports' would kernel use ? Just duplicate info or a bug ?

Not sure why /proc/fs/nfs was originally chosen (perhaps Neil knows?),
but the above code has nothing to do with where you mount the "nfsd"
filesystem. It is rather part of the legacy support for older versions
of nfs-utils.

We should aim to deprecate it at some point soon.

Cheers,
  Trond

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

[J.A. Magallon]

On 03.02, Linus Torvalds wrote:
> 
> Ok,
>  there it is. Only small stuff lately  - as promised. Shortlog from -rc5 
> appended, nothing exciting there, mostly some fixes from various code 
> checkers (like fixed init sections, and some coverity tool finds).
> 
> So it's now _officially_ all bug-free.
> 

Mmm, conflicts in NFS ?

nfsd/nfsctl.c reads:

static int __init init_nfsd(void)
{
...
if (proc_mkdir("fs/nfs", NULL)) {
struct proc_dir_entry *entry;
entry = create_proc_entry("fs/nfs/exports", 0, NULL);
if (entry)
entry->proc_fops =  &exports_operations;
}
...

But nfs-utils 1.0.7 say that you can mount nfsd at /proc/fs/nfsd.
What 'exports' would kernel use ? Just duplicate info or a bug ?

TIA

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Cooker) for i586
Linux 2.6.11-jam1 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #1


-
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 Fri, 4 Mar 2005 13:53:50 -0500, George Georgalis <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Mar 2005 23:37:06 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
> > > 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?
> > >
> > > 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.
> >
> > Does reverting to 2.6.10 fix this behavior?
> 
> Yes, actually I revert to 2.6.8.1; will try 2.6.10 today...

I did make oldconfig (n,n,n) with my 2.6.11 .config
and seems to be working normal. Could
CONFIG_PREEMPT_BKL=y
have anything to do with it?

http://galis.org/linux-2.6.11-sta.config
http://galis.org/linux-2.6.10-sta.conf

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

[George Georgalis]

On Thu, 3 Mar 2005 23:37:06 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
> > 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?
> >
> > 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.
> 
> Does reverting to 2.6.10 fix this behavior?

Yes, actually I revert to 2.6.8.1; will try 2.6.10 today...

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

[Jeff Garzik]

On Thu, Mar 03, 2005 at 01:57:28PM -0500, George Georgalis wrote:
> 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?
> 
> 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.

Does reverting to 2.6.10 fix this behavior?

Jeff



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

problem with linux 2.6.11 and sa

[George Georgalis]

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?

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


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

problem with linux 2.6.11 and sa

[George Georgalis]

Please keep me in cc as I'm not presently subscribed to lkml)

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?


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


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

[Matthias Andree]

Ryan Anderson schrieb am 2005-03-03:

> Is there some reason why
>   bk changes -aem -rv2.6.10..+ | shortlog
> isn't sufficient?

For some reason, this omits some changes, perhaps from sibling branches,
I haven't checked.

A similar change however warrants for a huge speedup of the changelog
script, using bk changes rather than bk prs, without affection output at
all. I have made such a change and committed it to my BK copy, see the
"shortlog" announcement I posted two minutes ago.

-- 
Matthias Andree
-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Dmitry Torokhov]

On Wed, 2 Mar 2005 13:26:18 -0800 (PST), Joshua Hudson
<[EMAIL PROTECTED]> wrote:
> No obvous reason. Works fine with kernel 2.6.10

Does it work with i8042.noacpi kernel boot parameter?

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

[Ryan Anderson]

On Wed, Mar 02, 2005 at 07:46:05AM -0800, Linus Torvalds wrote:
> (In contrast the full ChangeLog was missing because the generation script
> I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 
> or worse, so the log from the last -rc release is fast, but going back all 
> the way to 2.6.10 took long long enough that I didn't wait for it).

Is there some reason why
bk changes -aem -rv2.6.10..+ | shortlog
isn't sufficient?

I'd guess your script will want to calculate the 2.6.10 part
automatically, but that seems to run in a second or so on my machine,
from a largely cold cache.  I *think* this gets all the changes where a
-d (date) based method gets very confused by parallel trees.  Am I
missing something?

-- 

Ryan Anderson
  sometimes Pug Majere
-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Marcus Furlong]

Joshua Hudson wrote:

> No obvous reason. Works fine with kernel 2.6.10
> 
> Result of lspci:
> 00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
> 00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control
> Registers (rev 02)
> 00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration
> Process Registers (rev 02)
> 00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated
> Graphics Device (rev 02)
> 00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics
> Device (rev 02)
> 00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 01)
> 00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 01)
> 00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 01)
> 00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller
> (rev 01)
> 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81)
> 00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
> 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
> Controller (rev 01)
> 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97
> Audio Controller (rev 01)
> 00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 01)
> 02:01.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev
> 01)
> 02:02.0 Network controller: Broadcom Corporation: Unknown device 4324 (rev
> 03)
> 02:04.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus
> Controller
> 

ditto with Inspiron 5150

lspci:
:00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
:00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
:00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to I/O Controller (rev 02)
:00:01.0 PCI bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV
Processor to AGP Controller (rev 02)
:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M)
USB2 EHCI Controller (rev 01)
:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
:00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface
Bridge (rev 01)
:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE
Controller (rev 01)
:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
:01:00.0 VGA compatible controller: nVidia Corporation NV34M [GeForce FX
Go 5200] (rev a1)
:02:01.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T
(rev 01)
:02:04.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus
Controller (rev 02)
:02:04.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394
Controller


-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Dmitry Torokhov]

On Wednesday 02 March 2005 23:02, Joshua Hudson wrote:
> ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
> ACPI: PS/2 Mouse Controller [PS2M] at irq 12
> i8042.c: Can't read CTR while initializing i8042.

Ok, your BIOS is also reporting incorrect port values for the keyboard
controller, it should be 0x60, 0x64. You'll have to use i8042.noacpi
for now.

Thank you for the log.

-- 
Dmitry
-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Joshua Hudson]

PCI: Using ACPI for IRQ routing
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
ACPI: Video Device [VID2] (multi-head: yes  rom: no  post: no)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THM] (59 C)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI interrupt :00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
i8042.c: Can't read CTR while initializing i8042.
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
ACPI: PCI interrupt :00:1f.6[B] -> GSI 7 (level, low) -> IRQ 7
ACPI: PCI interrupt :02:01.0[A] -> GSI 7 (level, low) -> IRQ 7
ACPI: PCI interrupt :00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt :02:04.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11
ACPI: PCI interrupt :00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt :00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
ACPI: PCI interrupt :00:1d.1[B] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI interrupt :00:1d.2[C] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt :00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7
ACPI wakeup devices:
ACPI: (supports S0 S1 S3 S4 S4bios S5)

More like it, hmmm?

-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Joshua Hudson]

On Wed, 2 Mar 2005, Dmitry Torokhov wrote:

> On Wed, 2 Mar 2005 13:26:18 -0800 (PST), Joshua Hudson
> <[EMAIL PROTECTED]> wrote:
> > No obvous reason. Works fine with kernel 2.6.10
>
> Does it work with i8042.noacpi kernel boot parameter?
>
Yes, it does. I never heard of that option before, or any
one like it.

-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Dmitry Torokhov]

On Wednesday 02 March 2005 21:01, Joshua Hudson wrote:
> 
> On Wed, 2 Mar 2005, Dmitry Torokhov wrote:
> 
> > On Wed, 2 Mar 2005 13:26:18 -0800 (PST), Joshua Hudson
> > <[EMAIL PROTECTED]> wrote:
> > > No obvous reason. Works fine with kernel 2.6.10
> >
> > Does it work with i8042.noacpi kernel boot parameter?
> >
> Yes, it does. I never heard of that option before, or any
> one like it.

It is a new one.

Btw, when it boots _without_ this option is there any messages from
i8042 or ACPI? 

-- 
Dmitry
-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Dmitry Torokhov]

On Wednesday 02 March 2005 21:27, Joshua Hudson wrote:
> i8042: ACPI detection disabled
> i8042.c: Warning: Keylock active.

I really need dmesg when booting _without_ the option, i.e. non-working case.

Thanks!

-- 
Dmitry
-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Joshua Hudson]

Relevent messages (erring on the heavy side)

ACPI: RSDP (v000 DELL  ) @ 0x000fdf00
ACPI: RSDT (v001 DELLCPi R   0x27d4061d ASL  0x0061) @ 0x1fef
ACPI: FADT (v001 DELLCPi R   0x27d4061d ASL  0x0061) @ 0x1fef0400
ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 MSFT 0x010e) @ 0x
ACPI: PM-Timer IO Port: 0x808
...
ACPI: Subsystem revision 20050211
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller :00:1f.1
PCI: Transparent bridge - :00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11
ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
...
i8k: unable to get SMM Dell signature
i8k: unable to get SMM BIOS version
...
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to [EMAIL PROTECTED]
** so I can fix the driver.
...
apm: BIOS not found.
NTFS driver 2.1.22 [Flags: R/W].
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
ACPI: Video Device [VID2] (multi-head: yes  rom: no  post: no)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THM] (56 C)
...
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt :00:02.0[A] -> GSI 11 (level, low) -> IRQ 11
...
i8042: ACPI detection disabled
i8042.c: Warning: Keylock active.
...
i8042: ACPI detection disabled
i8042.c: Warning: Keylock active.
...
ACPI: PCI interrupt :02:01.0[A] -> GSI 7 (level, low) -> IRQ 7




-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Joshua Hudson]

> > > Does it work with i8042.noacpi kernel boot parameter?
> > >
> > Yes, it does.
> Btw, when it boots _without_ this option is there any messages from
> i8042 or ACPI?
>
A few. I'll go back and catch them for you.


-
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

[Jan Dittmer]

Linus Torvalds wrote:
> Ok,
>  there it is. Only small stuff lately  - as promised. Shortlog from -rc5 
> appended, nothing exciting there, mostly some fixes from various code 
> checkers (like fixed init sections, and some coverity tool finds).
> 
> So it's now _officially_ all bug-free.

At least it builds 14 out of 23 arch defconfigs (http://l4x.org/k/),
which is quite an improvement over 10/22 of 2.6.10.

Congrats,

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

[Herbert Poetzl]

On Wed, Mar 02, 2005 at 05:06:36PM +0300, Michael Tokarev wrote:
> Herbert Poetzl wrote:
> []
> >BUG_ON() and friends are still broken (at least on x86)
> []
> >Freeing unused kernel memory: 244k freed
> >[ cut here ]
> >kernel BUG at :9377!
> >   ~~~
> 
> Have you tried compiling with CONFIG_DEBUG_INFO=y ?
> (Looks like CONFIG_DEBUG_BUGVERBOSE should either
> depend on CONFIG_DEBUG_INFO or turn it on).

egrep 'CONFIG_DEBUG_(INFO|BUGVERBOSE)' .config
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO=y

good point, just it seems to be the other way round ..

with CONFIG_DEBUG_BUGVERBOSE set I get the correct
file and line, but no stack information ...

Freeing unused kernel memory: 104k freed
[ cut here ]
kernel BUG at init/main.c:692!
invalid operand:  [#1]
PREEMPT 
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 0246   (2.6.11-rc1) 
eax:    ebx: c01002b0   ecx:    edx: 
esi:    edi:    ebp:    esp: c10bdff0
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=c10bc000 task=c10b3aa0)
Stack: c0100635    
Call Trace:
 []
Code: 29 c0 01 00 00 00 6a 00 6a 02 68 97 0a 24 c0 e8 47 07 06 00 83 c4 0c 85 
c0 78 60 6a 00 e8 a9 80 07 00 6a 00 e8 a2 80 07 00 58 5a <0f> 0b b4 02 13 0a 24 
c0 a1 24 21 29 c0 85 c0 75 32 68 a4 0a 24 

maybe there is another option which sneaked in,
will investigate ...

thanks,
Herbert

PS: was it ever considered to hard code the explicit BUG_*
files and lines via a macro instead of that (probably very
fancy and efficient but nevertheless) strange address stuff?

I mean, are bug reports with missing/wrong file/line info
really what the kernel developers want to see in the future?

> /mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150 (and 5150)

[Dmitry Torokhov]

On Wed, 02 Mar 2005 23:16:43 +, Marcus Furlong <[EMAIL PROTECTED]> wrote:
> Here's the diff of dmesgs between 2.6.10 and 2.6.11
> 
> 2.6.10
> >i8042.c: Warning: Keylock active.
> >serio: i8042 AUX port at 0x60,0x64 irq 12
> >serio: i8042 KBD port at 0x60,0x64 irq 1
> 
> 2.6.11
> < ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
> < ACPI: PS/2 Mouse Controller [PS2M] at irq 12
> < i8042.c: Can't read CTR while initializing i8042.
> 

Your BIOS reports incorrect ports for the keyboard controller, should
be 0x60, 0x64. You will have to boot with i8042.noacpi for now.

-- 
Dmitry

-- Is there anything else I can contribute?
-- The latitude and longtitude of the bios writers current
position, and a ballistic missile. (Alan Cox)
-
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: Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150 (and 5150)

[Marcus Furlong]

Here's the diff of dmesgs between 2.6.10 and 2.6.11
2.6.10
i8042.c: Warning: Keylock active.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
2.6.11
< ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
< ACPI: PS/2 Mouse Controller [PS2M] at irq 12
< i8042.c: Can't read CTR while initializing i8042.
booting with i8042.debug=1 gives:
ACPI: PS/2 Keyboard Controller [KBC] at I/O 0x60, 0x66, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
drivers/input/serio/i8042.c: 20 -> i8042 (command) [0]
drivers/input/serio/i8042.c:  -- i8042 (timeout) [508]
i8042.c: Can't read CTR while initializing i8042.
workaround is to boot with i8042.noacpi=1
i8042: ACPI detection disabled
i8042.c: Warning: Keylock active.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
_
Get almost unlimited e-mail storage - upgrade to Hotmail Plus! 
http://www.imagine-msn.com/hotmail/en-ie

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

Bug report -- keyboard not working Linux 2.6.11 on Inspiron 1150

[Joshua Hudson]

No obvous reason. Works fine with kernel 2.6.10

Result of lspci:
00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control
Registers (rev 02)
00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration
Process Registers (rev 02)
00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics
Device (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 01)
00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 01)
00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 01)
00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller
(rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97
Audio Controller (rev 01)
00:1f.6 Modem: Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 01)
02:01.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev
01)
02:02.0 Network controller: Broadcom Corporation: Unknown device 4324 (rev
03)
02:04.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus
Controller



Diff of .config between 2.6.10 & 2.6.11

--- linux-2.6.10/.config2005-02-19 18:33:49.00000 -0800
+++ linux-2.6.11/.config2005-03-02 12:11:54.0 -0800
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.10
-# Sat Feb 19 17:34:02 2005
+# Linux kernel version: 2.6.11
+# Wed Mar  2 12:11:54 2005
 #
 CONFIG_X86=y
 CONFIG_MMU=y
@@ -92,6 +92,7 @@
 CONFIG_X86_XADD=y
 CONFIG_X86_L1_CACHE_SHIFT=7
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
 CONFIG_X86_WP_WORKS_OK=y
 CONFIG_X86_INVLPG=y
 CONFIG_X86_BSWAP=y
@@ -102,6 +103,7 @@
 # CONFIG_HPET_TIMER is not set
 # CONFIG_SMP is not set
 CONFIG_PREEMPT=y
+CONFIG_PREEMPT_BKL=y
 # CONFIG_X86_UP_APIC is not set
 CONFIG_X86_TSC=y
 CONFIG_X86_MCE=y
@@ -158,6 +160,7 @@
 CONFIG_ACPI_PCI=y
 CONFIG_ACPI_SYSTEM=y
 CONFIG_X86_PM_TIMER=y
+# CONFIG_ACPI_CONTAINER is not set

 #
 # APM (Advanced Power Management) BIOS Support
@@ -176,7 +179,8 @@
 #
 CONFIG_CPU_FREQ=y
 # CONFIG_CPU_FREQ_DEBUG is not set
-# CONFIG_CPU_FREQ_PROC_INTF is not set
+CONFIG_CPU_FREQ_STAT=y
+# CONFIG_CPU_FREQ_STAT_DETAILS is not set
 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
 # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
 CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
@@ -216,6 +220,7 @@
 CONFIG_PCI_BIOS=y
 CONFIG_PCI_DIRECT=y
 CONFIG_PCI_MMCONFIG=y
+# CONFIG_PCIEPORTBUS is not set
 CONFIG_PCI_LEGACY_PROC=y
 CONFIG_PCI_NAMES=y
 # CONFIG_ISA is not set
@@ -227,7 +232,6 @@
 #
 CONFIG_PCCARD=y
 CONFIG_PCMCIA_DEBUG=y
-CONFIG_PCMCIA_OBSOLETE=y
 CONFIG_PCMCIA=y
 CONFIG_CARDBUS=y

@@ -238,6 +242,7 @@
 CONFIG_PD6729=y
 CONFIG_I82092=y
 CONFIG_TCIC=y
+CONFIG_PCCARD_NONSTATIC=y

 #
 # PCI Hotplug Support
@@ -291,6 +296,7 @@
 # CONFIG_BLK_CPQ_CISS_DA is not set
 # CONFIG_BLK_DEV_DAC960 is not set
 # CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
 CONFIG_BLK_DEV_LOOP=y
 # CONFIG_BLK_DEV_CRYPTOLOOP is not set
 # CONFIG_BLK_DEV_NBD is not set
@@ -313,6 +319,7 @@
 CONFIG_IOSCHED_AS=y
 CONFIG_IOSCHED_DEADLINE=y
 CONFIG_IOSCHED_CFQ=y
+# CONFIG_ATA_OVER_ETH is not set

 #
 # ATA/ATAPI/MFM/RLL support
@@ -406,6 +413,7 @@
 #
 # CONFIG_SCSI_SPI_ATTRS is not set
 # CONFIG_SCSI_FC_ATTRS is not set
+# CONFIG_SCSI_ISCSI_ATTRS is not set

 #
 # SCSI low-level drivers
@@ -426,6 +434,7 @@
 CONFIG_SCSI_ATA_PIIX=y
 # CONFIG_SCSI_SATA_NV is not set
 # CONFIG_SCSI_SATA_PROMISE is not set
+# CONFIG_SCSI_SATA_QSTOR is not set
 CONFIG_SCSI_SATA_SX4=m
 # CONFIG_SCSI_SATA_SIL is not set
 CONFIG_SCSI_SATA_SIS=m
@@ -454,7 +463,6 @@
 # CONFIG_SCSI_QLA2300 is not set
 # CONFIG_SCSI_QLA2322 is not set
 # CONFIG_SCSI_QLA6312 is not set
-# CONFIG_SCSI_QLA6322 is not set
 # CONFIG_SCSI_DC395x is not set
 # CONFIG_SCSI_DC390T is not set
 # CONFIG_SCSI_NSP32 is not set
@@ -579,7 +587,6 @@
 CONFIG_IP_NF_TARGET_REDIRECT=y
 CONFIG_IP_NF_TARGET_NETMAP=y
 CONFIG_IP_NF_TARGET_SAME=y
-# CONFIG_IP_NF_NAT_LOCAL is not set
 # CONFIG_IP_NF_NAT_SNMP_BASIC is not set
 CONFIG_IP_NF_MANGLE=y
 CONFIG_IP_NF_TARGET_TOS=y
@@ -798,6 +805,7 @@
 # CONFIG_SERIO_SERPORT is not set
 # CONFIG_SERIO_CT82C710 is not set
 CONFIG_SERIO_PCIPS2=y
+CONFIG_SERIO_LIBPS2=y
 # CONFIG_SERIO_RAW is not set

 #
@@ -968,6 +976,7 @@
 CONFIG_LOGO_LINUX_MONO=y
 CONFIG_LOGO_LINUX_VGA16=y
 CONFIG_LOGO_LINUX_CLUT224=y
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

 #
 # Sound
@@ -986,7 +995,7 @@
 CONFIG_SND_MIXER_OSS=y
 CONFIG_SND_PCM_OSS=y
 CONFIG_SND_SEQUENCER_OSS=y
-# CONFIG_SND_RTCTIMER is not set
+CONFIG_SND_RTCTIMER=y
 # CONFIG_SND_VERBOSE_PRINTK is not set
 # 

Re: Linux 2.6.11

[Linus Torvalds]

On Wed, 2 Mar 2005, Matthias Andree wrote:
> 
> Is the master side a hidden host rather than ftp.kernel.org?

Yes. The private keys etc used to generate the signatures are not on the
public sites, which is what I assume your question _really_ is.

> > (In contrast the full ChangeLog was missing because the generation script
> > I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 
> > or worse, so the log from the last -rc release is fast, but going back all 
> > the way to 2.6.10 took long long enough that I didn't wait for it).
> 
> If that is an issue with the shortlog script or its integration with BK,
> contact me off-list so we can resolve the issue.

No, it's just my stupid release script.

Linus
-
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 jiffies.h uses shadowed variable names.

[linux-os]

The attached patch was sent for 2.6.10 but the kernel was
never updated. The kernel used to be compiled with -Wshadow
and would catch these problems. It no longer is (and it
should be).
I attached it so the M$ mail-sender doesn't dork with
white-space.
Signed Off By: [EMAIL PROTECTED]
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.--- linux-2.6.11/include/linux/jiffies.h.orig   2005-03-02 11:29:27.0 
-0500
+++ linux-2.6.11/include/linux/jiffies.h2005-03-02 11:36:05.0 
-0500
@@ -328,13 +328,13 @@
 }
 
 static __inline__ void
-jiffies_to_timespec(const unsigned long jiffies, struct timespec *value)
+jiffies_to_timespec(const unsigned long jif, struct timespec *value)
 {
/*
 * Convert jiffies to nanoseconds and separate with
 * one divide.
 */
-   u64 nsec = (u64)jiffies * TICK_NSEC;
+   u64 nsec = (u64)jif * TICK_NSEC;
value->tv_sec = div_long_long_rem(nsec, NSEC_PER_SEC, &value->tv_nsec);
 }
 
@@ -366,13 +366,13 @@
 }
 
 static __inline__ void
-jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
+jiffies_to_timeval(const unsigned long jif, struct timeval *value)
 {
/*
 * Convert jiffies to nanoseconds and separate with
 * one divide.
 */
-   u64 nsec = (u64)jiffies * TICK_NSEC;
+   u64 nsec = (u64)jif * TICK_NSEC;
value->tv_sec = div_long_long_rem(nsec, NSEC_PER_SEC, &value->tv_usec);
value->tv_usec /= NSEC_PER_USEC;
 }

Re: Linux 2.6.11

[Matthias Andree]

On Wed, 02 Mar 2005, Linus Torvalds wrote:

> On Wed, 2 Mar 2005, Matthias Andree wrote:
> > 
> > ftp.kernel.org:/pub/linux/kernel/v2.6 doesn't seem to carry a crypto
> > signature for the patch, patch-2.6.11.gz.sign
> 
> It's there now (along with the ChangeLog).

> The signatures are automatically generated at the master site, and the 
> mirroring out to the public sites is a separate event, so sometimes (if 
> you check early) you may miss the signatures for a while until the next 
> time the scripts run.

Is the master side a hidden host rather than ftp.kernel.org?

> (In contrast the full ChangeLog was missing because the generation script
> I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 
> or worse, so the log from the last -rc release is fast, but going back all 
> the way to 2.6.10 took long long enough that I didn't wait for it).

If that is an issue with the shortlog script or its integration with BK,
contact me off-list so we can resolve the issue.

Thanks,

-- 
Matthias Andree
-
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

[John Cherry]

Linux 2.6 Compile Statistics (gcc 3.4.1)

Web page with links to complete details:
   http://developer.osdl.org/cherry/compile/

Kernel bzImagebzImage  bzImage  modules  bzImage   modules
 (defconfig)  (allno)  (allyes) (allyes) (allmod) (allmod)
---  ---      -
2.6.1113w/0e   0w/0e   352w/0e6w/0e  17w/0e431w/0e
2.6.11-rc514w/0e   0w/0e   353w/0e6w/0e  18w/0e431w/0e
2.6.11-rc414w/0e   0w/0e   353w/0e6w/0e  18w/0e431w/0e
2.6.11-rc314w/0e   0w/0e   356w/0e6w/0e  18w/0e435w/0e
2.6.11-rc313w/0e   0w/0e   356w/0e6w/0e  18w/0e435w/0e
2.6.11-rc218w/0e   0w/0e   365w/0e6w/0e  22w/0e440w/0e
2.6.11-rc120w/0e   0w/0e   497w/0e6w/0e  22w/0e577w/0e
2.6.1013w/0e   0w/0e   778w/0e6w/0e  15w/0e861w/0e
2.6.9-rc3 13w/0e   0w/0e   774w/0e6w/0e  15w/0e857w/0e
2.6.9-rc2 14w/0e   0w/0e  1815w/11e  65w/0e  19w/0e   2157w/0e
(Compiles with gcc 3.2.2)
2.6.9-rc1  5w/0e   1w/0e  1069w/15e   6w/0e   4w/0e   1062w/1e
2.6.9  0w/0e   0w/0e  1930w/0e   41w/0e  11w/0e   1950w/0e
2.6.9-final0w/0e   0w/0e  1930w/0e   41w/0e  11w/0e   1950w/0e
2.6.9-rc4  0w/0e   0w/0e  1930w/0e   41w/0e  11w/0e   1950w/0e
2.6.9-rc3  0w/0e   0w/0e  2752w/17e  41w/0e  11w/0e   2782w/5e
2.6.9-rc2  0w/0e   0w/0e  3036w/0e   41w/0e  11w/0e   3655w/0e
2.6.9-rc1  0w/0e   0w/0e77w/10e   4w/0e   3w/0e 68w/0e
2.6.8.10w/0e   0w/0e78w/ 0e   4w/0e   1w/0e 72w/0e
2.6.8  0w/0e   0w/0e78w/ 0e   4w/0e   1w/0e 72w/0e
2.6.8-rc4  0w/0e   0w/0e78w/ 0e   4w/0e   1w/0e 72w/0e
2.6.8-rc3  0w/0e   0w/0e78w/ 0e   4w/0e   1w/0e 72w/0e
2.6.8-rc2  0w/0e   0w/0e85w/ 0e   5w/0e   1w/0e 79w/0e
2.6.8-rc1  0w/0e   0w/0e87w/ 0e   5w/0e   1w/0e 82w/0e
2.6.7  0w/0e   0w/0e   108w/ 0e   5w/0e   2w/0e102w/0e
2.6.7-rc3  0w/0e   0w/0e   108w/ 0e   5w/0e   2w/0e104w/0e
2.6.7-rc2  0w/0e   0w/0e   110w/ 0e   5w/0e   2w/0e106w/0e
2.6.7-rc1  0w/0e   0w/0e   111w/ 0e   6w/0e   2w/0e107w/0e
2.6.6  0w/0e   0w/0e   123w/ 0e   7w/0e   4w/0e121w/0e
2.6.6-rc3  0w/0e   0w/0e   124w/ 0e   7w/0e   5w/0e121w/0e
2.6.6-rc2  0w/0e   0w/0e   122w/ 0e   7w/0e   4w/0e121w/0e
2.6.6-rc1  0w/0e   0w/0e   125w/ 0e   7w/0e   4w/0e123w/0e
2.6.5  0w/0e   0w/0e   134w/ 0e   8w/0e   4w/0e132w/0e
2.6.5-rc3  0w/0e   0w/0e   135w/ 0e   8w/0e   4w/0e132w/0e
2.6.5-rc2  0w/0e   0w/0e   135w/ 0e   8w/0e   3w/0e132w/0e
2.6.5-rc1  0w/0e   0w/0e   138w/ 0e   8w/0e   3w/0e135w/0e
2.6.4  1w/0e   0w/0e   145w/ 0e   7w/0e   3w/0e142w/0e
2.6.4-rc2  1w/0e   0w/0e   148w/ 0e   7w/0e   3w/0e145w/0e
2.6.4-rc1  1w/0e   0w/0e   148w/ 0e   7w/0e   3w/0e145w/0e
2.6.3  1w/0e   0w/0e   142w/ 0e   9w/0e   3w/0e142w/0e
2.6.3-rc4  1w/0e   0w/0e   142w/ 0e   9w/0e   3w/0e142w/0e
2.6.3-rc3  1w/0e   0w/0e   145w/ 7e   9w/0e   3w/0e148w/0e
2.6.3-rc2  1w/0e   0w/0e   141w/ 0e   9w/0e   3w/0e144w/0e
2.6.3-rc1  1w/0e   0w/0e   145w/ 0e   9w/0e   3w/0e177w/0e
2.6.2  1w/0e   0w/0e   152w/ 0e  12w/0e   3w/0e187w/0e
2.6.2-rc3  0w/0e   0w/0e   152w/ 0e  12w/0e   3w/0e187w/0e
2.6.2-rc2  0w/0e   0w/0e   153w/ 8e  12w/0e   3w/0e188w/0e
2.6.2-rc1  0w/0e   0w/0e   152w/ 0e  12w/0e   3w/0e187w/0e
2.6.1  0w/0e   0w/0e   158w/ 0e  12w/0e   3w/0e197w/0e
2.6.1-rc3  0w/0e   0w/0e   158w/ 0e  12w/0e   3w/0e197w/0e
2.6.1-rc2  0w/0e   0w/0e   166w/ 0e  12w/0e   3w/0e205w/0e
2.6.1-rc1  0w/0e   0w/0e   167w/ 0e  12w/0e   3w/0e206w/0e
2.6.0  0w/0e   0w/0e   170w/ 0e  12w/0e   3w/0e209w/0e

Daily compiles (ia32): 
   http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Latest changes in Linus' bitkeeper tree:
   http://linux.bkbits.net:8080/linux-2.5

John



-
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

[Linus Torvalds]

On Wed, 2 Mar 2005, Matthias Andree wrote:
> 
> ftp.kernel.org:/pub/linux/kernel/v2.6 doesn't seem to carry a crypto
> signature for the patch, patch-2.6.11.gz.sign

It's there now (along with the ChangeLog).

The signatures are automatically generated at the master site, and the 
mirroring out to the public sites is a separate event, so sometimes (if 
you check early) you may miss the signatures for a while until the next 
time the scripts run.

The same is true of the .bz2 files, btw (I only upload the .gz ones, the 
rest is generated). And obviously the incremental patches.

(In contrast the full ChangeLog was missing because the generation script
I use is not exactly the smart way, so it's O(slow(n)), where slow is n**3 
or worse, so the log from the last -rc release is fast, but going back all 
the way to 2.6.10 took long long enough that I didn't wait for it).

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

[Michael Tokarev]

Herbert Poetzl wrote:
[]
BUG_ON() and friends are still broken (at least on x86)
[]
Freeing unused kernel memory: 244k freed
[ cut here ]
kernel BUG at :9377!
  ~~~
Have you tried compiling with CONFIG_DEBUG_INFO=y ?
(Looks like CONFIG_DEBUG_BUGVERBOSE should either
depend on CONFIG_DEBUG_INFO or turn it on).
/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.11

[Herbert Poetzl]

On Wed, Mar 02, 2005 at 12:02:03AM -0800, Linus Torvalds wrote:
> 
> Ok,
>  there it is. Only small stuff lately  - as promised. Shortlog from -rc5 
> appended, nothing exciting there, mostly some fixes from various code 
> checkers (like fixed init sections, and some coverity tool finds).
> 
> So it's now _officially_ all bug-free.

BUG_ON() and friends are still broken (at least on x86)

the following 'patch':

--- ./init/main.c.orig  Thu Feb 17 19:25:21 2005
+++ ./init/main.c   Sun Feb 27 05:13:45 2005
@@ -684,6 +684,8 @@ static int init(void * unused)
 * trying to recover a really broken machine.
 */

+   BUG_ON(0==0);
+
if (execute_command)
run_init_process(execute_command);


results in this oops:
(look at the filename and linenumber ;)

Freeing unused kernel memory: 244k freed
[ cut here ]
kernel BUG at :9377!
  ~~~

best,
Herbert

>   Linus
> 
> 
> Summary of changes from v2.6.11-rc5 to v2.6.11
> 
> 
> :
>   o [SERIAL] drivers/serial/*: convert to pci_register_driver
> 
> :
>   o prism54 not releasing region
> 
> Alex Williamson:
>   o [SERIAL] 8250 woraround for buggy uart
> 
> Alexander Nyberg:
>   o SELinux: Leak in error path
>   o SELinux: null dereference in error path
> 
> Andrea Arcangeli:
>   o Make the new merged pipe writes check for SIGPIPE
> 
> Andrew Morton:
>   o binfmt_elf build fix
>   o [IA64] ia64 audit build fix
>   o genhd: NULL checking fix
> 
> Andries E. Brouwer:
>   o __devinitdata in parport_pc
>   o __init in cfq-iosched.c
>   o remove __initdata in scsi_devinfo.c
>   o __initdata in apic.c
>   o more apic.c
> 
> Aurelien Jarno:
>   o USB: Fix usbfs regression
> 
> Bartlomiej Zolnierkiewicz:
>   o [ide] fix build for built-in hpt366 and modular ide-disk
>   o [ide] fix IRQ masking in ide_do_request()
> 
> Ben Dooks:
>   o [ARM PATCH] 2498/1: CREDITS - add Ben Dooks
>   o [ARM PATCH] 2505/1: Remove FTVPCI from debug code
> 
> Bjorn Helgaas:
>   o [SERIAL] discover PNP ports before PCI, etc
>   o [SERIAL] add TP560 data/fax/modem support
> 
> Chris Wright:
>   o fix audit inode filter
>   o send audit reply to correct socket
> 
> David Gibson:
>   o ppc64: hugepage hash flushing bugfix
> 
> David Howells:
>   o Make keyctl(KEYCTL_JOIN_SESSION_KEYRING) use the correct arg
> 
> David S. Miller:
>   o [IPV4]: Fix lost routes in fn_hash netlink dumps
>   o [AF_UNIX]: Fix SIOCINQ for STREAM and SEQPACKET
> 
> Dmitry Torokhov:
>   o Input: add more PNP IDs to i8042 driver
> 
> Greg Kroah-Hartman:
>   o sysfs: fix signedness problem
>   o fix module paramater permissions in radeon_base.c
>   o USB: fix bug in acm's open function
> 
> Harald Welte:
>   o [NETFILTER]: ipt_hashlimit rule load time race condition
> 
> Hideaki Yoshifuji:
>   o add sysctl helper functions to provide milliseconds-based
> interfaces
>   o [IPV4] Use appropriate sysctl helpers for gc_min_interval_ms
>   o [IPV6]: Unregister per-device snmp6 proc entry earlier
> 
> Jens Axboe:
>   o [PATCH] Fix bounced bio and dm panic
> 
> Kenji Kaneshige:
>   o [IA64] pci_irq.c: need signed variable to handle error return from
> acpi
> 
> Linus Torvalds:
>   o Fix possible pty line discipline race
>   o Properly limit keyboard keycodes to KEY_MAX
>   o Make pipe "poll()" take direction of pipe into account
>   o Linux 2.6.11
> 
> Nishanth Aravamudan:
>   o [PKTGEN]: Replace interruptible_sleep_on_timeout()
> 
> Olaf Hering:
>   o Fix incorrect __init on 'modedb[]' array
> 
> Patrick McHardy:
>   o [NETFILTER]: Prevent NAT from seeing fragments
> 
> Randy Dunlap:
>   o [ide] make 1-bit fields unsigned
>   o srat: initdata section references
>   o sound/oss/aedsp16: init/exit section cleanups
>   o sonicvibes: fix initdata references
>   o sound/oss/opl3as2: fix init section reference
>   o isdn: use __init for ICCVersion()
>   o dc395x: fix section references
>   o hp100: fix section references
>   o rrunner: fix section references
> 
> Robert Olsson:
>   o [PKTGEN]: reduce stack usage
> 
> Russell King:
>   o [ARM] Fix dma_mmap() size argument
> 
> Sascha Hauer:
>   o [ARM PATCH] 2496/1: i.MX DMA fix
>   o [ARM PATCH] 2497/1: i.MX pll decode
> 
> -
> 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/
-
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

[Jesper Juhl]

On Wed, 2 Mar 2005, Matthias Andree wrote:

> On Wed, 02 Mar 2005, Linus Torvalds wrote:
> 
> >  there it is. Only small stuff lately  - as promised. Shortlog from -rc5 
> > appended, nothing exciting there, mostly some fixes from various code 
> > checkers (like fixed init sections, and some coverity tool finds).
> 
> ftp.kernel.org:/pub/linux/kernel/v2.6 doesn't seem to carry a crypto
> signature for the patch, patch-2.6.11.gz.sign

The full 2.6.10 -> 2.6.11 Changelog also seems to be missing, but I guess 
I'm just impatient :)

Congrats on the new release, can't wait to try it out. 2.6.11-rc has been 
working great, I have high hopes for this one :) Good work!

--
Jesper Juhl


-
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

[Matthias Andree]

On Wed, 02 Mar 2005, Linus Torvalds wrote:

>  there it is. Only small stuff lately  - as promised. Shortlog from -rc5 
> appended, nothing exciting there, mostly some fixes from various code 
> checkers (like fixed init sections, and some coverity tool finds).

ftp.kernel.org:/pub/linux/kernel/v2.6 doesn't seem to carry a crypto
signature for the patch, patch-2.6.11.gz.sign
-
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

[Linus Torvalds]

Ok,
 there it is. Only small stuff lately  - as promised. Shortlog from -rc5 
appended, nothing exciting there, mostly some fixes from various code 
checkers (like fixed init sections, and some coverity tool finds).

So it's now _officially_ all bug-free.

Linus


Summary of changes from v2.6.11-rc5 to v2.6.11


:
  o [SERIAL] drivers/serial/*: convert to pci_register_driver

:
  o prism54 not releasing region

Alex Williamson:
  o [SERIAL] 8250 woraround for buggy uart

Alexander Nyberg:
  o SELinux: Leak in error path
  o SELinux: null dereference in error path

Andrea Arcangeli:
  o Make the new merged pipe writes check for SIGPIPE

Andrew Morton:
  o binfmt_elf build fix
  o [IA64] ia64 audit build fix
  o genhd: NULL checking fix

Andries E. Brouwer:
  o __devinitdata in parport_pc
  o __init in cfq-iosched.c
  o remove __initdata in scsi_devinfo.c
  o __initdata in apic.c
  o more apic.c

Aurelien Jarno:
  o USB: Fix usbfs regression

Bartlomiej Zolnierkiewicz:
  o [ide] fix build for built-in hpt366 and modular ide-disk
  o [ide] fix IRQ masking in ide_do_request()

Ben Dooks:
  o [ARM PATCH] 2498/1: CREDITS - add Ben Dooks
  o [ARM PATCH] 2505/1: Remove FTVPCI from debug code

Bjorn Helgaas:
  o [SERIAL] discover PNP ports before PCI, etc
  o [SERIAL] add TP560 data/fax/modem support

Chris Wright:
  o fix audit inode filter
  o send audit reply to correct socket

David Gibson:
  o ppc64: hugepage hash flushing bugfix

David Howells:
  o Make keyctl(KEYCTL_JOIN_SESSION_KEYRING) use the correct arg

David S. Miller:
  o [IPV4]: Fix lost routes in fn_hash netlink dumps
  o [AF_UNIX]: Fix SIOCINQ for STREAM and SEQPACKET

Dmitry Torokhov:
  o Input: add more PNP IDs to i8042 driver

Greg Kroah-Hartman:
  o sysfs: fix signedness problem
  o fix module paramater permissions in radeon_base.c
  o USB: fix bug in acm's open function

Harald Welte:
  o [NETFILTER]: ipt_hashlimit rule load time race condition

Hideaki Yoshifuji:
  o add sysctl helper functions to provide milliseconds-based
interfaces
  o [IPV4] Use appropriate sysctl helpers for gc_min_interval_ms
  o [IPV6]: Unregister per-device snmp6 proc entry earlier

Jens Axboe:
  o [PATCH] Fix bounced bio and dm panic

Kenji Kaneshige:
  o [IA64] pci_irq.c: need signed variable to handle error return from
acpi

Linus Torvalds:
  o Fix possible pty line discipline race
  o Properly limit keyboard keycodes to KEY_MAX
  o Make pipe "poll()" take direction of pipe into account
  o Linux 2.6.11

Nishanth Aravamudan:
  o [PKTGEN]: Replace interruptible_sleep_on_timeout()

Olaf Hering:
  o Fix incorrect __init on 'modedb[]' array

Patrick McHardy:
  o [NETFILTER]: Prevent NAT from seeing fragments

Randy Dunlap:
  o [ide] make 1-bit fields unsigned
  o srat: initdata section references
  o sound/oss/aedsp16: init/exit section cleanups
  o sonicvibes: fix initdata references
  o sound/oss/opl3as2: fix init section reference
  o isdn: use __init for ICCVersion()
  o dc395x: fix section references
  o hp100: fix section references
  o rrunner: fix section references

Robert Olsson:
  o [PKTGEN]: reduce stack usage

Russell King:
  o [ARM] Fix dma_mmap() size argument

Sascha Hauer:
  o [ARM PATCH] 2496/1: i.MX DMA fix
  o [ARM PATCH] 2497/1: i.MX pll decode

-
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: [PATCH] Linux-2.6.11-rc5: kernel/sys.c setrlimit() RLIMIT_RSS cleanup

[Peter Chubb]

> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:

Andrew> <[EMAIL PROTECTED]> wrote:
>>  $ ulimit -m 10 bash: ulimit: max memory size: cannot modify
>> limit: Function not implemented

Andrew> I don't know about this.  The change could cause existing
Andrew> applications and scripts to fail.  Sure, we'll do that
Andrew> sometimes but this doesn't seem important enough. 

What's more, there have been (and still are) out-of-tree patches to
enforce rlimit-RSS in various ways.  There just hasn't been consensus
yet on the best implementation.

-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*
-
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: [PATCH] Linux-2.6.11-rc5: kernel/sys.c setrlimit() RLIMIT_RSS cleanup

[Rik van Riel]

On Sun, 27 Feb 2005 [EMAIL PROTECTED] wrote:

> ulimit dont enforce RLIMIT_RSS now,while sys_setrlimit() pretend 
> it(RLIMIT_RSS) is enforced.
> 
> This may cause confusion to users, and may lead to un-guaranteed 
> dependence on "ulimit -m" to limit users/applications.
> 
> The patch fixed the problem. 

Some kernels do enforce the RSS rlimit.  Your patch could break
systems that have the RSS rlimit in their configuration files
because they used to run a kernel that enforces the RSS rlimit.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
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:Re: [PATCH] Linux-2.6.11-rc5: kernel/sys.c setrlimit() RLIMIT_RSS cleanup

[stone_wang]

I have a buddy who encountered the "ulimit" confusion,
when he and his team deployed Linux as the platform for a multi-user online 
programming test competition system.

And generally, i think the kernel/system shall work as it said(return of 
syscalls/output of commands) :)

But rss limit might be a historical issue, with already many applications 
depending on it :(

Stone Wang

-  Original Message  -
From: Andrew Morton 
To: [EMAIL PROTECTED] 
Cc: [EMAIL PROTECTED] ;[EMAIL PROTECTED] ;linux-kernel@vger.kernel.org 
Subject: Re: [PATCH] Linux-2.6.11-rc5: kernel/sys.c setrlimit() RLIMIT_RSS
 cleanup
Sent: Sun Feb 27 18:31:36 CST 2005

> 
> <[EMAIL PROTECTED]> wrote:
> >
> > $ ulimit  -m 10
> >  bash: ulimit: max memory size: cannot modify limit: Function not 
> > implemented
> 
> I don't know about this.  The change could cause existing applications and
> scripts to fail.  Sure, we'll do that sometimes but this doesn't seem
> important enough.

-
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: [PATCH] Linux-2.6.11-rc5: kernel/sys.c setrlimit() RLIMIT_RSS cleanup

[Andrew Morton]

<[EMAIL PROTECTED]> wrote:
>
> $ ulimit  -m 10
>  bash: ulimit: max memory size: cannot modify limit: Function not implemented

I don't know about this.  The change could cause existing applications and
scripts to fail.  Sure, we'll do that sometimes but this doesn't seem
important enough.
-
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-rc5: kernel/sys.c setrlimit() RLIMIT_RSS cleanup

[stone_wang]

ulimit dont enforce RLIMIT_RSS now,while sys_setrlimit() pretend it(RLIMIT_RSS) 
is enforced. 

This may cause confusion to users, and may lead to un-guaranteed dependence on 
"ulimit -m" to limit users/applications.

The patch fixed the problem. 

-- snip from system run with patched(patch attached) 2.6.11-rc5 kernel
$ ulimit  -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
file size   (blocks, -f) unlimited
pending signals (-i) 1024
max locked memory   (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 4091
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

$ ulimit  -m 10
bash: ulimit: max memory size: cannot modify limit: Function not implemented

-
patch: 2.6.11-rc5 kernel/sys.c setrlimit() RLIMIT_RSS cleanup

Signed-Off-By: Stone Wang  <[EMAIL PROTECTED]>

diff -urpN linux-2.6.11-rc5-original/kernel/sys.c 
linux-2.6.11-rc5-cleanup/kernel/sys.c
--- linux-2.6.11-rc5-original/kernel/sys.c  2005-02-26 17:34:38.0 
-0500
+++ linux-2.6.11-rc5-cleanup/kernel/sys.c   2005-02-27 17:27:20.0 
-0500
@@ -1488,6 +1488,14 @@ asmlinkage long sys_setrlimit(unsigned i
if (new_rlim.rlim_cur > new_rlim.rlim_max)
return -EINVAL;
old_rlim = current->signal->rlim + resource;
+
+   /* We dont enforce RLIMIT_RSS ulimit yet. But for application
+  compatability, we warn only when asked to change system default 
value. */
+   if( resource == RLIMIT_RSS &&
+   ((new_rlim.rlim_max != old_rlim->rlim_max)||
+(new_rlim.rlim_cur != old_rlim->rlim_cur)) )
+   return -ENOSYS;
+
if ((new_rlim.rlim_max > old_rlim->rlim_max) &&
!capable(CAP_SYS_RESOURCE))
return -EPERM;
-
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/