linux, branch v2.6.16.10

Linux 2.6.16.10

2006-04-24T17:07:37Z

[PATCH] IPC: access to unmapped vmalloc area in grow_ary()

2006-04-24T16:56:05Z

grow_ary() should not copy struct ipc_id_ary (it copies new->p, not new). Due to this, memcpy() src pointer could hit unmapped vmalloc page when near page boundary. Found during OpenVZ stress testing Signed-off-by: Alexey Kuznetsov Signed-off-by: Kirill Korotaev Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] Add more prevent_tail_call()

2006-04-24T16:56:05Z

Those also break userland regs like following. 00000000 : 0: 0f b7 44 24 0c movzwl 0xc(%esp),%eax 5: 83 ca ff or $0xffffffff,%edx 8: 0f b7 4c 24 08 movzwl 0x8(%esp),%ecx d: 66 83 f8 ff cmp $0xffffffff,%ax 11: 0f 44 c2 cmove %edx,%eax 14: 66 83 f9 ff cmp $0xffffffff,%cx 18: 0f 45 d1 cmovne %ecx,%edx 1b: 89 44 24 0c mov %eax,0xc(%esp) 1f: 89 54 24 08 mov %edx,0x8(%esp) 23: e9 fc ff ff ff jmp 24 where the tailcall at the end overwrites the incoming stack-frame. Signed-off-by: OGAWA Hirofumi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] alim15x3: ULI M-1573 south Bridge support

2006-04-24T16:56:05Z

>From http://bugzilla.kernel.org/show_bug.cgi?id=6358 The alim15x3.c havn't been update for 3 years. Recently when we use this "ULI M1573" south bridge chip found that can't mount CDROM(VCD) smoothly, must waiting for a long time. After I check the "ULI M1573" south bridge datasheet, I found the reason. The reason is the "ULI M1573" version in the Linux is "0xC7" not "0xC4" anymore So I was modified the source than it was successed. Cc: Bartlomiej Zolnierkiewicz Acked-by: Alan Cox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] apm: fix Armada laptops again

2006-04-24T16:56:05Z

Fix the "apm: set display: Interface not engaged" error on Armada laptops again. Jordan said: I think this is fine. It seems to me that this may be the fault of one or both of the APM solutions handling this situation in a non-standard way, but since APM is used very little on the Geode, and I have direct access to our BIOS folks, if this problem comes up with a customer again, we'll solve it from the firmware. Signed-off-by: Samuel Thibault Cc: "Jordan Crouse" Cc: Zachary Amsden Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] fbdev: Fix return error of fb_write

2006-04-24T16:56:05Z

Fix return code of fb_write(): If at least 1 byte was transferred to the device, return number of bytes, otherwise: - return -EFBIG - if file offset is past the maximum allowable offset or size is greater than framebuffer length - return -ENOSPC - if size is greater than framebuffer length - offset Signed-off-by: Antonino Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix file lookup without ref

2006-04-24T16:56:05Z

There are places in the kernel where we look up files in fd tables and access the file structure without holding refereces to the file. So, we need special care to avoid the race between looking up files in the fd table and tearing down of the file in another CPU. Otherwise, one might see a NULL f_dentry or such torn down version of the file. This patch fixes those special places where such a race may happen. Signed-off-by: Dipankar Sarma Acked-by: "Paul E. McKenney" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] m41t00: fix bitmasks when writing to chip

2006-04-24T16:56:05Z

Fix the bitmasks used when writing to the M41T00 registers. The original code used a mask of 0x7f when writing to each register, this is incorrect and probably the result of a copy-paste error. As a result years from 1980 to 1999 will be read back as 2000 to 2019. Signed-off-by: David Barksdale Acked-by: Jean Delvare Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] Open IPMI BT overflow

2006-04-24T16:56:04Z

I was looking into random driver code and found a suspicious looking memcpy() in drivers/char/ipmi/ipmi_bt_sm.c on 2.6.17-rc1: if ((size < 2) || (size > IPMI_MAX_MSG_LENGTH)) return -1; ... memcpy(bt->write_data + 3, data + 1, size - 1); where sizeof bt->write_data is IPMI_MAX_MSG_LENGTH. It looks like the memcpy would overflow by 2 bytes if size == IPMI_MAX_MSG_LENGTH. A patch attached to limit size to (IPMI_MAX_LENGTH - 2). Cc: Corey Minyard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

[PATCH] x86: be careful about tailcall breakage for sys_open[at] too

2006-04-24T16:56:04Z

x86: be careful about tailcall breakage for sys_open[at] too Came up through a quick grep for other cases similar to the ftruncate() one in commit 0a489cb3b6a7b277030cdbc97c2c65905db94536. Also, add a comment, so that people who read the code understand why we do what looks like a no-op. (Again, this won't actually matter to any sane user, since libc will save and restore the register gcc stomps on, but it's still wrong to stomp on it) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman