- 04 Nov, 2006 40 commits
-
-
Herbert Xu authored
I was looking at a RHEL5 bug report involving Xen and SCTP (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550). It turns out that SCTP wasn't written to handle skb fragments at all. The absence of any calls to skb_may_pull is testament to that. It just so happens that Xen creates fragmented packets more often than other scenarios (header & data split when going from domU to dom0). That's what caused this bug to show up. Until someone has the time sits down and audits the entire net/sctp directory, here is a conservative and safe solution that simply linearises all packets on input. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
Chris Wright <chrisw@sous-sol.org>
-
Herbert Xu authored
[NET]: Fix segmentation of linear packets skb_segment fails to segment linear packets correctly because it tries to write all linear parts of the original skb into each segment. This will always panic as each segment only contains enough space for one MSS. This was not detected earlier because linear packets should be rare for GSO. In fact it still remains to be seen what exactly created the linear packets that triggered this bug. Basically the only time this should happen is if someone enables GSO emulation on an interface that does not support SG. Signed-off-by:
-
Al Viro authored
several targets have no ....at() family and m32r calls its only chown variant chown32(), with __NR_chown being undefined. creat(2) is also absent in some targets. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Doug Ledford authored
[SCSI] aic7xxx: pause sequencer before touching SBLKCTL Some cards need to pause the sequencer before the SBLKCTL register is touched. This fixes a PCI related oops seen on powerpc macs with this card caused by trying to ascertain the bus signalling before beginning domain validation. Signed-off-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Stephen Hemminger authored
The reason sky2 driver was locking up on transmit on the Yukon-FE chipset is that it was misconfiguring the internal RAM buffer so the transmitter and receiver were sharing the same space. It is a wonder it worked at all! This patch addresses this, and fixes an easily reproducible hang on Transmit. Only the Yukon-FE chip is Marvell 88E803X (10/100 only) are affected. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Zachary Amsden authored
Interrupts must be disabled during alternative instruction patching. On systems with high timer IRQ rates, or when running in an emulator, timing differences can result in random kernel panics because of running partially patched instructions. This doesn't yet fix NMIs, which requires extricating the patch code from the late bug checking and is logically separate (and also less likely to cause problems). Signed-off-by:
Zachary Amsden <zach@vmware.com> Signed-off-by:
-
Miklos Szeredi authored
Fuse didn't always call i_size_write() with i_mutex held which caused rare hangs on SMP/32bit. This bug has been present since fuse-2.2, well before being merged into mainline. The simplest solution is to protect i_size_write() with the per-connection spinlock. Using i_mutex for this purpose would require some restructuring of the code and I'm not even sure it's always safe to acquire i_mutex in all places i_size needs to be set. Since most of vmtruncate is already duplicated for other reasons, duplicate the remaining part as well, making all i_size_write() calls internal to fuse. Using i_size_write() was unnecessary in fuse_init_inode(), since this function is only called on a newly created locked inode. Reported by a few people over the years, but special thanks to Dana Henriksen who was persistent enough in helping me debug it. Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Arthur Kepner authored
We discovered a problem when running IPoIB applications on multiple CPUs on an Altix system. Many messages such as: ib_mthca 0002:01:00.0: SQ 000014 full (19941644 head, 19941707 tail, 64 max, 0 nreq) appear in syslog, and the driver wedges up. Apparently this is because writes to the doorbells from different CPUs reach the device out of order. The following patch adds mmiowb() calls after doorbell rings to ensure the doorbell writes are ordered. Signed-off-by:
Arthur Kepner <akepner@sgi.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Eli Cohen authored
When ipoib_ib_dev_flush() is called because of a port event, the driver needs to rejoin all multicast groups, since the flush will call ipoib_mcast_dev_flush() (via ipoib_ib_dev_down()). Otherwise no (non-broadcast) multicast groups will be rejoined until the networking core calls ->set_multicast_list again, and so multicast reception will be broken for potentially a long time. Signed-off-by:
Eli Cohen <eli@mellanox.co.il> Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
-
James Bottomley authored
[SCSI] aic7xxx: avoid checking SBLKCTL register for certain cards For cards that don't support LVD, checking the SBLKCTL register to determine the bus singalling doesn't work. So, check that the card supports LVD first (AHC_ULTRA2) before checking the register. Signed-off-by:
-
NeilBrown authored
This is a long standing bug that seems to have only recently become apparent, presumably due to increasing use of NFS over TCP - many distros seem to be making it the default. The SK_CONN bit gets set when a listening socket may be ready for an accept, just as SK_DATA is set when data may be available. It is entirely possible for svc_tcp_accept to be called with neither of these set. It doesn't happen often but there is a small race in svc_sock_enqueue as SK_CONN and SK_DATA are tested outside the spin_lock. They could be cleared immediately after the test and before the lock is gained. This normally shouldn't be a problem. The sockets are non-blocking so trying to read() or accept() when ther is nothing to do is not a problem. However: svc_tcp_recvfrom makes the decision "Should I accept() or should I read()" based on whether SK_CONN is set or not. This usually works but is not safe. The decision should be based on whether it is a TCP_LISTEN socket or a TCP_CONNECTED socket. Signed-off-by:
Neil Brown <neilb@suse.de> Signed-off-by:
-
NeilBrown authored
Two less-used md personalities have bugs in the calculation of ->degraded (the extent to which the array is degraded). Signed-off-by:
-
NeilBrown authored
If save_raid_disk is >= 0, then the device could be a device that is already in sync that is being re-added. So we need to default this value to -1. Signed-off-by:
-
Takashi Iwai authored
The va_list is designed to be used only once. The current code may pass va_list arguments multiple times and may cause Oops. Copy/release the arguments temporarily to avoid this problem. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Michael Krufky authored
DVB: fix dvb_pll_attach for mt352/zl10353 in cx88-dvb, and nxt200x Typical wiring of MT352, ZL10353, NXT2002 and NXT2004 based tuners differ from dvb-pll's expectation that the PLL is directly accessible. On these boards, the PLL is actually hidden behind the demodulator, and as such can only be accessed via the demodulator's interface. It was failing to communicate with the PLL during an attach test and subsequently not connecting the tuner ops. By passing a NULL I2C bus handle to dvb_pll_attach, this accessibility check can be bypassed. Do this for the affected boards. Also fix a possible NULL dereference at sleep time, which would otherwise be exposed by this change. This patch has been backported to the 2.6.18.y stable kernel series from the original changesets from Chris Pascoe and Michael Krufky, already present in the upstream 2.6.19 kernel tree. Signed-off-by:
Chris Pascoe <c.pascoe@itee.uq.edu.au> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Michael Buesch authored
This fixes a netdev watchdog timeout problem. The problem is caused by a needed netif_tx_disable in the hardware calibration code and can be shown by the following timegraph. |---5secs - ~10 jiffies time---|---|OOPS ^ ^ last real TX periodic work stops netif At OOPS, the following happens: The watchdog timer triggers, because the timeout of 5secs is over. The watchdog first checks for stopped TX. _Usually_ TX is only stopped from the TX handler to indicate a full TX queue. But this is different. We need to stop TX here, regardless of the TX queue state. So the watchdog recognizes the stopped device and assumes it is stopped due to full TX queues (Which is a _wrong_ assumption in this case). It then tests how far the last TX has been in the past. If it's more than 5secs (which is the case for low or no traffic), it will fire a TX timeout. Acked-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Michael Buesch <mb@bu3sch.de> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
David Miller authored
The second argument to free_npages() was being incorrectly calculated, which would thus access far past the end of the arena->map[] bitmap. Signed-off-by:
-
David Miller authored
1) probe_other_fhcs() wants to see only non-central FHC busses, so skip FHCs that don't sit off the root 2) Like SBUS, FHC can lack the appropriate address and size cell count properties, so add an of_busses[] entry and handlers for that. 3) Central FHC irq translator probing was buggy. We were trying to use dp->child in irq_trans_init but that linkage is not setup at this point. So instead, pass in the parent of "dp" and look for the child "fhc" with parent "central". Thanks to the tireless assistence of Ben Collins in tracking down these problems and testing out these fixes. Signed-off-by:
-
Dave Kleikamp authored
JFS: pageno needs to be long diRead and diWrite are representing the page number as an unsigned int. This causes file system corruption on volumes larger than 16TB. Signed-off-by:
Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by:
-
Marcel Holtmann authored
[Bluetooth] Check if DLC is still attached to the TTY If the DLC device is no longer attached to the TTY device, then it makes no sense to go through with changing the termios settings. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Russell King authored
[SERIAL] Fix oops when removing suspended serial port A serial card might have been removed when the system is resumed. This results in a suspended port being shut down, which results in the ports shutdown method being called twice in a row. This causes BUGs. Avoid this by tracking the suspended state separately from the initialised state. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
maximilian attems <maks@sternwelten.at> Signed-off-by:
-
Russell King authored
Unfortunately, pcmcia_dev_present() returns false when a device is suspended, so checking this on resume does not work too well. Omit this test. the backported patch below is already in fedora tree. -maks Signed-off-by:
-
David Woodhouse authored
The uninitialised pmu_backlight_lock causes the current Fedora test kernel (which has spinlock debugging enabled) to panic on suspend. This is suboptimal, so I fixed it. Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Brian King authored
[SCSI] DAC960: PCI id table fixup The PCI ID table in the DAC960 driver conflicts with some devices that use the ipr driver. All ipr adapters that use this chip have an IBM subvendor ID and all DAC960 adapters that use this chip have a Mylex subvendor id. Signed-off-by:
Brian King <brking@us.ibm.com> Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
Makes UML compile on any possible processor choice. The two problems were: *) x86 code, when 386 is selected, checks at runtime boot_cpuflags, which we do not have. *) 3Dnow support for memcpy() et al. does not compile currently and fixing this is not trivial, so simply disable it; with this change, if one selects MK7 UML compiles (while it did not). Merged upstream. Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Stephen Hemminger authored
This reverts earlier change that attempted to fix flow control. Device needs to discard pause frames, otherwise it passes pause frames up the stack. Signed-off-by:
-
Stephen Hemminger authored
When using flow control, the PHY needs to accept multicast pause frames. Without this fix, these frames were getting discarded by the PHY before doing any flow control. Signed-off-by:
-
Karsten Wiese authored
ALSA: Repair snd-usb-usx2y for usb 2.6.18 urb->start_frame rolls over beyond MAX_INT now. This is for stable kernel and stable alsa. From: Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by:
Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by:
-
Karsten Wiese authored
Fix bug in snd-usb-usx2y's usX2Y_pcms_lock_check() substream can be NULL...... in mainline, bug was introduced by: 2006-06-22 [ALSA] Add O_APPEND flag support to PCM From: Karsten Wiese <annabellesgarden@yahoo.de> Signed-off-by:
-
Florin Malita authored
snd_card_file_remove() may free hw->card so we can't dereference hw->card->module after that. Coverity ID 1420. This bug actually causes an Oops at usb-disconnection, especially with CONFIG_PREEMPT. From: Florin Malita <fmalita@gmail.com> Signed-off-by:
Florin Malita <fmalita@gmail.com> Signed-off-by:
-
Amol Lad authored
From: Amol Lad <amol@verismonetworks.com> Signed-off-by:
Amol Lad <amol@verismonetworks.com> Signed-off-by:
-
Takashi Iwai authored
Fixed Oops when conflictin with aoa driver due to lack of i2c initialization. Signed-off-by:
-
Arnaud Patard authored
The emu10k1 driver saves the A_IOCFG and HCFG register on suspend and restores it on resumes. Unfortunately, this doesn't work as the arguments to outl() are reversed. From: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by:
Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by:
-
Stephen Hemminger authored
When PHY is turned off on shutdown, it can causes the IRQ to get stuck on. Make sure and disable the IRQ first, and if IRQ occurs when device is not running, don't access PHY because that can hang. Signed-off-by:
-
Stephen Hemminger authored
The lower pause threshold set by the driver is too large and causes FIFO overruns. Especially on laptops running at slower clock rates. Signed-off-by:
-
Stephen Hemminger authored
Make sure and do PCI reads after writes in the MSI test setup code. Some motherboards don't implement MSI correctly. The driver handles this but the warning is too verbose and overly cautious. Signed-off-by:
-
Suresh Siddha authored
Failing context is a multi threaded process context and the failing sequence is as follows. One thread T0 doing self modifying code on page X on processor P0 and another thread T1 doing COW (breaking the COW setup as part of just happened fork() in another thread T2) on the same page X on processor P1. T0 doing SMC can endup modifying the new page Y (allocated by the T1 doing COW on P1) but because of different I/D TLB's, P0 ITLB will not see the new mapping till the flush TLB IPI from P1 is received. During this interval, if T0 executes the code created by SMC it can result in an app error (as ITLB still points to old page X and endup executing the content in page X rather than using the content in page Y). Fix this issue by first clearing the PTE and flushing it, before updating it with new entry. Hugh sayeth: I was a bit sceptical, in the habit of thinking that Self Modifying Code must look such issues itself: but I guess there's nothing it can do to avoid this one. Fair enough, what you're changing it to is pretty much what powerpc and s390 were already doing, and is a more robust way of proceeding, consistent with how ptes are set everywhere else. The ptep_clear_flush is a bit heavy-handed (it's anxious to return the pte that was atomically cleared), but we'd have to wander through lots of arches to get the right minimal behaviour. It'd also be nice to eliminate ptep_establish completely, now only used to define other macros/inlines: it always seemed obfuscation to me, what you've got there now is clearer. Let's put those cleanups on a TODO list. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Acked-by:
Hugh Dickins <hugh@veritas.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
Martin Schwidefsky authored
The clocksource infrastructure introduced with commit ad596171 broke 31 bit s390. The reason is that the do_div() primitive for 31 bit always had a restriction: it could only divide an unsigned 64 bit integer by an unsigned 31 bit integer. The clocksource code now uses do_div() with a base value that has the most significant bit set. The result is that clock->cycle_interval has a funny value which causes the linux time to jump around like mad. The solution is "obvious": implement a proper __div64_32 function for 31 bit s390. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Jens Axboe authored
Don't jump to the unlock+release path, we already did that. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Patrick McHardy authored
Dave Jones wrote: > sfuzz D 724EF62A 2828 28717 28691 (NOTLB) > cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0 > dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202 > de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0 > Call Trace: > [<c05b1708>] lock_sock+0x75/0xa6 > [<e0b0b604>] dn_getname+0x18/0x5f [decnet] > [<c05b083b>] sys_getsockname+0x5c/0xb0 > [<c05b0b46>] sys_socketcall+0xef/0x261 > [<c0403f97>] syscall_call+0x7/0xb > DWARF2 unwinder stuck at syscall_call+0x7/0xb > > I wonder if the plethora of lockdep related changes inadvertantly broke something? Looks like unbalanced locking. Acked-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
