Avoid poisoning of the bridge forwarding table by frames that have been
dropped by filtering. This prevents spoofed source addresses on hostile
side of bridge from causing packet leakage, a small but possible security
risk.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix possible false assertion failure in log_do_checkpoint(). We might fail
to detect that we actually made a progress when cleaning up the checkpoint
lists if we don't retry after writing something to disk. The patch was
confirmed to fix observed assertion failures for several users.
When we flushed some buffers we need to retry scanning the list.
Otherwise we can fail to detect our progress.
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Pete Jewell [Wed, 1 Jun 2005 19:16:04 +0000 (21:16 +0200)]
[PATCH] Fix for bttv driver (v0.9.15) for Leadtek WinFast VC100 XP capture cards
Cc: kraxel@bytesex.org
This is a tiny patch that fixes bttv-cards.c so that Leadtek WinFast
VC100 XP video capture cards work. I've been advised to post it here
after having already posted it to the v4l mailing list.
Acked-by: Gerd Knorr <kraxel@bytesex.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andi Kleen [Tue, 31 May 2005 14:08:47 +0000 (16:08 +0200)]
[PATCH] x86_64: avoid SMP boot up race
Keep interrupts disabled during smp bootup
This avoids a race that breaks SMP bootup on some machines.
The race is not fully plugged (that is only done with much
more changes in 2.6.12), but should be good enough
for most people.
Keeping the interrupts disabled here is ok because we
don't rely on the timer interrupt for local APIC
timer setup, but always read the timer registers
directly.
(originally from Rusty Russell iirc)
Signed-off-by: ak@suse.de Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Colin Leroy [Mon, 30 May 2005 14:01:58 +0000 (16:01 +0200)]
[PATCH] fix hfsplus oops, hfs and hfsplus leak
This patch fixes the leak of sb->s_fs_info in both the HFS and HFS+
modules. In addition to this, it fixes an oops happening when trying to
mount a non-hfsplus filesystem using hfsplus. This patch is from Roman
Zippel, based off patches sent by myself. It's been included in 2.6.12-
rc4. See
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=945b092011c6af71a0107be96e119c8c08776f3f
Harald Welte [Mon, 30 May 2005 22:38:14 +0000 (15:38 -0700)]
[PATCH] Fix deadlock with ip_queue and tcp local input path.
When we have ip_queue being used from LOCAL_IN, then we end up with a
situation where the verdicts coming back from userspace traverse the TCP
input path from syscall context. While this seems to work most of the
time, there's an ugly deadlock:
syscall context is interrupted by the timer interrupt. When the timer
interrupt leaves, the timer softirq get's scheduled and calls
tcp_delack_timer() and alike. They themselves do bh_lock_sock(sk),
which is already held from somewhere else -> boom.
I've now tested the suggested solution by Patrick McHardy and Herbert Xu to
simply use local_bh_{en,dis}able().
Signed-off-by: Harald Welte <laforge@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It may take a little staring to notice, but pte can actually fall off the
end of the pte page in this iteration, which makes life difficult for
kmap_atomic() and the users not expecting it to BUG(). Of course, we're
somewhat lucky in that arithmetic elsewhere in the function guarantees that
at least one iteration is made, lest this force larger rearrangements to be
made. This issue and patch also apply to non-mm mainline and with trivial
adjustments, at least two related kernels.
Discovered during internal testing at Oracle.
Signed-off-by: William Irwin <wli@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
Andi Kleen [Tue, 17 May 2005 04:53:31 +0000 (04:53 +0000)]
[PATCH] x86_64: When checking vmalloc mappings don't use pte_page
The PTEs can point to ioremap mappings too, and these are often outside
mem_map. The NUMA hash page lookup functions cannot handle out of bounds
accesses properly.
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org>
Gregor Jasny [Thu, 28 Apr 2005 07:24:08 +0000 (09:24 +0200)]
[PATCH] usbusx2y: prevent oops & dead keyboard on usb unplugging while the device is being used
Summary: prevent oops & dead keyboard on usb unplugging while the device is being used
Without this patch, some usb kobjects, which are parents to
the usx2y's kobjects can be freed before the usx2y's.
This led to an oops in get_kobj_path_length() and a dead
keyboard, when the usx2y's kobjects were freed.
The patch ensures the correct sequence.
Tested ok on kernel 2.6.12-rc2.
Gregor Jasny [Thu, 28 Apr 2005 07:26:48 +0000 (09:26 +0200)]
[PATCH] usbaudio: prevent oops & dead keyboard on usb unplugging while the device is being used
Summary: prevent oops & dead keyboard on usb unplugging while the device is being used
Without this patch, some usb kobjects, which are parents to
the usx2y's kobjects can be freed before the usx2y's.
This led to an oops in get_kobj_path_length() and a dead
keyboard, when the usx2y's kobjects were freed.
The patch ensures the correct sequence.
Tested ok on kernel 2.6.12-rc2.
Daniel Drake [Thu, 12 May 2005 11:31:27 +0000 (12:31 +0100)]
[PATCH] ide-disk: Fix LBA8 DMA
This is from Gentoo's 2.6.11 patchset. A problem was introduced in 2.6.10
where some users could not enable DMA on their disks (particularly ALi15x3
users). This was a small mistake with the no_lba48_dma flag.
I can't find the exact commit but this is definately included in 2.6.12-rc4.
There was too much/too few byteswapping done by driver and hardware in
matroxfb on big endian hardware. Change fixes mirrored/split/corrupted
letters seen on screen when using accelerated matroxfb mode.
Patch was tested on Mips (by Peter) and x86-64 (by Petr).
Signed-off-by: Peter 'p2' De Schrijver <p2@mind.be> Signed-off-by: Petr Vandrovec <vandrove@vc.cvut.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
Here's a fix to deal with p630 systems in LPAR mode. They're to date the
only system that in some cases might lack a dma-window property for the
bus, but contain an overriding property in the device node for the specific
adapter/slot. This makes the device setup code a bit more complex since it
needs to do some of the things that the bus setup code has already done.
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
cmm@us.ibm.com [Thu, 10 Mar 2005 16:44:10 +0000 (08:44 -0800)]
[PATCH] ext3: fix race between ext3 make block reservation and reservation window discard
This patch fixed a race between ext3_discard_reservation() and
ext3_try_to_allocate_with_rsv().
There is a window where ext3_discard_reservation will remove an already
unlinked reservation window node from the filesystem reservation tree:
It thinks the reservation is still linked in the filesystem reservation
tree, but it is actually temperately removed from the tree by
allocate_new_reservation() when it failed to make a new reservation from
the current group and try to make a new reservation from next block
group.
Here is how it could happen:
CPU 1
try to allocate a block in group1 with given reservation window my_rsv
ext3_try_to_allocate_with_rsv(group
----copy reservation window my_rsv into local rsv_copy
ext3_try_to_allocate(...rsv_copy)
----no free block in existing reservation window,
----need a new reservation window
spin_lock(&rsv_lock);
CPU 2
ext3_discard_reservation
if (!rsv_is_empty()
----this is true
spin_lock(&rsv_lock)
----waiting for thread 1
CPU 1:
allocate_new_reservation
failed to reserve blocks in this group
remove the window from the tree
rsv_window_remove(my_rsv)
----window node is unlinked from the tree here
return -1
spin_unlock(&rsv_lock)
ext3_try_to_allocate_with_rsv() failed in this group
group++
CPU 2
spin_lock(&rsv_lock) succeed
rsv_remove_window ()
---------------break, trying to remove a unlinked node from the tree
....
CPU 1:
ext3_try_to_allocate_with_rsv(group, my_rsv)
rsv_is_empty is true, need a new reservation window
spin_lock(&rsv_lock);
^--------------- spinning forever
We need to re-check whether the reservation window is still linked to
the tree after grab the rsv_lock spin lock in ext3_discard_reservation,
to prevent panic in rsv_remove_window->rb_erase.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
The patch below fixes an smp race that happens on such systems under
heavy load.
This bug was reported and solved by Steve Herrell
<steve_herrell@yahoo.ca>
Signed-off-by: Bart De Schuymer <bdschuym@pandora.be> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
Linus Torvalds [Fri, 20 May 2005 05:43:37 +0000 (22:43 -0700)]
[PATCH] Fix get_unmapped_area sanity tests
Fix get_unmapped_area sanity tests
As noted by Chris Wright, we need to do the full range of tests regardless
of whether MAP_FIXED is set or not, so re-organize get_unmapped_area()
slightly to do the sanity checks unconditionally.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@osdl.org>
Peter Osterlund [Sat, 14 May 2005 07:58:30 +0000 (00:58 -0700)]
[PATCH] Fix root hole in pktcdvd
ioctl_by_bdev may only be used INSIDE the kernel. If the "arg" argument
refers to memory that is accessed by put_user/get_user in the ioctl
function, the memory needs to be in the kernel address space (that's the
set_fs(KERNEL_DS) doing in the ioctl_by_bdev). This works on i386 because
even with set_fs(KERNEL_DS) the user space memory is still accessible with
put_user/get_user. That is not true for s390. In short the ioctl
implementation of the pktcdvd device driver is horribly broken.
Signed-off-by: Peter Osterlund <petero2@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Jones [Sat, 14 May 2005 03:31:19 +0000 (23:31 -0400)]
[PATCH] Fix root hole in raw device
[Patch] Fix raw device ioctl pass-through
Raw character devices are supposed to pass ioctls through to the block
devices they are bound to. Unfortunately, they are using the wrong
function for this: ioctl_by_bdev(), instead of blkdev_ioctl().
ioctl_by_bdev() performs a set_fs(KERNEL_DS) before calling the ioctl,
redirecting the user-space buffer access to the kernel address space.
This is, needless to say, a bad thing.
This was noticed first on s390, where raw IO was non-functioning. The
s390 driver config does not actually allow raw IO to be enabled, which
was the first part of the problem. Secondly, the s390 kernel address
space is distinct from user, causing legal raw ioctls to fail. I've
reproduced this on a kernel built with 4G:4G split on x86, which fails
in the same way (-EFAULT if the address does not exist kernel-side;
returns success without actually populating the user buffer if it does.)
The patch below fixes both the config and address-space problems. It's
based closely on a patch by Jan Glauber <jang@de.ibm.com>, which has
been tested on s390 at IBM. I've tested it on x86 4G:4G (split address
space) and x86_64 (common address space).
Kernel-address-space access has been assigned CAN-2005-1264.
Signed-off-by: Stephen Tweedie <sct@redhat.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] sparc64: use message queue compat syscalls
A couple message queue system call entries for compat tasks
were not using the necessary compat_sys_*() functions, causing
some glibc test cases to fail.
From: "David S. Miller" <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
SunOS aparently had this weird PTRACE_CONT semantic which
we copied. If the addr argument is something other than
1, it sets the process program counter to whatever that
value is.
This is different from every other Linux architecture, which
don't do anything with the addr and data args.
This difference in particular breaks the Linux native GDB support
for fork and vfork tracing on sparc and sparc64.
There is no interest in running SunOS binaries using this weird
PTRACE_CONT behavior, so just delete it so we behave like other
platforms do.
From: "David S. Miller" <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I'm resending this for inclusion in the -stable tree. I've deleted whitespace
cleanups, and hope this can be merged. I've been asked to split the former
patch, I don't know if I must split again this one, even because I don't want
to split this correct patch into multiple non-correct ones by mistake.
Uml 2.6.11 does not compile with gcc 2.95.4 because some entries are
duplicated, and that GCC does not accept this (unlike gcc 3). Plus various
other bugs in the syscall table definitions, resulting in probable wrong
syscall entries:
*) 223 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 it's a
valid syscall (thus a duplicated one).
*) __NR_vserver must be only once with sys_ni_syscall, and not multiple
times with different values!
*) syscalls duplicated in SUBARCHs and in common files (thus assigning twice
to the same array entry and causing the GCC 2.95.4 failure mentioned above):
sys_utimes, which is common, and sys_fadvise64_64, sys_statfs64,
sys_fstatfs64, which exist only on i386.
*) syscalls duplicated in each SUBARCH, to put in common files:
sys_remap_file_pages, sys_utimes, sys_fadvise64
*) 285 is a syscall hole (i.e. ni_syscall) only on i386, on x86_64 the range
does not arrive to that point.
*) on x86_64, the macro name is __NR_kexec_load and not __NR_sys_kexec_load.
Use the correct name in either case.
Note: as you can see, part of the syscall table definition in UML is
arch-independent (with everywhere defined syscalls), and part is
arch-dependant. This has created confusion (some syscalls are listed in both
places, some in the wrong one, some are wrong on one arch or another).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] Fix reproducible SMP crash in security/keys/key.c
Jani Jaakkola <jjaakkol@cs.Helsinki.FI> wrote:
>
> SMP race handling is broken in key_user_lookup() in security/keys/key.c
This was fixed post-2.6.11. Can you confirm that 2.6.12-rc2 works OK?
This is the patch we used. It should go into -stable if it's not already
there.
From: Alexander Nyberg <alexn@dsv.su.se>
I looked at some of the oops reports against keyrings, I think the problem
is that the search isn't restarted after dropping the key_user_lock, *p
will still be NULL when we get back to try_again and look through the tree.
It looks like the intention was that the search start over from scratch.
Signed-off-by: Alexander Nyberg <alexn@dsv.su.se> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Here's a patch that fixes
http://bugme.osdl.org/show_bug.cgi?id=4395.
Patch by Manu Abraham and Gerd Knorr:
Remove redundant bttv_reset_audio() which caused the computer to
freeze with some bt8xx based DVB cards when loading the bttv driver.
Since BIC is the default congestion control algorithm
enabled in every 2.6.x kernel out there, fixing errors
in it becomes quite critical.
A flaw in the loss handling caused it to not perform
the binary search regimen of the BIC algorithm
properly.
The fix below from Stephen Hemminger has been heavily
verified.
[TCP]: BIC not binary searching correctly
While redoing BIC for the split up version, I discovered that the existing
2.6.11 code doesn't really do binary search. It ends up being just a slightly
modified version of Reno. See attached graphs to see the effect over simulated
1mbit environment.
The problem is that BIC is supposed to reset the cwnd to the last loss value
rather than ssthresh when loss is detected. The correct code (from the BIC
TCP code for Web100) is in this patch.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We should merge this backport - it's needed to prevent deadlocks when
dio_complete() does up_read() from IRQ context. And perhaps other places.
From: David Howells <dhowells@redhat.com>
[PATCH] rwsem: Make rwsems use interrupt disabling spinlocks
The attached patch makes read/write semaphores use interrupt disabling
spinlocks in the slow path, thus rendering the up functions and trylock
functions available for use in interrupt context. This matches the
regular semaphore behaviour.
I've assumed that the normal down functions must be called with interrupts
enabled (since they might schedule), and used the irq-disabling spinlock
variants that don't save the flags.
Signed-Off-By: David Howells <dhowells@redhat.com> Tested-by: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] Do not hold state lock while checking size
This patch from Herbert Xu fixes a deadlock with IPsec.
When an ICMP frag. required is sent and the ICMP message
needs the same SA as the packet that caused it the state
will be locked twice.
[IPSEC]: Do not hold state lock while checking size.
This can elicit ICMP message output and thus result in a
deadlock.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes an oops in the eeprom driver. It was first reported here:
http://bugzilla.kernel.org/show_bug.cgi?id=4347
It was additionally discussed here (while tracking a completely
different bug):
http://archives.andrew.net.au/lm-sensors/msg30021.html
The patch is already in 2.6.12-rc1:
http://linux.bkbits.net:8080/linux-2.5/cset@1.2227
The oops happens when one reads data from the sysfs interface file such
that (off < 16) and (count < 16 - off). For example "sensors" from
lm_sensors 2.9.0 does this, and causes the oops.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Attached is a patch against David's audit.17 kernel that adds checks
for the TIF_SYSCALL_AUDIT thread flag to the ia64 system call and
signal handling code paths. The patch enables auditing of system
calls set up via fsys_bubble_down, as well as ensuring that
audit_syscall_exit() is called on return from sigreturn.
Neglecting to check for TIF_SYSCALL_AUDIT at these points results in
incorrect information in audit_context, causing frequent system panics
when system call auditing is enabled on an ia64 system.
I have tested this patch and have seen no problems with it.
[Original patch from Amy Griffis ported to current kernel by David Woodhouse]
From: Amy Griffis <amy.griffis@hp.com>
From: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stephen Tweedie [Thu, 7 Apr 2005 18:17:40 +0000 (11:17 -0700)]
[PATCH] Prevent race condition in jbd
Subject: Prevent race condition in jbd
This patch from Stephen Tweedie which fixes a race in jbd code (it
demonstrated itself as more or less random NULL dereferences in the
journal code).
Acked-by: Jan Kara <jack@suse.cz> Acked-by: Chris Mason <mason@suse.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
khc@pm.waw.pl [Sat, 19 Mar 2005 05:47:12 +0000 (21:47 -0800)]
[PATCH] Fix kernel panic on receive with WAN Hitachi SCA HD6457x
Another patch for 2.6.11.x: already in main tree, fixes kernel panic on
receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101, PCI200SYN.
The attached patch fixes NULL pointer dereference on RX.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It seems to me that in the VIA Rhine device driver the requested irq might
not be freed in case the alloc_ring() function fails. alloc_ring()
can fail with a ENOMEM return value because of possible
pci_alloc_consistent() failures.
Updated to CodingStyle.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
hugh@veritas.com [Sat, 19 Mar 2005 05:41:52 +0000 (21:41 -0800)]
[PATCH] tasklist left locked
On 4-way SMP, about one reboot in twenty hangs while killing processes:
exit needs exclusive tasklist_lock, but something still holds read_lock.
do_signal_stop race case misses unlock, and fixing it fixes the symptom.
Signed-off-by: Hugh Dickins <hugh@veritas.com> Acked-by: Roland McGrath <roland@redhat.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
http://bugme.osdl.org/show_bug.cgi?id=4279
Summary: When I try to start vpnc the net/core/skbuff.c:91 crash
This check is wrong, gcc optimizes it away:
if ((len -= sizeof(pi)) > len)
return -EINVAL;
This could be responsible for the BUG. If len is 2 or 3 and TUN_NO_PI
isn't set it underflows. alloc_skb() allocates len + 2, which is 0 or
1 byte. skb_reserve tries to reserve 2 bytes and things explode in
skb_put.
[TUN]: Fix check for underflow
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This function, as it's name implies, is supposed to only
return IPSEC objects which are in the XFRM_STATE_ACQ
("acquire") state. But it returns any object with the
matching sequence number.
This is wrong and confuses IPSEC daemons to no end.
[XFRM]: xfrm_find_acq_byseq should only return XFRM_STATE_ACQ states.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kaber@trash.net [Sat, 19 Mar 2005 05:37:15 +0000 (21:37 -0800)]
[PATCH] Fix crash while reading /proc/net/route
[IPV4]: Fix crash while reading /proc/net/route caused by stale pointers
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It seems to me that if in the amd8111e_open() fuction dev->irq isn't
zero and the irq request succeeds it might not get released anymore.
Specifically, on failure of the amd8111e_restart() call the function
returns -ENOMEM without releasing the irq. The amd8111e_restart()
function can fail because of various pci_alloc_consistent() and
dev_alloc_skb() calls in amd8111e_init_ring() which is being
called by amd8111e_restart.
dsd@gentoo.org [Sat, 19 Mar 2005 05:32:08 +0000 (21:32 -0800)]
[PATCH] Fix stereo mutes on Surround volume control
As of 2.6.11, I have no output out of the rear right speaker of my 4.1
surround sound setup. I am using snd-intel8x0 based on a Realtek ALC650F chip
on an nvidia motherboard.
A gentoo user with completely different hardware also ran into this:
http://bugs.gentoo.org/84276
2.6.11-mm3 fixes this problem and I've identified the specific fix, which is
already in the ALSA development tree. An ALSA developer asked me to submit the
fix for 2.6.11.x when I'd found it, so here it is :)
--
AC97 Codec
Fix stereo mutes on Surround volume control.
Fix deadlock in NetROM due to double locking. I was sent the patch by
Alan and have doublechecked it. This bug hits Net/ROM users really hard.
It's accepted by DaveM - but just too late to make it into 2.6.11.
[PATCH] CAN-2005-0384: Remote Linux DoS on ppp servers
Martin Schulze writes:
> Ben Martel and Stephen Blackheath have discovered a denial-of-service attack
> that a client of pppd can make that can hang the server machine. The bug is
> in the Linux kernel 2.6 (tested on 2.6.9), but it looks like it also exists
> in the 2.4 series.
Yes, this is my bug. :(
I would just do this instead:
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
/* Hit power state D3 (sleep) */
iowrite8(ioread8(ioaddr + StickyHW) | 0x03, ioaddr + StickyHW);
that fails. StickyHW is 0x83. lspci says:
0000:00:07.0 Ethernet controller: VIA Technologies, Inc. VT86C100A
[Rhine] (rev 06)
Flags: bus master, medium devsel, latency 32, IRQ 18
I/O ports at ec00 [size=128]
Memory at dfffff80 (32-bit, non-prefetchable) [size=128]
In other words, it's trying to read outside of the I/O range (0x80),
which matches the fauling address.
I'm guessing my chip revision doesn't support WOL, it's a crappy noname
card.
It does seem as if rhine_power_init checks quirks for rqWOL before
touching any registers. Should rhine_shutdown do the same? Proposed
patch below, which resolves the problem on my system.
Check to make sure WOL is supported before setting it up in
rhine_shutdown.
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
chrisw@osdl.org [Sun, 13 Mar 2005 05:46:45 +0000 (21:46 -0800)]
[PATCH] sis900 kernel oops fix
Backport of fix described below.
From: Herbert Xu <herbert@gondor.apana.org.au>
Fix bug #4223.
OK, this happened because we got preempted before sis900_mii_probe
finished setting the sis_priv->mii. Theoretically this can happen
with SMP as well but I suppose the number of SMP machines with sis900
is fairly small.
Anyway, the fix is to make sure that sis900_mii_probe is done before
the device can be opened. This patch does it by moving the setup
before register_netdevice.
Since the netdev name is not available before register_netdev, I've
changed the relevant printk's to use pci_name instead. Note that
one of those printk's may be called after register_netdev as well.
Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] Put back tcp_timer_bug_msg[] symbol export.
This wrecks the ipv6 modular build for a lot of people.
In fact, since I always build ipv6 modular I am surprised
I never hit this. My best guess is that my compiler is
optimizing the reference away, but that can never be
depended upon and the symbol export really is needed.
[TCP]: Put back tcp_timer_bug_msg[] symbol export.
It is needed for tcp_reset_xmit_timer(), which is invoked by
tcp_prequeue() which is invoked from tcp_ipv6.c
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
While working on the saa7110 driver I found a problem with the way
various video drivers (found on Zoran-based boards) prepare i2c messages
to be used by i2c_transfer. The drivers improperly copy the i2c client
flags as the message flags, while both sets are mostly unrelated. The
net effect in this case is to trigger an I2C block read instead of the
expected I2C block write. The fix is simply not to pass any flag,
because none are needed.
I think this patch qualifies hands down as a "critical bug fix" to be
included in whatever bug-fix-only trees exist these days. As far as I
can see, all Zoran-based boards are broken in 2.6.11 without this patch.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Matt Porter [Sun, 13 Mar 2005 05:39:19 +0000 (21:39 -0800)]
[PATCH] ppc32: Compilation fixes for Ebony, Luan and Ocotea
this patch fixes the problem, that the current kernel (linux-2.6.11-rc5)
could not be compiled, when "support for early boot texts over serial port"
(CONFIG_SERIAL_TEXT_DEBUG=y) is active.
Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com> Signed-off-by: Matt Porter <mporter@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
airlied@linux.ie [Sun, 13 Mar 2005 05:38:27 +0000 (21:38 -0800)]
[PATCH] drm missing memset can crash X server..
Egbert Eich reported a bug 2673 on bugs.freedesktop.org and tracked it
down to a missing memset in the setversion ioctl, this causes X server
crashes...
From: Egbert Eich <eich@pdx.freedesktop.org> Signed-off-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Lammerts [Sun, 13 Mar 2005 05:35:18 +0000 (21:35 -0800)]
[PATCH] cramfs: small stat(2) fix
When I stat(2) a device node on a cramfs, the st_blocks field is bogus
(it's derived from the size field which in this case holds the major/minor
numbers). This makes du(1) output completely wrong.
Signed-off-by: Eric Lammerts <eric@lammerts.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] fix amd64 2.6.11 oops on modprobe (saa7110)
This is a rewrite of the saa7110_write_block function, which was plain
broken in the case where the underlying adapter supports I2C_FUNC_I2C.
It also includes related fixes which ensure that different parts of the
driver agree on the number of registers the chip has.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some ACPI-related changes were recently made to i8042 discovery for ia64.
Unfortunately this broke a significant number of Dell laptops due to their
having incorrect BIOS tables.
So, for now, arrange for the new code to be ia64-only.
[PATCH] Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec
Here's a patch that will work for both PPC and PPC64. The proper way to
fix this in mainline is to merge -mm's cpu_has_feature patch, but for
the stable 2.6.11-series, this much less intrusive (i.e. just the pure
bugfix, not the cleanup part).
Signed-off-by: Olof Johansson <olof@austin.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
projects / thirdparty / kernel / stable.git / log
