- 09 Sep, 2006 2 commits
-
-
Adrian Bunk authored
-
Neil Brown authored
This prevents bad inode numbers from triggering errors in ext2_get_inode. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 06 Sep, 2006 10 commits
-
-
Adrian Bunk authored
-
Alan Cox authored
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
David S. Miller authored
Mirror the bug fix from fill_packet_ipv4() Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Chen-Li Tien authored
Signed-off-by: Chen-Li Tien <cltien@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Dean Nelson authored
Jack Steiner identified a problem where XPC can cause a silent data corruption. On module load, the placement may cause the xpc_remote_copy_buffer to span two physical pages. DMA transfers are done to the start virtual address translated to physical. This patch changes the buffer from a statically allocated buffer to a kmalloc'd buffer. Dean Nelson reviewed this before posting. I have tested it in the configuration that was showing the memory corruption and verified it works. I also added a BUG_ON statement to help catch this if a similar situation is encountered. Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Dean Nelson <dcn@sgi.com> Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
YOSHIFUJI Hideaki authored
Bug noticed by Remi Denis-Courmont <rdenis@simphalempin.com>. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Sonny Rao authored
I ran into a bug where the kernel died in the idr code: cpu 0x1d: Vector: 300 (Data Access) at [c000000b7096f710] pc: c0000000001f8984: .idr_get_new_above_int+0x140/0x330 lr: c0000000001f89b4: .idr_get_new_above_int+0x170/0x330 sp: c000000b7096f990 msr: 800000000000b032 dar: 0 dsisr: 40010000 current = 0xc000000b70d43830 paca = 0xc000000000556900 pid = 2022, comm = hwup 1d:mon> t [c000000b7096f990] c0000000000d2ad8 .expand_files+0x2e8/0x364 (unreliable) [c000000b7096faa0] c0000000001f8bf8 .idr_get_new_above+0x18/0x68 [c000000b7096fb20] c00000000002a054 .init_new_context+0x5c/0xf0 [c000000b7096fbc0] c000000000049dc8 .copy_process+0x91c/0x1404 [c000000b7096fcd0] c00000000004a988 .do_fork+0xd8/0x224 [c000000b7096fdc0] c00000000000ebdc .sys_clone+0x5c/0x74 [c000000b7096fe30] c000000000008950 .ppc_clone+0x8/0xc -- Exception: c00 (System Call) at 000000000fde887c SP (f8b4e7a0) is in userspace Turned out to be a race-condition and NULL ptr deref, here's my fix: Users of the idr code are supposed to call idr_pre_get without locking, so the idr code must serialize itself with respect to layer allocations. However, it fails to do so in an error path in idr_get_new_above_int(). I added the missing locking to fix this. Signed-off-by: Sonny Rao <sonny@burdell.org> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Christian Borntraeger authored
This patch adds a barrier() in futex unqueue_me to avoid aliasing of two pointers. On my s390x system I saw the following oops: Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000 Oops: 0004 [#1] CPU: 0 Not tainted Process mytool (pid: 13613, task: 000000003ecb6ac0, ksp: 00000000366bdbd8) Krnl PSW : 0704d00180000000 00000000003c9ac2 (_spin_lock+0xe/0x30) Krnl GPRS: 00000000ffffffff 000000003ecb6ac0 0000000000000000 0700000000000000 0000000000000000 0000000000000000 000001fe00002028 00000000000c091f 000001fe00002054 000001fe00002054 0000000000000000 00000000366bddc0 00000000005ef8c0 00000000003d00e8 0000000000144f91 00000000366bdcb8 Krnl Code: ba 4e 20 00 12 44 b9 16 00 3e a7 84 00 08 e3 e0 f0 88 00 04 Call Trace: ([<0000000000144f90>] unqueue_me+0x40/0xe4) [<0000000000145a0c>] do_futex+0x33c/0xc40 [<000000000014643e>] sys_futex+0x12e/0x144 [<000000000010bb00>] sysc_noemu+0x10/0x16 [<000002000003741c>] 0x2000003741c The code in question is: static int unqueue_me(struct futex_q *q) { int ret = 0; spinlock_t *lock_ptr; /* In the common case we don't take the spinlock, which is nice. */ retry: lock_ptr = q->lock_ptr; if (lock_ptr != 0) { spin_lock(lock_ptr); /* * q->lock_ptr can change between reading it and * spin_lock(), causing us to take the wrong lock. This * corrects the race condition. [...] and my compiler (gcc 4.1.0) makes the following out of it: 00000000000003c8 <unqueue_me>: 3c8: eb bf f0 70 00 24 stmg %r11,%r15,112(%r15) 3ce: c0 d0 00 00 00 00 larl %r13,3ce <unqueue_me+0x6> 3d0: R_390_PC32DBL .rodata+0x2a 3d4: a7 f1 1e 00 tml %r15,7680 3d8: a7 84 00 01 je 3da <unqueue_me+0x12> 3dc: b9 04 00 ef lgr %r14,%r15 3e0: a7 fb ff d0 aghi %r15,-48 3e4: b9 04 00 b2 lgr %r11,%r2 3e8: e3 e0 f0 98 00 24 stg %r14,152(%r15) 3ee: e3 c0 b0 28 00 04 lg %r12,40(%r11) /* write q->lock_ptr in r12 */ 3f4: b9 02 00 cc ltgr %r12,%r12 3f8: a7 84 00 4b je 48e <unqueue_me+0xc6> /* if r12 is zero then jump over the code.... */ 3fc: e3 20 b0 28 00 04 lg %r2,40(%r11) /* write q->lock_ptr in r2 */ 402: c0 e5 00 00 00 00 brasl %r14,402 <unqueue_me+0x3a> 404: R_390_PC32DBL _spin_lock+0x2 /* use r2 as parameter for spin_lock */ So the code becomes more or less: if (q->lock_ptr != 0) spin_lock(q->lock_ptr) instead of if (lock_ptr != 0) spin_lock(lock_ptr) Which caused the oops from above. After adding a barrier gcc creates code without this problem: [...] (the same) 3ee: e3 c0 b0 28 00 04 lg %r12,40(%r11) 3f4: b9 02 00 cc ltgr %r12,%r12 3f8: b9 04 00 2c lgr %r2,%r12 3fc: a7 84 00 48 je 48c <unqueue_me+0xc4> 400: c0 e5 00 00 00 00 brasl %r14,400 <unqueue_me+0x38> 402: R_390_PC32DBL _spin_lock+0x2 As a general note, this code of unqueue_me seems a bit fishy. The retry logic of unqueue_me only works if we can guarantee, that the original value of q->lock_ptr is always a spinlock (Otherwise we overwrite kernel memory). We know that q->lock_ptr can change. I dont know what happens with the original spinlock, as I am not an expert with the futex code. Signed-off-by: Christian Borntraeger <borntrae@de.ibm.com> Acked-by: Ingo Molnar <mingo@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
maximilian attems authored
The icom driver uses request_firmware() and thus needs to select FW_LOADER. Signed-off-by: maximilian attems <maks@sternwelten.at> Signed-off-by: Olaf Hering <olh@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Alan Cox authored
Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 05 Sep, 2006 8 commits
-
-
Sridhar Samudrala authored
With the recent fix, the callers of sctp_primitive_ABORT() need to create an ABORT chunk and pass it as an argument rather than msghdr that was passed earlier. Adrian Bunk: Ported to 2.6.16. Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Remy Bruno authored
Signed-off-by: Jaroslav Kysela <perex@suse.cz> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Takashi Iwai authored
Call iounmap after free_irq to avoid invalid accesses in the shared irq. The patch is taken from https://bugzilla.novell.com/show_bug.cgi?id=167869Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Takashi Iwai authored
Fix the workaround for AD1988A rev2 codec not to apply to AD1988B codec chips. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <perex@suse.cz> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Takashi Iwai authored
Changed the assigned model for HP dc7600 with ALC260 codec to match better with the actual I/O assignment. Patch taken from ALSA bug#2157. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Takashi Iwai authored
Fixed the missing array terminators in AD1988 codec support code. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <perex@suse.cz> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Takashi Iwai authored
Fix an occasional deadlock occuring with snd-rtctimer driver, added irqsave to the lock in tasklet (ALSA bug#952). Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <perex@suse.cz> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Takashi Iwai authored
Fix 64bit address of MPU401 MMIO port on au88x0 chip. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 31 Aug, 2006 2 commits
-
-
Willy Tarreau authored
The function pointers which were checked were for their get_* counterparts. Typically a copy-paste typo. Signed-off-by: Willy Tarreau <w@1wt.eu> Acked-by: Jeff Garzik <jeff@garzik.org> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Herbert Xu authored
The function ethtool_get_ufo was referring to ETHTOOL_GTSO instead of ETHTOOL_GUFO. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 30 Aug, 2006 6 commits
-
-
Kirill Korotaev authored
2.6.16 leaks like hell. While testing, I found massive filp leakage (reproduced in openvz) in the bowels of namei.c. Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Eric Sandeen authored
blatantly ripped off from Neil Brown's ext2 patch. Signed-off-by: Eric Sandeen <sandeen@sandeen.net> Acked-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Neil Brown authored
The inode number out of an NFS file handle gets passed eventually to ext3_get_inode_block() without any checking. If ext3_get_inode_block() allows it to trigger an error, then bad filehandles can have unpleasant effect - ext3_error() will usually cause a forced read-only remount, or a panic if `errors=panic' was used. So remove the call to ext3_error there and put a matching check in ext3/namei.c where inode numbers are read off storage. Andrew Morton fixed an off-by-one error. Dann Frazier ported the patch to 2.6.16. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Alexey Dobriyan authored
* MODE_MASK is unused in eicon driver. * Conflicts with a ptrace stuff on arm. drivers/isdn/hardware/eicon/divasync.h:259:1: warning: "MODE_MASK" redefined include2/asm/ptrace.h:48:1: warning: this is the location of the previous definition Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Karsten Keil <kkeil@suse.de> Acked-by: Armin Schindler <armin@melware.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Patrick McHardy authored
table->private might change because of ruleset changes, don't use it without holding the lock. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Hannes Reinecke authored
This patch fixes the aic79xx driver to properly respond to BIOS settings. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 27 Aug, 2006 1 commit
-
-
Paul Fulghum authored
Serialize processing of tty buffers in flush_to_ldisc to fix (very rare) corruption of tty buffer free list on SMP systems. Signed-off-by: Paul Fulghum <paulkf@microgate.com> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 26 Aug, 2006 7 commits
-
-
Mark Huang authored
Fix kernel panic on various SMP machines. The culprit is a null ub->skb in ulog_send(). If ulog_timer() has already been scheduled on one CPU and is spinning on the lock, and ipt_ulog_packet() flushes the queue on another CPU by calling ulog_send() right before it exits, there will be no skbuff when ulog_timer() acquires the lock and calls ulog_send(). Cancelling the timer in ulog_send() doesn't help because it has already been scheduled and is running on the first CPU. Similar problem exists in ebt_ulog.c and nfnetlink_log.c. Signed-off-by: Mark Huang <mlhuang@cs.princeton.edu> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Neil Brown authored
At the point where this 'atomic_add' is, rdev could be NULL, as seen by the fact that we test for this in the very next statement. Further is it is really the wrong place of the add. We could add to the count of corrected errors once the are sure it was corrected, not before trying to correct it. Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Tsutomu Fujii authored
Right now, every time we increase our rwnd by more then MTU bytes, we trigger a SACK. When processing large messages, this will generate a SACK for almost every other SCTP fragment. However since we are freeing the entire message at the same time, we might as well collapse the SACK generation to 1. Signed-off-by: Tsutomu Fujii <t-fujii@nb.jp.nec.com> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Vlad Yasevich authored
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Vlad Yasevich authored
When using ASSOCINFO socket option, we need to limit the number of maximum association retransmissions to be no greater than the sum of all the path retransmissions. This is specified in Section 7.1.2 of the SCTP socket API draft. However, we only do this if the association has multiple paths. If there is only one path, the protocol stack will use the assoc_max_retrans setting when trying to retransmit packets. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Neil Horman authored
In the event that our entire receive buffer is full with a series of chunks that represent a single gap-ack, and then we accept a chunk (or chunks) that fill in the gap between the ctsn and the first gap, we renege chunks from the end of the buffer, which effectively does nothing but move our gap to the end of our received tsn stream. This does little but move our missing tsns down stream a little, and, if the sender is sending sufficiently large retransmit frames, the result is a perpetual slowdown which can never be recovered from, since the only chunk that can be accepted to allow progress in the tsn stream necessitates that a new gap be created to make room for it. This leads to a constant need for retransmits, and subsequent receiver stalls. The fix I've come up with is to deliver the frame without reneging if we have a full receive buffer and the receiving sockets sk_receive_queue is empty(indicating that the receive buffer is being blocked by a missing tsn). Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Vlad Yasevich authored
Make SCTP handle broadcast properly Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
- 25 Aug, 2006 1 commit
-
-
Adrian Bunk authored
-
- 23 Aug, 2006 3 commits
-
-
Adrian Bunk authored
-
Danny Tholen authored
Recently a patch was added for preliminary suspend/resume handling on !PPC_PMAC. However, this broke both suspend and firewire on powerpc because it saves the pci state after the device has already been disabled. This moves the save state to before the pmac specific code. Signed-off-by: Danny Tholen <obiwan@mailmij.org> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-
Sridhar Samudrala authored
sctp_make_abort_user() now takes the msg_len along with the msg so that we don't have to recalculate the bytes in iovec. It also uses memcpy_fromiovec() so that we don't go beyond the length allocated. It is good to have this fix even if verify_iovec() is fixed to return error on overflow. Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Acked-by: David Miller <davem@davemloft.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
-