]> git.kernelconcepts.de Git - karo-tx-linux.git/log
karo-tx-linux.git
15 years agoAPIC routing fix
Yinghai Lu [Fri, 12 Sep 2008 11:08:18 +0000 (13:08 +0200)]
APIC routing fix

commit e0da33646826b66ef933d47ea2fb7a693fd849bf upstream

x86: introduce max_physical_apicid for bigsmp switching

a multi-socket test-system with 3 or 4 ioapics, when 4 dualcore cpus or
2 quadcore cpus installed, needs to switch to bigsmp or physflat.

CPU apic id is [4,11] instead of [0,7], and we need to check max apic
id instead of cpu numbers.

also add check for 32 bit when acpi is not compiled in or acpi=off.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agosched: fix process time monotonicity
Balbir Singh [Fri, 5 Sep 2008 16:12:23 +0000 (18:12 +0200)]
sched: fix process time monotonicity

commit 49048622eae698e5c4ae61f7e71200f265ccc529 upstream

Spencer reported a problem where utime and stime were going negative despite
the fixes in commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. The suspected
reason for the problem is that signal_struct maintains it's own utime and
stime (of exited tasks), these are not updated using the new task_utime()
routine, hence sig->utime can go backwards and cause the same problem
to occur (sig->utime, adds tsk->utime and not task_utime()). This patch
fixes the problem

TODO: using max(task->prev_utime, derived utime) works for now, but a more
generic solution is to implement cputime_max() and use the cputime_gt()
function for comparison.

Reported-by: spencer@bluehost.com
Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoblock: submit_bh() inadvertently discards barrier flag on a sync write
Jens Axboe [Wed, 3 Sep 2008 23:49:10 +0000 (19:49 -0400)]
block: submit_bh() inadvertently discards barrier flag on a sync write

commit 48fd4f93a00eac844678629f2f00518e146ed30d upstream

Reported by Milan Broz <mbroz@redhat.com>, commit 18ce3751 inadvertently
made submit_bh() discard the barrier bit for a WRITE_SYNC request. Fix
that up.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agox86: Fix broken LDT access in VMI
Zachary Amsden [Wed, 1 Oct 2008 16:45:04 +0000 (16:45 +0000)]
x86: Fix broken LDT access in VMI

commit de59985e3a623d4d5d6207f1777398ca0606ab1c upstream

After investigating a JRE failure, I found this bug was introduced a
long time ago, and had already managed to survive another bugfix which
occurred on the same line.  The result is a total failure of the JRE due
to LDT selectors not working properly.

This one took a long time to rear up because LDT usage is not very
common, but the bug is quite serious.  It got introduced along with
another bug, already fixed, by 75b8bb3e56ca09a467fbbe5229bc68627f7445be

Signed-off-by: Zachary Amsden <zach@vmware.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Glauber de Oliveira Costa <gcosta@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agox64, fpu: fix possible FPU leakage in error conditions
Suresh Siddha [Wed, 1 Oct 2008 00:56:13 +0000 (17:56 -0700)]
x64, fpu: fix possible FPU leakage in error conditions

[Upstream commit: 6ffac1e90a17ea0aded5c581204397421eec91b6]

On Thu, Jul 24, 2008 at 03:43:44PM -0700, Linus Torvalds wrote:
> So how about this patch as a starting point? This is the RightThing(tm) to
> do regardless, and if it then makes it easier to do some other cleanups,
> we should do it first. What do you think?

restore_fpu_checking() calls init_fpu() in error conditions.

While this is wrong(as our main intention is to clear the fpu state of
the thread), this was benign before commit 92d140e21f1 ("x86: fix taking
DNA during 64bit sigreturn").

Post commit 92d140e21f1, live FPU registers may not belong to this
process at this error scenario.

In the error condition for restore_fpu_checking() (especially during the
64bit signal return), we are doing init_fpu(), which saves the live FPU
register state (possibly belonging to some other process context) into
the thread struct (through unlazy_fpu() in init_fpu()). This is wrong
and can leak the FPU data.

For the signal handler restore error condition in restore_i387(), clear
the fpu state present in the thread struct(before ultimately sending a
SIGSEGV for badframe).

For the paranoid error condition check in math_state_restore(), send a
SIGSEGV, if we fail to restore the state.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agox86-64: Clean up save/restore_i387() usage
Linus Torvalds [Wed, 1 Oct 2008 00:56:12 +0000 (17:56 -0700)]
x86-64: Clean up save/restore_i387() usage

[ Upstream commit b30f3ae50cd03ef2ff433a5030fbf88dd8323528]

Suresh Siddha wants to fix a possible FPU leakage in error conditions,
but the fact that save/restore_i387() are inlines in a header file makes
that harder to do than necessary.  So start off with an obvious cleanup.

This just moves the x86-64 version of save/restore_i387() out of the
header file, and moves it to the only file that it is actually used in:
arch/x86/kernel/signal_64.c.  So exposing it in a header file was wrong
to begin with.

[ Side note: I'd like to fix up some of the games we play with the
  32-bit version of these functions too, but that's a separate
  matter.  The 32-bit versions are shared - under different names
  at that! - by both the native x86-32 code and the x86-64 32-bit
  compatibility code ]

Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoKVM: SVM: fix guest global tlb flushes with NPT
Joerg Roedel [Sat, 13 Sep 2008 05:38:42 +0000 (08:38 +0300)]
KVM: SVM: fix guest global tlb flushes with NPT

(cherry picked from commit e5eab0cede4b1ffaca4ad857d840127622038e55)

Accesses to CR4 are intercepted even with Nested Paging enabled. But the code
does not check if the guest wants to do a global TLB flush. So this flush gets
lost. This patch adds the check and the flush to svm_set_cr4.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoKVM: SVM: fix random segfaults with NPT enabled
Joerg Roedel [Sat, 13 Sep 2008 05:38:41 +0000 (08:38 +0300)]
KVM: SVM: fix random segfaults with NPT enabled

(cherry picked from commit 44874f84918e37b64bec6df1587e5fe2fdf6ab62)

This patch introduces a guest TLB flush on every NPF exit in KVM. This fixes
random segfaults and #UD exceptions in the guest seen under some workloads
(e.g. long running compile workloads or tbench). A kernbench run with and
without that fix showed that it has a slowdown lower than 0.5%

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoALSA: remove unneeded power_mutex lock in snd_pcm_drop
Takashi Iwai [Tue, 30 Sep 2008 09:54:12 +0000 (11:54 +0200)]
ALSA: remove unneeded power_mutex lock in snd_pcm_drop

Upstream-commit-id: 24e8fc498e9618338854bfbcf8d1d737e0bf1775

The power_mutex lock in snd_pcm_drop may cause a possible deadlock
chain, and above all, it's unneeded.  Let's get rid of it.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoALSA: fix locking in snd_pcm_open*() and snd_rawmidi_open*()
Takashi Iwai [Tue, 30 Sep 2008 09:52:57 +0000 (11:52 +0200)]
ALSA: fix locking in snd_pcm_open*() and snd_rawmidi_open*()

Upstream-commit-id: 399ccdc1cd4e92e541d4dacbbf18c52bd693418b

The PCM and rawmidi open callbacks have a lock against card->controls_list
but it takes a wrong one, card->controls_rwsem, instead of a right one
card->ctl_files_rwlock.  This patch fixes them.

This change also fixes automatically the potential deadlocks due to
mm->mmap_sem in munmap and copy_from/to_user, reported by Sitsofe
Wheeler:

  A: snd_ctl_elem_user_tlv(): card->controls_rwsem => mm->mmap_sem
  B: snd_pcm_open(): card->open_mutex => card->controls_rwsem
  C: munmap: mm->mmap_sem => snd_pcm_release(): card->open_mutex

The patch breaks the chain.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoALSA: oxygen: fix distorted output on AK4396-based cards
Clemens Ladisch [Tue, 30 Sep 2008 09:50:35 +0000 (11:50 +0200)]
ALSA: oxygen: fix distorted output on AK4396-based cards

Upstream-commit-id: df91bc23dcb052ff2da71b3482bf3c5fbf4b8a53

When changing the sample rate, the CMI8788's master clock output becomes
unstable for a short time.  The AK4396 needs the master clock to do SPI
writes, so writing to an AK4396 control register directly after a sample
rate change will garble the value.  In our case, this leads to the DACs
being misconfigured to I2S sample format, which results in a wrong
output level and horrible distortions on samples louder than -6 dB.

To fix this, we need to wait until the new master clock signal has
become stable before doing SPI writes.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoALSA: hda - Fix model for Dell Inspiron 1525
Takashi Iwai [Tue, 30 Sep 2008 18:15:10 +0000 (18:15 +0000)]
ALSA: hda - Fix model for Dell Inspiron 1525

commit 24918b61b55c21e09a3e07cd82e1b3a8154782dc upstream

Dell Inspiron 1525 seems to have a buggy BIOS setup and screws up
the recent codec parser, as reported by Oleksandr Natalenko:
    http://lkml.org/lkml/2008/9/12/203

This patch adds the working model, dell-3stack, statically.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoSCSI: qla2xxx: Defer enablement of RISC interrupts until ISP initialization completes.
Andrew Vasquez [Mon, 29 Sep 2008 15:15:04 +0000 (15:15 +0000)]
SCSI: qla2xxx: Defer enablement of RISC interrupts until ISP initialization completes.

commit 048feec5548c0582ee96148c61b87cccbcb5f9be upstream

Josip Rodin noted
(http://article.gmane.org/gmane.linux.ports.sparc/10152) the
driver oopsing during registration of an rport to the
FC-transport layer with a backtrace indicating a dereferencing of
an shost->shost_data equal to NULL.  David Miller identified a
small window in driver logic where this could happen:

    > Look at how the driver registers the IRQ handler before the host has
    > been registered with the SCSI layer.
    >
    > That leads to a window of time where the shost hasn't been setup
    > fully, yet ISRs can come in and trigger DPC thread events, such as
    > loop resyncs, which expect the transport area to be setup.
    >
    > But it won't be setup, because scsi_add_host() hasn't finished yet.
    >
    > Note that in Josip's crash log, we don't even see the
    >
    >         qla_printk(KERN_INFO, ha, "\n"
    >             " QLogic Fibre Channel HBA Driver: %s\n"
    >             "  QLogic %s - %s\n"
    >             "  ISP%04X: %s @ %s hdma%c, host#=%ld, fw=%s\n",
    >  ...
    >
    > message yet.
    >
    > Which means that the crash occurs between qla2x00_request_irqs()
    > and printing that message.

Close this window by enabling RISC interrupts after the host has
been registered with the SCSI midlayer.

Reported-by: Josip Rodin <joy@entuzijast.net>
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoUSB: fix hcd interrupt disabling
Geoff Levand [Tue, 23 Sep 2008 22:05:34 +0000 (22:05 +0000)]
USB: fix hcd interrupt disabling

commit 83a798207361cc26385187b2e71efa2b5d75de7f upstream

Commit de85422b94ddb23c021126815ea49414047c13dc, 'USB: fix interrupt
disabling for HCDs with shared interrupt handlers' changed usb_add_hcd()
to strip IRQF_DISABLED from irqflags prior to calling request_irq()
with the justification that such a removal was necessary for shared
interrupts to work properly.  Unfortunately, the change in that commit
unconditionally removes the IRQF_DISABLED flag, causing problems on
platforms that don't use a shared interrupt but require IRQF_DISABLED.
This change adds a check for IRQF_SHARED prior to removing the
IRQF_DISABLED flag.

Fixes the PS3 system startup hang reported with recent Fedora and
OpenSUSE kernels.

Note that this problem is hidden when CONFIG_LOCKDEP=y (ps3_defconfig),
as local_irq_enable_in_hardirq() is defined as a null statement for
that config.

Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Stefan Becker <Stefan.Becker@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agosmb.h: do not include linux/time.h in userspace
Kirill A. Shutemov [Tue, 23 Sep 2008 17:25:04 +0000 (17:25 +0000)]
smb.h: do not include linux/time.h in userspace

commit c32a162fd420fe8dfb049db941b2438061047fcc upstream

linux/time.h conflicts with time.h from glibc

It breaks building smbmount from samba.  It's regression introduced by
commit 76308da (" smb.h: uses struct timespec but didn't include
linux/time.h").

Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agopxa2xx_spi: fix build breakage
Mike Rapoport [Wed, 1 Oct 2008 17:39:24 +0000 (10:39 -0700)]
pxa2xx_spi: fix build breakage

commit 20b918dc77b383e9779dafceee3f2198a6f7b0e5 upstream

This patch fixes a build error in the pxa2xx-spi driver,
introduced by commit 7e96445533ac3f4f7964646a202ff3620602fab4
("pxa2xx_spi: dma bugfixes")

  CC      drivers/spi/pxa2xx_spi.o
drivers/spi/pxa2xx_spi.c: In function 'map_dma_buffers':
drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary &
drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary &
drivers/spi/pxa2xx_spi.c: In function 'pump_transfers':
drivers/spi/pxa2xx_spi.c:897: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int'

[dbrownell@users.sourceforge.net: fix warning too ]

Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agopxa2xx_spi: chipselect bugfixes
Ned Forrester [Sat, 13 Sep 2008 22:05:54 +0000 (22:05 +0000)]
pxa2xx_spi: chipselect bugfixes

commit 8423597d676615f3dd2d9ab36f59f147086b90b8 upstream

Fixes several chipselect bugs in the pxa2xx_spi driver.  These bugs are in
all versions of this driver and prevent using it with chips like m25p16
flash.

 1. The spi_transfer.cs_change flag is handled too early:
    before spi_transfer.delay_usecs applies, thus making the
    delay ineffective at holding chip select.

 2. spi_transfer.delay_usecs is ignored on the last transfer
    of a message (likewise not holding chipselect long enough).

 3. If spi_transfer.cs_change is set on the last transfer, the
    chip select is always disabled, instead of the intended
    meaning: optionally holding chip select enabled for the
    next message.

Those first three bugs were fixed with a relocation of delays
and chip select de-assertions.

 4. If a message has the cs_change flag set on the last transfer,
    and had the chip select stayed enabled as requested (see 3,
    above), it would not have been disabled if the next message is
    for a different chip.  Fixed by dropping chip select regardless
    of cs_change at end of a message, if there is no next message
    or if the next message is for a different chip.

This patch should apply to all kernels back to and including 2.6.20;
it was test patched against 2.6.20.  An additional patch would be
required for older kernels, but those versions are very buggy anyway.

Signed-off-by: Ned Forrester <nforrester@whoi.edu>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agopxa2xx_spi: dma bugfixes
Ned Forrester [Sat, 13 Sep 2008 22:05:47 +0000 (22:05 +0000)]
pxa2xx_spi: dma bugfixes

commit 7e96445533ac3f4f7964646a202ff3620602fab4 upstream

Fixes two DMA bugs in the pxa2xx_spi driver.  The first bug is in all
versions of this driver; the second was introduced in the 2.6.20 kernel,
and prevents using the driver with chips like m25p16 flash (which can
issue large DMA reads).

 1. Zero length transfers are permitted for use to insert timing,
    but pxa2xx_spi.c will fail if this is requested in DMA mode.
    Fixed by using programmed I/O (PIO) mode for such transfers.

 2. Transfers larger than 8191 are not permitted in DMA mode.  A
    test for length rejects all large transfers regardless of DMA
    or PIO mode.  Worked around by rejecting only large transfers
    with DMA mapped buffers, and forcing all other transfers
    larger than 8191 to use PIO mode.  A rate limited warning is
    issued for DMA transfers forced to PIO mode.

This patch should apply to all kernels back to and including 2.6.20;
it was test patched against 2.6.20.  An additional patch would be
required for older kernels, but those versions are very buggy anyway.

Signed-off-by: Ned Forrester <nforrester@whoi.edu>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agomm: mark the correct zone as full when scanning zonelists
Mel Gorman [Sat, 13 Sep 2008 22:05:39 +0000 (22:05 +0000)]
mm: mark the correct zone as full when scanning zonelists

commit 5bead2a0680687b9576d57c177988e8aa082b922 upstream

The iterator for_each_zone_zonelist() uses a struct zoneref *z cursor when
scanning zonelists to keep track of where in the zonelist it is.  The
zoneref that is returned corresponds to the the next zone that is to be
scanned, not the current one.  It was intended to be treated as an opaque
list.

When the page allocator is scanning a zonelist, it marks elements in the
zonelist corresponding to zones that are temporarily full.  As the
zonelist is being updated, it uses the cursor here;

  if (NUMA_BUILD)
        zlc_mark_zone_full(zonelist, z);

This is intended to prevent rescanning in the near future but the zoneref
cursor does not correspond to the zone that has been found to be full.
This is an easy misunderstanding to make so this patch corrects the
problem by changing zoneref cursor to be the current zone being scanned
instead of the next one.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoasync_tx: fix the bug in async_tx_run_dependencies
Yuri Tikhonov [Sat, 6 Sep 2008 01:10:06 +0000 (01:10 +0000)]
async_tx: fix the bug in async_tx_run_dependencies

commit de24125dd0a452bfd4502fc448e3534c5d2e87aa upstream

Should clear the next pointer of the TX if we are sure that the
next TX (say NXT) will be submitted to the channel too. Overwise,
we break the chain of descriptors, because we lose the information
about the next descriptor to run. So next time, when invoke
async_tx_run_dependencies() with TX, it's TX->next will be NULL, and
NXT will be never submitted.

Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agodrivers/mmc/card/block.c: fix refcount leak in mmc_block_open()
Andrew Morton [Sat, 6 Sep 2008 01:10:03 +0000 (01:10 +0000)]
drivers/mmc/card/block.c: fix refcount leak in mmc_block_open()

commit 70bb08962ea9bd50797ae9f16b2493f5f7c65053 upstream

mmc_block_open() increments md->usage although it returns with -EROFS when
default mounting a MMC/SD card with write protect switch on.  This
reference counting bug prevents /dev/mmcblkX from being released on card
removal, and situation worsen with reinsertion until the minor number
range runs out.

Reported-by: <sasin@solomon-systech.com>
Acked-by: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoixgbe: initialize interrupt throttle rate
Andy Gospodarek [Thu, 4 Sep 2008 01:05:06 +0000 (01:05 +0000)]
ixgbe: initialize interrupt throttle rate

commit 15e79f24b60c4b0bf8019423bda4e03a576b02f2 upstream

This commit dropped the setting of the default interrupt throttle rate.

commit 021230d40ae0e6508d6c717b6e0d6d81cd77ac25
Author: Ayyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Date:   Mon Mar 3 15:03:45 2008 -0800

    ixgbe: Introduce MSI-X queue vector code

The following patch adds it back.  Without this the default value of 0
causes the performance of this card to be awful.  Restoring these to the
default values yields much better performance.

This regression has been around since 2.6.25.

Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoi2c-dev: Return correct error code on class_create() failure
Sven Wegener [Sun, 28 Sep 2008 12:14:21 +0000 (14:14 +0200)]
i2c-dev: Return correct error code on class_create() failure

In Linus' tree:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commit;h=e74783ec3cb981211689bd2cfd3248f8dc48ec01

We need to convert the error pointer from class_create(), else we'll return the
successful return code from register_chrdev() on failure.

Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agoACPI: Fix thermal shutdowns
Milan Broz [Wed, 3 Sep 2008 23:41:12 +0000 (19:41 -0400)]
ACPI: Fix thermal shutdowns

commit 9f497bcc695fb828da023d74ad3c966b1e58ad21 upstream

ACPI: Fix thermal shutdowns

Do not use unsigned int if there is test for negative number...

See drivers/acpi/processor_perflib.c
  static unsigned int ignore_ppc = -1;
...
  if (event == CPUFREQ_START && ignore_ppc <= 0) {
       ignore_ppc = 0;
...

Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
15 years agox86-32: AMD c1e force timer broadcast late
Chuck Ebbert [Wed, 3 Sep 2008 23:34:59 +0000 (19:34 -0400)]
x86-32: AMD c1e force timer broadcast late

This patch is not needed in 2.6.27 because it has new c1e-aware idle code.

In kernel 2.6.26 the 32-bit x86 timers are started earlier than before.
This breaks AMD c1e detection trying to force timer broadcast for the
local apic timer. Copy the code from the 64-bit kernel to force timer
broadcast late.

Reference:
http://bugzilla.kernel.org/show_bug.cgi?id=11427

Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoLinux 2.6.26.5 v2.6.26.5
Greg Kroah-Hartman [Mon, 8 Sep 2008 17:40:20 +0000 (10:40 -0700)]
Linux 2.6.26.5

16 years agoNET: fix build error caused by Greg K-H
Greg Kroah-Hartman [Mon, 8 Sep 2008 17:17:15 +0000 (10:17 -0700)]
NET: fix build error caused by Greg K-H

This resolves the build error introduced in
97348238e1f470b200d4b810becaaa4147c6db51 due to Greg applying the the
incorrect patch.

Thanks to Randy Dunlap for reporting this.

Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoLinux 2.6.26.4 v2.6.26.4
Greg Kroah-Hartman [Mon, 8 Sep 2008 11:44:46 +0000 (04:44 -0700)]
Linux 2.6.26.4

16 years agosata_mv: don't issue two DMA commands concurrently
Tejun Heo [Wed, 13 Aug 2008 11:24:16 +0000 (20:24 +0900)]
sata_mv: don't issue two DMA commands concurrently

commit 4bdee6c5103696a2729d3db2f235d202191788e4 upstream

sata_mv allowed issuing two DMA commands concurrently which the
hardware allows.  Unfortunately, libata core layer isn't ready for
this yet and spews ugly warning message and malfunctions on this.
Don't allow concurrent DMA commands for now.

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Cc: Martin Michlmayr <tbm@cyrius.com>
Cc: Mark Lord <liml@rtr.ca>
Cc: Artem Bokhan <aptem@ngs.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoKVM: MMU: Fix torn shadow pte
Avi Kivity [Tue, 26 Aug 2008 08:05:28 +0000 (11:05 +0300)]
KVM: MMU: Fix torn shadow pte

(cherry picked from commit cd5998ebfbc9e6cb44408efa217c15d7eea13675)

The shadow code assigns a pte directly in one place, which is nonatomic on
i386 can can cause random memory references.  Fix by using an atomic setter.

Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agox86: work around MTRR mask setting, v2
Ingo Molnar [Wed, 3 Sep 2008 00:54:10 +0000 (17:54 -0700)]
x86: work around MTRR mask setting, v2

commit 9754a5b840a209bc1f192d59f63e81b698a55ac8 upstream

x86: work around MTRR mask setting, v2

improve the debug printout:

- make it actually display something
- print it only once

would be nice to have a WARN_ONCE() facility, to feed such things to
kerneloops.org.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agonfsd: fix buffer overrun decoding NFSv4 acl
J. Bruce Fields [Mon, 1 Sep 2008 18:51:02 +0000 (14:51 -0400)]
nfsd: fix buffer overrun decoding NFSv4 acl

commit 91b80969ba466ba4b915a4a1d03add8c297add3f upstream

The array we kmalloc() here is not large enough.

Thanks to Johann Dahm and David Richter for bug report and testing.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: David Richter <richterd@citi.umich.edu>
Tested-by: Johann Dahm <jdahm@umich.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports
Cyrill Gorcunov [Mon, 1 Sep 2008 18:51:01 +0000 (14:51 -0400)]
sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports

commit 27df6f25ff218072e0e879a96beeb398a79cdbc8 upstream

Vegard Nossum reported
----------------------
> I noticed that something weird is going on with /proc/sys/sunrpc/transports.
> This file is generated in net/sunrpc/sysctl.c, function proc_do_xprt(). When
> I "cat" this file, I get the expected output:
>    $ cat /proc/sys/sunrpc/transports
>    tcp 1048576
>    udp 32768

> But I think that it does not check the length of the buffer supplied by
> userspace to read(). With my original program, I found that the stack was
> being overwritten by the characters above, even when the length given to
> read() was just 1.

David Wagner added (among other things) that copy_to_user could be
probably used here.

Ingo Oeser suggested to use simple_read_from_buffer() here.

The conclusion is that proc_do_xprt doesn't check for userside buffer
size indeed so fix this by using Ingo's suggestion.

Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
CC: Ingo Oeser <ioe-lkml@rameria.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Cc: Greg Banks <gnb@sgi.com>
Cc: Tom Tucker <tom@opengridcomputing.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agor8169: balance pci_map / pci_unmap pair
Francois Romieu [Thu, 28 Aug 2008 20:55:33 +0000 (22:55 +0200)]
r8169: balance pci_map / pci_unmap pair

commit a866bbf6aacf95f849810079442a20be118ce905 upstream

The leak hurts with swiotlb and jumbo frames.

Fix http://bugzilla.kernel.org/show_bug.cgi?id=9468.

Heavily hinted by Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Alistair John Strachan <alistair@devzero.co.uk>
Tested-by: Timothy J Fontaine <tjfontaine@atxconsulting.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agotg3: Fix firmware event timeouts
Matt Carlson [Fri, 15 Aug 2008 21:10:04 +0000 (14:10 -0700)]
tg3: Fix firmware event timeouts

patch 4ba526ced990f4d61ee8d65fe8a6f0745e8e455c upstream

The git commit 7c5026aa9b81dd45df8d3f4e0be73e485976a8b6 ("tg3: Add
link state reporting to UMP firmware") introduced code that waits for
previous firmware events to be serviced before attempting to submit a
new event.  Unfortunately that patch contained a bug that cause the
driver to wait 2.5 seconds, rather than 2.5 milliseconds as intended.
This patch fixes that bug.

This bug revealed that not all firmware versions service driver events
though.  Since we do not know which versions of the firmware do and don't
service these events, the driver needs some way to minimize the effects
of the delay.  This patch solves the problem by recording a jiffies
timestamp when it submits an event to the hardware.  If the jiffies
counter shows that 2.5 milliseconds have already passed, a wait is not
needed and the driver can proceed to submit a new event.

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agocrypto: authenc - Avoid using clobbered request pointer
Herbert Xu [Fri, 22 Aug 2008 23:36:17 +0000 (09:36 +1000)]
crypto: authenc - Avoid using clobbered request pointer

crypto: authenc - Avoid using clobbered request pointer

[ Upstream commit: a697690bece75d4ba424c1318eb25c37d41d5829 ]

Authenc works in two stages for encryption, it first encrypts and
then computes an ICV.  The context memory of the request is used
by both operations.  The problem is that when an asynchronous
encryption completes, we will compute the ICV and then reread the
context memory of the encryption to get the original request.

It just happens that we have a buffer of 16 bytes in front of the
request pointer, so ICVs of 16 bytes (such as SHA1) do not trigger
the bug.  However, any attempt to uses a larger ICV instantly kills
the machine when the first asynchronous encryption is completed.

This patch fixes this by saving the request pointer before we start
the ICV computation.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Fix cmdline_memory_size handling bugs.
David S. Miller [Wed, 3 Sep 2008 08:21:23 +0000 (01:21 -0700)]
sparc64: Fix cmdline_memory_size handling bugs.

[ Upstream commit f2b6079464fc73cf12f08248180a618f05033a70 ]

First, lmb_enforce_memory_limit() interprets it's argument
(mostly, heh) as a size limit not an address limit.  So pass
the raw cmdline_memory_size value into it.  And we don't
need to check it against zero, lmb_enforce_memory_limit() does
that for us.

Next, free_initmem() needs special handling when the kernel
command line trims the available memory.  The problem case is
if the trimmed out memory is where the kernel image itself
resides.

When that memory is trimmed out, we don't add those physical
ram areas to the sparsemem active ranges, amongst other things.
Which means that this free_initmem() code will free up invalid
page structs, resulting in either crashes or hangs.

Just quick fix this by not freeing initmem at all if "mem="
was given on the boot command line.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Fix overshoot in nid_range().
David S. Miller [Wed, 3 Sep 2008 08:20:37 +0000 (01:20 -0700)]
sparc64: Fix overshoot in nid_range().

[ Upstream commit c918dcce92f76bb9903e4d049f4780bad384c207 ]

If 'start' does not begin on a page boundary, we can overshoot
past 'end'.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoipsec: Fix deadlock in xfrm_state management.
David S. Miller [Wed, 3 Sep 2008 08:03:39 +0000 (01:03 -0700)]
ipsec: Fix deadlock in xfrm_state management.

[ Upstream commit 37b08e34a98c664bea86e3fae718ac45a46b7276 ]

Ever since commit 4c563f7669c10a12354b72b518c2287ffc6ebfb3
("[XFRM]: Speed up xfrm_policy and xfrm_state walking") it is
illegal to call __xfrm_state_destroy (and thus xfrm_state_put())
with xfrm_state_lock held.  If we do, we'll deadlock since we
have the lock already and __xfrm_state_destroy() tries to take
it again.

Fix this by pushing the xfrm_state_put() calls after the lock
is dropped.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosctp: fix random memory dereference with SCTP_HMAC_IDENT option.
Vlad Yasevich [Wed, 3 Sep 2008 08:02:37 +0000 (01:02 -0700)]
sctp: fix random memory dereference with SCTP_HMAC_IDENT option.

[ Upstream commit d97240552cd98c4b07322f30f66fd9c3ba4171de ]

The number of identifiers needs to be checked against the option
length.  Also, the identifier index provided needs to be verified
to make sure that it doesn't exceed the bounds of the array.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosctp: correct bounds check in sctp_setsockopt_auth_key
Vlad Yasevich [Wed, 3 Sep 2008 08:02:19 +0000 (01:02 -0700)]
sctp: correct bounds check in sctp_setsockopt_auth_key

[ Upstream commit 328fc47ea0bcc27d9afa69c3ad6e52431cadd76c ]

The bonds check to prevent buffer overlflow was not exactly
right.  It still allowed overflow of up to 8 bytes which is
sizeof(struct sctp_authkey).

Since optlen is already checked against the size of that struct,
we are guaranteed not to cause interger overflow either.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agonet: Unbreak userspace which includes linux/mroute.h
David S. Miller [Wed, 3 Sep 2008 08:01:01 +0000 (01:01 -0700)]
net: Unbreak userspace which includes linux/mroute.h

[ Upstream commit 7c19a3d280297d43ef5ff7c6b205dc208a16d3d1 ]

This essentially reverts two commits:

1) 2e8046271f68198dd37451017c1a4a2432e4ec68 ("[IPV4] MROUTE: Move PIM
   definitions to <linux/pim.h>.")

and

2) 80a9492a33dd7d852465625022d56ff76d62174d ("[IPV4] MROUTE: Adjust
   include files for user-space.")

which broke userpsace, in particular the XORP build as reported by
Jose Calhariz, the debain package maintainer for XORP.

Nothing originally in linux/mroute.h was exported to userspace
ever, but some of this stuff started to be when it was moved into
this new linux/pim.h, and that was wrong.  If we didn't provide these
definitions for 10 years we can reasonable expect that applications
defined this stuff locally or used GLIBC headers providing the
protocol definitions.  And as such the only result of this can
be conflict and userland build breakage.

The commit #1 had such a short and terse commit message, that we
cannot even know why such a move and set of new userland exports were
even made.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosch_prio: Fix nla_parse_nested_compat() regression
Thomas Graf [Wed, 3 Sep 2008 08:00:02 +0000 (01:00 -0700)]
sch_prio: Fix nla_parse_nested_compat() regression

[ No upstream commit, this is fixing code no longer in 2.6.27 ]

nla_parse_nested_compat() was used to parse two different message
formats in the netem and prio qdisc, when it was "fixed" to work
with netem, it broke the multi queue support in the prio qdisc.
Since the prio qdisc code in question is already removed in the
development tree, this patch only fixes the regression in the
stable tree.

Based on original patch from Alexander H Duyck <alexander.h.duyck@intel.com>

Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosctp: add verification checks to SCTP_AUTH_KEY option
Vlad Yasevich [Thu, 28 Aug 2008 05:41:52 +0000 (22:41 -0700)]
sctp: add verification checks to SCTP_AUTH_KEY option

[ Upstream commit 30c2235cbc477d4629983d440cdc4f496fec9246 ]

The structure used for SCTP_AUTH_KEY option contains a
length that needs to be verfied to prevent buffer overflow
conditions.  Spoted by Eugene Teo <eteo@redhat.com>.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Eugene Teo <eugeneteo@kernel.sg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosctp: fix potential panics in the SCTP-AUTH API.
Vlad Yasevich [Thu, 28 Aug 2008 05:41:00 +0000 (22:41 -0700)]
sctp: fix potential panics in the SCTP-AUTH API.

[ Upstream commit 5e739d1752aca4e8f3e794d431503bfca3162df4 ]

All of the SCTP-AUTH socket options could cause a panic
if the extension is disabled and the API is envoked.

Additionally, there were some additional assumptions that
certain pointers would always be valid which may not
always be the case.

This patch hardens the API and address all of the crash
scenarios.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoudp: Drop socket lock for encapsulated packets
Herbert Xu [Thu, 28 Aug 2008 05:40:04 +0000 (22:40 -0700)]
udp: Drop socket lock for encapsulated packets

[ Upstream commit d97106ea52aa57e63ff40d04479016836bbb5a4e ]

The socket lock is there to protect the normal UDP receive path.
Encapsulation UDP sockets don't need that protection.  In fact
the locking is deadly for them as they may contain another UDP
packet within, possibly with the same addresses.

Also the nested bit was copied from TCP.  TCP needs it because
of accept(2) spawning sockets.  This simply doesn't apply to UDP
so I've removed it.

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>
16 years agopkt_sched: Fix actions referencing
Jamal Hadi Salim [Thu, 28 Aug 2008 05:38:11 +0000 (22:38 -0700)]
pkt_sched: Fix actions referencing

[ Upstream commit 76aab2c1eae491a5d73ac83deec97dd28ebac584 ]

When an action is added several times with the same exact index
it gets deleted on every even-numbered attempt.
This fixes that issue.

Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agopkt_sched: Fix return value corruption in HTB and TBF.
David S. Miller [Thu, 28 Aug 2008 05:35:56 +0000 (22:35 -0700)]
pkt_sched: Fix return value corruption in HTB and TBF.

[ Upstream commit 69747650c814a8a79fef412c7416adf823293a3e ]

Based upon a bug report by Josip Rodin.

Packet schedulers should only return NET_XMIT_DROP iff
the packet really was dropped.  If the packet does reach
the device after we return NET_XMIT_DROP then TCP can
crash because it depends upon the enqueue path return
values being accurate.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agonetns: Add network namespace argument to rt6_fill_node() and ipv6_dev_get_saddr()
Brian Haley [Thu, 28 Aug 2008 05:30:52 +0000 (22:30 -0700)]
netns: Add network namespace argument to rt6_fill_node() and ipv6_dev_get_saddr()

[ Upstream commit 191cd582500f49b32a63040fedeebb0168c720af ]

ipv6_dev_get_saddr() blindly de-references dst_dev to get the network
namespace, but some callers might pass NULL.  Change callers to pass a
namespace pointer instead.

Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoipv6: Fix OOPS, ip -f inet6 route get fec0::1, linux-2.6.26, ip6_route_output, rt6_fi...
Brian Haley [Thu, 28 Aug 2008 05:30:08 +0000 (22:30 -0700)]
ipv6: Fix OOPS, ip -f inet6 route get fec0::1, linux-2.6.26, ip6_route_output, rt6_fill_node+0x175

[ Upstream commit 5e0115e500fe9dd2ca11e6f92db9123204f1327a ]

Alexey Dobriyan wrote:
> On Thu, Aug 07, 2008 at 07:00:56PM +0200, John Gumb wrote:
>> Scenario: no ipv6 default route set.
>
>> # ip -f inet6 route get fec0::1
>>
>> BUG: unable to handle kernel NULL pointer dereference at 00000000
>> IP: [<c0369b85>] rt6_fill_node+0x175/0x3b0
>> EIP is at rt6_fill_node+0x175/0x3b0
>
> 0xffffffff80424dd3 is in rt6_fill_node (net/ipv6/route.c:2191).
> 2186                    } else
> 2187    #endif
> 2188                            NLA_PUT_U32(skb, RTA_IIF, iif);
> 2189            } else if (dst) {
> 2190                    struct in6_addr saddr_buf;
> 2191      ====>         if (ipv6_dev_get_saddr(ip6_dst_idev(&rt->u.dst)->dev,
>        ^^^^^^^^^^^^^^^^^^^^^^^^
> NULL
>
> 2192                                           dst, 0, &saddr_buf) == 0)
> 2193                            NLA_PUT(skb, RTA_PREFSRC, 16, &saddr_buf);
> 2194            }

The commit that changed this can't be reverted easily, but the patch
below works for me.

Fix NULL de-reference in rt6_fill_node() when there's no IPv6 input
device present in the dst entry.

Signed-off-by: Brian Haley <brian.haley@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoAX.25: Fix sysctl registration if !CONFIG_AX25_DAMA_SLAVE
Ralf Baechle [Thu, 28 Aug 2008 05:28:53 +0000 (22:28 -0700)]
AX.25: Fix sysctl registration if !CONFIG_AX25_DAMA_SLAVE

[ Upstream commit ffb208479bd62ab26c29a242faeb1de1c6d5fcdc ]

Since 49ffcf8f99e8d33ec8afb450956804af518fd788 ("sysctl: update
sysctl_check_table") setting struct ctl_table.procname = NULL does no
longer work as it used to the way the AX.25 code is expecting it to
resulting in the AX.25 sysctl registration code to break if
CONFIG_AX25_DAMA_SLAVE was not set as in some distribution kernels.
Kernel releases from 2.6.24 are affected.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agomm: make setup_zone_migrate_reserve() aware of overlapping nodes
Adam Litke [Wed, 3 Sep 2008 02:35:08 +0000 (02:35 +0000)]
mm: make setup_zone_migrate_reserve() aware of overlapping nodes

commit 344c790e3821dac37eb742ddd0b611a300f78b9a upstream

I have gotten to the root cause of the hugetlb badness I reported back on
August 15th.  My system has the following memory topology (note the
overlapping node):

            Node 0 Memory: 0x8000000-0x44000000
            Node 1 Memory: 0x0-0x8000000 0x44000000-0x80000000

setup_zone_migrate_reserve() scans the address range 0x0-0x8000000 looking
for a pageblock to move onto the MIGRATE_RESERVE list.  Finding no
candidates, it happily continues the scan into 0x8000000-0x44000000.  When
a pageblock is found, the pages are moved to the MIGRATE_RESERVE list on
the wrong zone.  Oops.

setup_zone_migrate_reserve() should skip pageblocks in overlapping nodes.

Signed-off-by: Adam Litke <agl@us.ibm.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years ago8250: improve workaround for UARTs that don't re-assert THRE correctly
Will Newton [Wed, 3 Sep 2008 02:35:06 +0000 (02:35 +0000)]
8250: improve workaround for UARTs that don't re-assert THRE correctly

commit 363f66fe06c75270b669c88e321e6b354ba0201e upstream

Recent changes to tighten the check for UARTs that don't correctly
re-assert THRE (01c194d9278efc15d4785ff205643e9c0bdcef53: "serial 8250:
tighten test for using backup timer") caused problems when such a UART was
opened for the second time - the bug could only successfully be detected
at first initialization.  For users of this version of this particular
UART IP it is fatal.

This patch stores the information about the bug in the bugs field of the
port structure when the port is first started up so subsequent opens can
check this bit even if the test for the bug fails.

David Brownell: "My own exposure to this is that the UART on DaVinci
hardware, which TI allegedly derived from its original 16550 logic, has
periodically gone from working to unusable with the mainline 8250.c ...
and back and forth a bunch.  Currently it's "unusable", a regression from
some previous versions.  With this patch from Will, it's usable."

Signed-off-by: Will Newton <will.newton@gmail.com>
Acked-by: Alex Williamson <alex.williamson@hp.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agortc_time_to_tm: fix signed/unsigned arithmetic
Jan Altenberg [Wed, 3 Sep 2008 02:35:04 +0000 (02:35 +0000)]
rtc_time_to_tm: fix signed/unsigned arithmetic

commit 73442daf2ea85e2a779396b76b1a39b10188ecb5 upstream

commit 945185a69daa457c4c5e46e47f4afad7dcea734f ("rtc: rtc_time_to_tm: use
unsigned arithmetic") changed the some types in rtc_time_to_tm() to
unsigned:

 void rtc_time_to_tm(unsigned long time, struct rtc_time *tm)
 {
-       register int days, month, year;
+       unsigned int days, month, year;

This doesn't work for all cases, because days is checked for < 0 later
on:

if (days < 0) {
year -= 1;
days += 365 + LEAP_YEAR(year);
}

I think the correct fix would be to keep days signed and do an appropriate
cast later on.

Signed-off-by: Jan Altenberg <jan.altenberg@linutronix.de>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Cc: Dmitri Vorobiev <dmitri.vorobiev@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agodrivers/char/random.c: fix a race which can lead to a bogus BUG()
Andrew Morton [Wed, 3 Sep 2008 02:35:02 +0000 (02:35 +0000)]
drivers/char/random.c: fix a race which can lead to a bogus BUG()

commit 8b76f46a2db29407fed66cf4aca19d61b3dcb3e1 upstream

Fix a bug reported by and diagnosed by Aaron Straus.

This is a regression intruduced into 2.6.26 by

    commit adc782dae6c4c0f6fb679a48a544cfbcd79ae3dc
    Author: Matt Mackall <mpm@selenic.com>
    Date:   Tue Apr 29 01:03:07 2008 -0700

        random: simplify and rename credit_entropy_store

credit_entropy_bits() does:

spin_lock_irqsave(&r->lock, flags);
...
if (r->entropy_count > r->poolinfo->POOLBITS)
r->entropy_count = r->poolinfo->POOLBITS;

so there is a time window in which this BUG_ON():

static size_t account(struct entropy_store *r, size_t nbytes, int min,
      int reserved)
{
unsigned long flags;

BUG_ON(r->entropy_count > r->poolinfo->POOLBITS);

/* Hold lock while accounting */
spin_lock_irqsave(&r->lock, flags);

can trigger.

We could fix this by moving the assertion inside the lock, but it seems
safer and saner to revert to the old behaviour wherein
entropy_store.entropy_count at no time exceeds
entropy_store.poolinfo->POOLBITS.

Reported-by: Aaron Straus <aaron@merfinllc.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agocifs: fix O_APPEND on directio mounts
Jeff Layton [Tue, 2 Sep 2008 19:25:05 +0000 (19:25 +0000)]
cifs: fix O_APPEND on directio mounts

commit 838726c4756813576078203eb7e1e219db0da870 upstream

The direct I/O write codepath for CIFS is done through
cifs_user_write(). That function does not currently call
generic_write_checks() so the file position isn't being properly set
when the file is opened with O_APPEND.  It's also not doing the other
"normal" checks that should be done for a write call.

The problem is currently that when you open a file with O_APPEND on a
mount with the directio mount option, the file position is set to the
beginning of the file. This makes any subsequent writes clobber the data
in the file starting at the beginning.

This seems to fix the problem in cursory testing. It is, however
important to note that NFS disallows the combination of
(O_DIRECT|O_APPEND). If my understanding is correct, the concern is
races with multiple clients appending to a file clobbering each others'
data. Since the write model for CIFS and NFS is pretty similar in this
regard, CIFS is probably subject to the same sort of races. What's
unclear to me is why this is a particular problem with O_DIRECT and not
with buffered writes...

Regardless, disallowing O_APPEND on an entire mount is probably not
reasonable, so we'll probably just have to deal with it and reevaluate
this flag combination when we get proper support for O_DIRECT. In the
meantime this patch at least fixes the existing problem.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoatl1: disable TSO by default
Jay Cliburn [Thu, 28 Aug 2008 19:40:05 +0000 (19:40 +0000)]
atl1: disable TSO by default

commit 82c26a9d117f0178b8c1b33429014b6d99c470f6 upstream

The atl1 driver is causing stalled connections and file corruption
whenever TSO is enabled.  Two examples are here:

http://lkml.org/lkml/2008/7/15/325
http://lkml.org/lkml/2008/8/18/543

Disable TSO by default until we can determine the source of the
problem.

Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoforcedeth: fix checksum flag
Ayaz Abdulla [Thu, 28 Aug 2008 19:40:03 +0000 (19:40 +0000)]
forcedeth: fix checksum flag

commit edcfe5f7e307846e578fb88d69fa27051fded0ab upstream

Fix the checksum feature advertised in device flags.  The hardware support
TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers).
However, the kernel feature flags do not distinguish IPv6 with/without
extension headers.

Therefore, the driver needs to use NETIF_F_IP_CSUM instead of
NETIF_F_HW_CSUM since the latter includes all IPv6 packets.

A future patch can be created to check for extension headers and perform
software checksum calculation.

Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agobio: fix bio_copy_kern() handling of bio->bv_len
FUJITA Tomonori [Wed, 27 Aug 2008 22:25:47 +0000 (22:25 +0000)]
bio: fix bio_copy_kern() handling of bio->bv_len

commit 76029ff37f31dad64641489c610d98955217bb68 upstream

The commit 68154e90c9d1492d570671ae181d9a8f8530da55 introduced
bio_copy_kern() to add bounce support to blk_rq_map_kern.

bio_copy_kern() uses bio->bv_len to copy data for READ commands after
the completion but it doesn't work with a request that partially
completed. SCSI always completes a PC request as a whole but seems
some don't.

This patch fixes bio_copy_kern to handle the above case. As
bio_copy_user does, bio_copy_kern uses struct bio_map_data to store
struct bio_vec.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Reported-by: Nix <nix@esperi.org.uk>
Tested-by: Nix <nix@esperi.org.uk>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agobio: fix __bio_copy_iov() handling of bio->bv_len
FUJITA Tomonori [Wed, 27 Aug 2008 22:25:36 +0000 (22:25 +0000)]
bio: fix __bio_copy_iov() handling of bio->bv_len

commit aefcc28a3a63ac33a298777aa50ba43641c75241 upstream

The commit c5dec1c3034f1ae3503efbf641ff3b0273b64797 introduced
__bio_copy_iov() to add bounce support to blk_rq_map_user_iov.

__bio_copy_iov() uses bio->bv_len to copy data for READ commands after
the completion but it doesn't work with a request that partially
completed. SCSI always completes a PC request as a whole but seems
some don't.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoALSA: oxygen: prevent muting of nonexistent AC97 controls
Clemens Ladisch [Tue, 26 Aug 2008 18:05:03 +0000 (18:05 +0000)]
ALSA: oxygen: prevent muting of nonexistent AC97 controls

commit 3d839e5b87a70effc629c1cdbf77d837ef141919 upstream

Date: Tue, 26 Aug 2008 11:06:26 +0200
Subject: ALSA: oxygen: prevent muting of nonexistent AC97 controls

The Xonar DX does not have CD Capture controls, so we have to check that
a control actually exists before muting it.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoS390 dasd: fix data size for PSF/PRSSD command
Stefan Weinhuber [Fri, 22 Aug 2008 17:40:08 +0000 (17:40 +0000)]
S390 dasd: fix data size for PSF/PRSSD command

commit 49fd38bdaa96f093fcad3176a781a4d0de8f8602 upstream

The Perform Subsystem Function/Prepare for Read Subsystem Data
command requires 12 bytes of parameter data, but the respective data
structure dasd_psf_prssd_data has a length of 16 bytes.
Current storage servers ignore the obsolete bytes, but older models
fail to execute the command and report an incorrect length error.
This causes the device initilization for these devices to fail.
To fix this problem we need to correct the dasd_psf_prssd_data
structure and shorten it to the correct length.

Reported-by: Ivan Warren <ivan@vmfacility.fr>
Reviewed-by: Ivan Warren <ivan@vmfacility.fr>
Tested-by: Ivan Warren <ivan@vmfacility.fr>
Signed-off-by: Stefan Weinhuber <wein@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agox86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)"
Samuel Sieb [Fri, 22 Aug 2008 17:40:12 +0000 (17:40 +0000)]
x86: fix "kernel won't boot on a Cyrix MediaGXm (Geode)"

commit c6744955d0ec0cb485c28c51eeb7185e260f6172 upstream

Cyrix MediaGXm/Cx5530 Unicorn Revision 1.19.3B has stopped
booting starting at v2.6.22.

The reason is this commit:

> commit f25f64ed5bd3c2932493681bdfdb483ea707da0a
> Author: Juergen Beisert <juergen@kreuzholzen.de>
> Date:   Sun Jul 22 11:12:38 2007 +0200
>
>     x86: Replace NSC/Cyrix specific chipset access macros by inlined functions.

this commit activated a macro which was dormant before due to (buggy)
macro side-effects.

I've looked through various datasheets and found that the GXm and GXLV
Geode processors don't have an incrementor.

Remove the incrementor setup entirely.  As the incrementor value
differs according to clock speed and we would hope that the BIOS
configures it correctly, it is probably the right solution.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agox86: work around MTRR mask setting
Yinghai Lu [Fri, 22 Aug 2008 17:40:05 +0000 (17:40 +0000)]
x86: work around MTRR mask setting

commit 38cc1c3df77c1bb739a4766788eb9fa49f16ffdf upstream

Joshua Hoblitt reported that only 3 GB of his 16 GB of RAM is
usable. Booting with mtrr_show showed us the BIOS-initialized
MTRR settings - which are all wrong.

So the root cause is that the BIOS has not set the mask correctly:

>               [    0.429971]  MSR00000200: 00000000d0000000
>               [    0.433305]  MSR00000201: 0000000ff0000800
> should be ==> [    0.433305]  MSR00000201: 0000003ff0000800
>
>               [    0.436638]  MSR00000202: 00000000e0000000
>               [    0.439971]  MSR00000203: 0000000fe0000800
> should be ==> [    0.439971]  MSR00000203: 0000003fe0000800
>
>               [    0.443304]  MSR00000204: 0000000000000006
>               [    0.446637]  MSR00000205: 0000000c00000800
> should be ==> [    0.446637]  MSR00000205: 0000003c00000800
>
>               [    0.449970]  MSR00000206: 0000000400000006
>               [    0.453303]  MSR00000207: 0000000fe0000800
> should be ==> [    0.453303]  MSR00000207: 0000003fe0000800
>
>               [    0.456636]  MSR00000208: 0000000420000006
>               [    0.459970]  MSR00000209: 0000000ff0000800
> should be ==> [    0.459970]  MSR00000209: 0000003ff0000800

So detect this borkage and add the prefix 111.

Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoUSB: cdc-acm: don't unlock acm->mutex on error path
Alexey Dobriyan [Fri, 22 Aug 2008 17:40:10 +0000 (17:40 +0000)]
USB: cdc-acm: don't unlock acm->mutex on error path

commit 74573ee7096a4ffc2f098108d21c85801b9c7434 upstream

On Wed, Jul 23, 2008 at 03:52:36PM +0300, Andrei Popa wrote:
> I installed gnokii-0.6.22-r2 and gave the command "gnokii --identify"
> and the kernel oopsed:
>
> BUG: unable to handle kernel NULL pointer dereference at 00000458
> IP: [<c0444b52>] mutex_unlock+0x0/0xb
>  [<c03830ae>] acm_tty_open+0x4c/0x214

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Tested-by: Andrei Popa <andrei.popa@i-neo.ro>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agobinfmt_misc: fix false -ENOEXEC when coupled with other binary handlers
Pavel Emelyanov [Wed, 20 Aug 2008 22:50:13 +0000 (22:50 +0000)]
binfmt_misc: fix false -ENOEXEC when coupled with other binary handlers

commit ff9bc512f198eb47204f55b24c6fe3d36ed89592 upstream

Date: Wed, 20 Aug 2008 14:09:10 -0700
Subject: binfmt_misc: fix false -ENOEXEC when coupled with other binary handlers

In case the binfmt_misc binary handler is registered *before* the e.g.
script one (when for example being compiled as a module) the following
situation may occur:

1. user launches a script, whose interpreter is a misc binary;
2. the load_misc_binary sets the misc_bang and returns -ENOEVEC,
   since the binary is a script;
3. the load_script_binary loads one and calls for search_binary_hander
   to run the interpreter;
4. the load_misc_binary is called again, but refuses to load the
   binary due to misc_bang bit set.

The fix is to move the misc_bang setting lower - prior to the actual
call to the search_binary_handler.

Caused by the commit 3a2e7f47 (binfmt_misc.c: avoid potential kernel
stack overflow)

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agofbdefio: add set_page_dirty handler to deferred IO FB
Ian Campbell [Wed, 20 Aug 2008 22:50:11 +0000 (22:50 +0000)]
fbdefio: add set_page_dirty handler to deferred IO FB

commit d847471d063663b9f36927d265c66a270c0cfaab upstream

Fixes kernel BUG at lib/radix-tree.c:473.

Previously the handler was incidentally provided by tmpfs but this was
removed with:

  commit 14fcc23fdc78e9d32372553ccf21758a9bd56fa1
  Author: Hugh Dickins <hugh@veritas.com>
  Date:   Mon Jul 28 15:46:19 2008 -0700

    tmpfs: fix kernel BUG in shmem_delete_inode

relying on this behaviour was incorrect in any case and the BUG also
appeared when the device node was on an ext3 filesystem.

v2: override a_ops at open() time rather than mmap() time to minimise
races per AKPM's concerns.

Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Cc: Jaya Kumar <jayakumar.lkml@gmail.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Johannes Weiner <hannes@saeurebad.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Kel Modderman <kel@otaku42.de>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoeeepc-laptop: fix use after free
Matthew Garrett [Wed, 20 Aug 2008 22:50:16 +0000 (22:50 +0000)]
eeepc-laptop: fix use after free

commit f14413184b1de4dcbd5ec3e7c129c3ce2079f543 upstream

Date: Wed, 20 Aug 2008 14:08:57 -0700
Subject: eeepc-laptop: fix use after free

eeepc-laptop uses the hwmon struct after unregistering the device, causing
an oops on module unload.  Flip the ordering to fix.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Karol Kozimor <sziwan@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoPCI: fix reference leak in pci_get_dev_by_id()
Greg Kroah-Hartman [Mon, 25 Aug 2008 20:05:06 +0000 (20:05 +0000)]
PCI: fix reference leak in pci_get_dev_by_id()

commit ebca4f1bce1eb7b91a63c515db66316db9391221 upstream

Alex Chiang and Matthew Wilcox pointed out that pci_get_dev_by_id() does
not properly decrement the reference on the from pointer if it is
present, like the documentation for the function states it will.

It fixes a pretty bad leak in the hotplug core (we were leaking an
entire struct pci_dev for each function of each offlined card, the first
time around; subsequent onlines/offlines were ok).

Cc: Matthew Wilcox <matthew@wil.cx>
Tested-by: Alex Chiang <achiang@hp.com>
Acked-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
16 years agocramfs: fix named-pipe handling
Al Viro [Wed, 20 Aug 2008 22:50:04 +0000 (22:50 +0000)]
cramfs: fix named-pipe handling

commit 82d63fc9e30687c055b97928942b8893ea65b0bb upstream

After commit a97c9bf33f4612e2aed6f000f6b1d268b6814f3c (fix cramfs
making duplicate entries in inode cache) in kernel 2.6.14, named-pipe
on cramfs does not work properly.

It seems the commit make all named-pipe on cramfs share their inode
(and named-pipe buffer).

Make ..._test() refuse to merge inodes with ->i_ino == 1, take inode setup
back to get_cramfs_inode() and make ->drop_inode() evict ones with ->i_ino
== 1 immediately.

Reported-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoLinux 2.6.26.3 v2.6.26.3
Greg Kroah-Hartman [Wed, 20 Aug 2008 18:11:37 +0000 (11:11 -0700)]
Linux 2.6.26.3

16 years agocrypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()
Suresh Siddha [Fri, 15 Aug 2008 00:13:20 +0000 (10:13 +1000)]
crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()

crypto: padlock - fix VIA PadLock instruction usage with irq_ts_save/restore()

[ Upstream commit: e49140120c88eb99db1a9172d9ac224c0f2bbdd2 ]

Wolfgang Walter reported this oops on his via C3 using padlock for
AES-encryption:

##################################################################

BUG: unable to handle kernel NULL pointer dereference at 000001f0
IP: [<c01028c5>] __switch_to+0x30/0x117
*pde = 00000000
Oops: 0002 [#1] PREEMPT
Modules linked in:

Pid: 2071, comm: sleep Not tainted (2.6.26 #11)
EIP: 0060:[<c01028c5>] EFLAGS: 00010002 CPU: 0
EIP is at __switch_to+0x30/0x117
EAX: 00000000 EBX: c0493300 ECX: dc48dd00 EDX: c0493300
ESI: dc48dd00 EDI: c0493530 EBP: c04cff8c ESP: c04cff7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process sleep (pid: 2071, ti=c04ce000 task=dc48dd00 task.ti=d2fe6000)
Stack: dc48df30 c0493300 00000000 00000000 d2fe7f44 c03b5b43 c04cffc8 00000046
   c0131856 0000005a dc472d3c c0493300 c0493470 d983ae00 00002696 00000000
   c0239f54 00000000 c04c4000 c04cffd8 c01025fe c04f3740 00049800 c04cffe0
Call Trace:
[<c03b5b43>] ? schedule+0x285/0x2ff
[<c0131856>] ? pm_qos_requirement+0x3c/0x53
[<c0239f54>] ? acpi_processor_idle+0x0/0x434
[<c01025fe>] ? cpu_idle+0x73/0x7f
[<c03a4dcd>] ? rest_init+0x61/0x63
=======================

Wolfgang also found out that adding kernel_fpu_begin() and kernel_fpu_end()
around the padlock instructions fix the oops.

Suresh wrote:

These padlock instructions though don't use/touch SSE registers, but it behaves
similar to other SSE instructions. For example, it might cause DNA faults
when cr0.ts is set. While this is a spurious DNA trap, it might cause
oops with the recent fpu code changes.

This is the code sequence  that is probably causing this problem:

a) new app is getting exec'd and it is somewhere in between
start_thread() and flush_old_exec() in the load_xyz_binary()

b) At pont "a", task's fpu state (like TS_USEDFPU, used_math() etc) is
cleared.

c) Now we get an interrupt/softirq which starts using these encrypt/decrypt
routines in the network stack. This generates a math fault (as
cr0.ts is '1') which sets TS_USEDFPU and restores the math that is
in the task's xstate.

d) Return to exec code path, which does start_thread() which does
free_thread_xstate() and sets xstate pointer to NULL while
the TS_USEDFPU is still set.

e) At the next context switch from the new exec'd task to another task,
we have a scenarios where TS_USEDFPU is set but xstate pointer is null.
This can cause an oops during unlazy_fpu() in __switch_to()

Now:

1) This should happen with or with out pre-emption. Viro also encountered
similar problem with out CONFIG_PREEMPT.

2) kernel_fpu_begin() and kernel_fpu_end() will fix this problem, because
kernel_fpu_begin() will manually do a clts() and won't run in to the
situation of setting TS_USEDFPU in step "c" above.

3) This was working before the fpu changes, because its a spurious
math fault  which doesn't corrupt any fpu/sse registers and the task's
math state was always in an allocated state.

With out the recent lazy fpu allocation changes, while we don't see oops,
there is a possible race still present in older kernels(for example,
while kernel is using kernel_fpu_begin() in some optimized clear/copy
page and an interrupt/softirq happens which uses these padlock
instructions generating DNA fault).

This is the failing scenario that existed even before the lazy fpu allocation
changes:

0. CPU's TS flag is set

1. kernel using FPU in some optimized copy  routine and while doing
kernel_fpu_begin() takes an interrupt just before doing clts()

2. Takes an interrupt and ipsec uses padlock instruction. And we
take a DNA fault as TS flag is still set.

3. We handle the DNA fault and set TS_USEDFPU and clear cr0.ts

4. We complete the padlock routine

5. Go back to step-1, which resumes clts() in kernel_fpu_begin(), finishes
the optimized copy routine and does kernel_fpu_end(). At this point,
we have cr0.ts again set to '1' but the task's TS_USEFPU is stilll
set and not cleared.

6. Now kernel resumes its user operation. And at the next context
switch, kernel sees it has do a FP save as TS_USEDFPU is still set
and then will do a unlazy_fpu() in __switch_to(). unlazy_fpu()
will take a DNA fault, as cr0.ts is '1' and now, because we are
in __switch_to(), math_state_restore() will get confused and will
restore the next task's FP state and will save it in prev tasks's FP state.
Remember, in __switch_to() we are already on the stack of the next task
but take a DNA fault for the prev task.

This causes the fpu leakage.

Fix the padlock instruction usage by calling them inside the
context of new routines irq_ts_save/restore(), which clear/restore cr0.ts
manually in the interrupt context. This will not generate spurious DNA
in the  context of the interrupt which will fix the oops encountered and
the possible FPU leakage issue.

Reported-and-bisected-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoPCI: Limit VPD length for Broadcom 5708S
Dean Hildebrand [Fri, 8 Aug 2008 00:31:45 +0000 (17:31 -0700)]
PCI: Limit VPD length for Broadcom 5708S

commit 35405f256de924be56ea5edaca4cdc627f1bb0f8 upstream

BCM5706S wont work correctly unless VPD length truncated to 128

Signed-off-by: Dean Hildebrand <dhildeb@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoCIFS: properly account for new user= field in SPNEGO upcall string allocation
Jeff Layton [Fri, 1 Aug 2008 18:08:14 +0000 (13:08 -0500)]
CIFS: properly account for new user= field in SPNEGO upcall string allocation

commit 66b8bd3c405389213de1d6ba6c2565990f62004f upstream

[CIFS] properly account for new user= field in SPNEGO upcall string allocation

...it doesn't look like it's being accounted for at the moment. Also
try to reorganize the calculation to make it a little more evident
what each piece means.

This should probably go to the stable series as well...

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agousb-storage: automatically recognize bad residues
Alan Stern [Tue, 5 Aug 2008 14:46:23 +0000 (10:46 -0400)]
usb-storage: automatically recognize bad residues

commit 59f4ff2ecff4cef36378928cec891785b402e80c upstream

This patch (as1119b) will help to reduce the clutter of usb-storage's
unusual_devs file by automatically detecting some devices that need
the IGNORE_RESIDUE flag.  The idea is that devices should never return
a non-zero residue for an INQUIRY or a READ CAPACITY command unless
they failed to transfer all the requested data.  So if one of these
commands transfers a standard amount of data but there is a positive
residue, we know that the residue is bogus and we can set the flag.

This fixes the problems reported in Bugzilla #11125.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Matthew Frost <artusemrys@sbcglobal.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agousb-storage: revert DMA-alignment change for Wireless USB
Alan Stern [Mon, 11 Aug 2008 14:08:17 +0000 (10:08 -0400)]
usb-storage: revert DMA-alignment change for Wireless USB

commit f756cbd458ab71c996a069cb3928fb1e2d7cd9cc upstream.

This patch (as1110) reverts an earlier patch meant to help with
Wireless USB host controllers.  These controllers can have bulk
maxpacket values larger than 512, which puts unusual constraints on
the sizes of scatter-gather list elements.  However it turns out that
the block layer does not provide the support we need to enforce these
constraints; merely changing the DMA alignment mask doesn't help.
Hence there's no reason to keep the original patch.  The Wireless USB
problem will have to be solved a different way.

In addition, there is a reason to get rid of the earlier patch.  By
dereferencing a pointer stored in the ep_in array of struct
usb_device, the current code risks an invalid memory access when it
runs concurrently with device removal.  The members of that array are
cleared before the driver's disconnect method is called, so it should
not try to use them.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoqla2xxx: Set an rport's dev_loss_tmo value in a consistent manner.
Andrew Vasquez [Thu, 14 Aug 2008 16:39:35 +0000 (09:39 -0700)]
qla2xxx: Set an rport's dev_loss_tmo value in a consistent manner.

[ Upstream commit 85821c906cf3563a00a3d98fa380a2581a7a5ff1 ]

As there's no point in adding a fixed-fudge value (originally 5
seconds), honor the user settings only.  We also remove the
driver's dead-callback get_rport_dev_loss_tmo function
(qla2x00_get_rport_loss_tmo()).

Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoqla2xxx: Add dev_loss_tmo_callbk/terminate_rport_io callback support.
Seokmann Ju [Thu, 14 Aug 2008 16:37:34 +0000 (09:37 -0700)]
qla2xxx: Add dev_loss_tmo_callbk/terminate_rport_io callback support.

[ Upstream commit 5f3a9a207f1fccde476dd31b4c63ead2967d934f ]

Signed-off-by: Seokmann Ju <seokmann.ju@qlogic.com>
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agox86: fix setup code crashes on my old 486 box
Joerg Roedel [Sun, 17 Aug 2008 00:25:07 +0000 (00:25 +0000)]
x86: fix setup code crashes on my old 486 box

commit 7b27718bdb1b70166383dec91391df5534d449ee upstream

yesterday I tried to reactivate my old 486 box and wanted to install a
current Linux with latest kernel on it. But it turned out that the
latest kernel does not boot because the machine crashes early in the
setup code.

After some debugging it turned out that the problem is the query_ist()
function. If this interrupt with that function is called the machine
simply locks up. It looks like a BIOS bug. Looking for a workaround for
this problem I wrote the attached patch. It checks for the CPUID
instruction and if it is not implemented it does not call the speedstep
BIOS function. As far as I know speedstep should be available since some
Pentium earliest.

Alan Cox observed that it's available since the Pentium II, so cpuid
levels 4 and 5 can be excluded altogether.

H. Peter Anvin cleaned up the code some more:

> Right in concept, but I dislike the implementation (duplication of the
> CPU detect code we already have).  Could you try this patch and see if
> it works for you?

which, with a small modification to fix a build error with it the
resulting kernel boots on my machine.

Signed-off-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agox86: fix spin_is_contended()
Jan Beulich [Sun, 17 Aug 2008 00:25:05 +0000 (00:25 +0000)]
x86: fix spin_is_contended()

commit 7bc069c6bc4ede519a7116be1b9e149a1dbf787a upstream

The masked difference is what needs to be compared against 1, rather
than the difference of masked values (which can be negative).

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Handle stack trace attempts before irqstacks are setup.
David S. Miller [Mon, 18 Aug 2008 03:51:12 +0000 (20:51 -0700)]
sparc64: Handle stack trace attempts before irqstacks are setup.

[ Upstream commit 6f63e781eaf6a741fc65f773017154b20ed4ce3b ]

Things like lockdep can try to do stack backtraces before
the irqstack blocks have been setup.  So don't try to match
their ranges so early on.

Also, remove unused variable in save_stack_trace().

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Implement IRQ stacks.
David S. Miller [Mon, 18 Aug 2008 03:49:47 +0000 (20:49 -0700)]
sparc64: Implement IRQ stacks.

[ Upstream commit 4f70f7a91bffdcc39f088748dc678953eb9a3fbd ]

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Make global reg dumping even more useful.
David S. Miller [Mon, 18 Aug 2008 03:47:13 +0000 (20:47 -0700)]
sparc64: Make global reg dumping even more useful.

[ Upstream commit 5afe27380bc42454254c9c83c045240249c15e35 ]

Record one more level of stack frame program counter.

Particularly when lockdep and all sorts of spinlock debugging is
enabled, figuring out the caller of spin_lock() is difficult when the
cpu is stuck on the lock.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Fix recursion in stack overflow detection handling.
David S. Miller [Mon, 18 Aug 2008 03:39:08 +0000 (20:39 -0700)]
sparc64: Fix recursion in stack overflow detection handling.

[ Upstream commit c7498081a6f5d96c9f3243b6b5e020352903bfd2 ]

The calls down into prom_printf() when we detect an overflowed stack
can recurse again since the overflow stack will be "below" the current
kernel stack limit.

Prevent this by just returning straight if we are on the stack
overflow safe stack already.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agosparc64: Fix end-of-stack checking in save_stack_trace().
David S. Miller [Mon, 18 Aug 2008 03:34:14 +0000 (20:34 -0700)]
sparc64: Fix end-of-stack checking in save_stack_trace().

[ Upstream commit 433c5f706856689be25928a99636e724fb3ea7cf ]

Bug reported by Alexander Beregalov.

Before we dereference the stack frame or try to peek at the
pt_regs magic value, make sure the entire object is within
the kernel stack bounds.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agortl8187: Fix lockups due to concurrent access to config routine
Larry Finger [Wed, 6 Aug 2008 04:20:56 +0000 (23:20 -0500)]
rtl8187: Fix lockups due to concurrent access to config routine

With the rtl8187 driver, the config routine is not protected against
access before a previous call has completed. When this happens, the
TX loopback that is needed to change channels may cause the chip to
be locked with a reset needed to restore communications. This patch
entered mainline as commit 7dcdd073bf78bb6958bbc12a1a47754a0f3c4721.

The problem was found by Herton Ronaldo Krzesinski <herton@mandriva.com.br>,
who also suggested this type of fix.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agocs5520: add enablebits checking
Bartlomiej Zolnierkiewicz [Wed, 6 Aug 2008 16:40:27 +0000 (18:40 +0200)]
cs5520: add enablebits checking

upstream commit is 24307ffabd5b39bad443641f54b12ee2ba7a38ac

Based on sparse comments in OpenFirmware code
(no Cx5510/Cx5520 datasheet here).

This fixes 2.6.26 regression reported by TAKADA
and caused by addition of warm-plug support.

Tested-by: TAKADA Yoshihito <takada@mbf.nifty.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoradeon: misc corrections
David Miller [Wed, 6 Aug 2008 22:28:12 +0000 (15:28 -0700)]
radeon: misc corrections

Commit efc491814308f89d5ef6c4fe19ae4552a67d4132 upstream

radeon: misc corrections

I have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that
hangs in my sparc64 boxes when the init scripts set the font.  The problem
goes away if I disable acceleration.

I haven't figured out that bug yet, but along the way I found some
corrections to make based upon some auditing.

1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver
   and the XORG video driver differ.  I've made the kernel
   match what XORG is using.

2) In radeonfb_engine_reset() we have top-level code structure
   that roughly looks like:

if (family is 300, 350, or V350)
do this;
else
do that;
...
if (family is NOT 300, OR
    family is NOT 350, OR
    family is NOT V350)
do another thing;

   this last conditional makes no sense, is always true,
   and obviously was likely meant to be "family is NOT
   300, 350, or V350".  So I've made the code match the
   intent.

Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoCIFS: Fix compiler warning on 64-bit
Jan Beulich [Tue, 22 Jul 2008 13:04:18 +0000 (13:04 +0000)]
CIFS: Fix compiler warning on 64-bit

commit 04e1e0cccade330ab3715ce59234f7e3b087e246 upstream.

Signed-off-by: Steve French <sfrench@us.ibm.com>
Cc: Eugene Teo <eteo@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoide: it821x in pass-through mode segfaults in 2.6.26-stable
Dimitri Gorokhovik [Wed, 16 Jul 2008 18:33:34 +0000 (20:33 +0200)]
ide: it821x in pass-through mode segfaults in 2.6.26-stable

commit 84e0f3f6c1e26588fdcb9f1b0f99d0275229bc99 upstream

The driver of ITE8212 in pass-through mode (it8212.noraid=1 on cmndline)
attempts to use the field `.dma_host_set' of the struct ide_dma_ops in
`ide_config_drive_speed' which is set to NULL by default.

So give a value to all fields of the struct ide_dma_ops.

Signed-off-by: Dimitri Gorokhovik <dimitri.gorokhovik@free.fr>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agox86: amd opteron TOM2 mask val fix
Yinghai Lu [Tue, 13 May 2008 00:40:39 +0000 (17:40 -0700)]
x86: amd opteron TOM2 mask val fix

commit 8004dd965b13b01a96def054d420f6df7ff22d53 upstream.

there is a typo in the mask value, need to remove that extra 0,
to avoid 4bit clearing.

Signed-off-by: Yinghal Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: maximilian attems <max@stro.at>
Cc: Peter Palfrader <weasel@debian.org>
Cc: dann frazier <dannf@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoALSA: ASoC: fix SNDCTL_DSP_SYNC support in Freescale 8610 sound drivers
Timur Tabi [Tue, 12 Aug 2008 15:11:11 +0000 (17:11 +0200)]
ALSA: ASoC: fix SNDCTL_DSP_SYNC support in Freescale 8610 sound drivers

Upstream-commit-id: bf9c8c9ddef7ef761ae9747349175adad0ef16ce

If an OSS application calls SNDCTL_DSP_SYNC, then ALSA will call the driver's
_hw_params and _prepare functions again.  On the Freescale MPC8610 DMA ASoC
driver, this caused the DMA controller to be unneccessarily re-programmed, and
apparently it doesn't like that.  The DMA will then not operate when
instructed.  This patch relocates much of the DMA programming to
fsl_dma_open(), which is called only once.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoi2c: Let users select algorithm drivers manually again
Jean Delvare [Tue, 12 Aug 2008 08:52:06 +0000 (10:52 +0200)]
i2c: Let users select algorithm drivers manually again

Already in Linus' tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8d24f8dcb7ead491704e274883b2c627062f6235

In kernel 2.6.26, the ability to select I2C algorithm drivers manually
was removed, as all in-kernel drivers do that automatically. However
there were some complaints that it was a problem for out-of-tree I2C
bus drivers. In order to address these complaints, let's allow manual
selection of these drivers again, but still hide them by default for
better general user experience.

This closes bug #11140:
http://bugzilla.kernel.org/show_bug.cgi?id=11140

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoi2c: Fix NULL pointer dereference in i2c_new_probed_device
Hans Verkuil [Tue, 12 Aug 2008 08:50:29 +0000 (10:50 +0200)]
i2c: Fix NULL pointer dereference in i2c_new_probed_device

Already in Linus' tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b25b791b13aaa336b56c4f9bd417ff126363f80b

Fix a NULL pointer dereference that happened when calling
i2c_new_probed_device on one of the addresses for which we use byte
reads instead of quick write for detection purpose (that is: 0x30-0x37
and 0x50-0x5f).

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoALSA: asoc: restrict sample rate and size in Freescale MPC8610 sound drivers
Timur Tabi [Tue, 12 Aug 2008 15:09:25 +0000 (17:09 +0200)]
ALSA: asoc: restrict sample rate and size in Freescale MPC8610 sound drivers

Upstream-commid-id: be41e941d5f1a48bde7f44d09d56e8d2605f98e1

The Freescale MPC8610 SSI device has the option of using one clock for both
transmit and receive (synchronous mode), or independent clocks (asynchronous).
The SSI driver, however, programs the SSI into synchronous mode and then
tries to program the clock registers independently.  The result is that the wrong
sample size is usually generated during recording.

This patch fixes the discrepancy by restricting the sample rate and sample size
of the playback and capture streams.  The SSI driver remembers which stream
is opened first.  When a second stream is opened, that stream is constrained
to the same sample rate and size as the first stream.

A future version of this driver will lift the sample size restriction.
Supporting independent sample rates is more difficult, because only certain
codecs provide dual independent clocks.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agor8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06
Marcus Sundberg [Thu, 10 Jul 2008 19:28:08 +0000 (21:28 +0200)]
r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06

commit 77332894c21165404496c56763d7df6c15c4bb09 upstream

The magic write to register 0x82 will often cause PCI config space on
my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop)
to be filled with ones during driver load, and thus breaking NIC
operation until reboot. If it does not happen on first driver load it
can easily be reproduced by unloading and loading the driver a few
times.

The magic write was added long ago by this commit:

Author: François Romieu <romieu@fr.zoreil.com>
Date:   Sat Jan 10 06:00:46 2004 -0500

     [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one():
     - phy capability settings allows lower or equal capability as suggested
       in Realtek's changes;
     - I/O voodoo;
     - no need to s/mdio_write/RTL8169_WRITE_GMII_REG/;
     - s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/;
     - rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication
       of code (yep, the u16 -> int conversions should work as expected);
     - variable renames and whitepace changes ignored.

As the 8168 wasn't supported by that version this patch simply removes
the bogus write from mac versions <= RTL_GIGA_MAC_VER_06.

[The change above makes sense for the 8101/8102 too -- Ueimor]

Signed-off-by: Marcus Sundberg <marcus@ingate.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoKVM: ia64: Fix irq disabling leak in error handling code
Julia Lawall [Wed, 13 Aug 2008 15:00:30 +0000 (18:00 +0300)]
KVM: ia64: Fix irq disabling leak in error handling code

(cherry picked from commit cab7a1eeeb007be309cd99cf14407261a72d2418)

There is a call to local_irq_restore in the normal exit case, so it would
seem that there should be one on an error return as well.

The semantic patch that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
expression l;
expression E,E1,E2;
@@

local_irq_save(l);
... when != local_irq_restore(l)
    when != spin_unlock_irqrestore(E,l)
    when any
    when strict
(
if (...) { ... when != local_irq_restore(l)
               when != spin_unlock_irqrestore(E1,l)
+   local_irq_restore(l);
    return ...;
}
|
if (...)
+   {local_irq_restore(l);
    return ...;
+   }
|
spin_unlock_irqrestore(E2,l);
|
local_irq_restore(l);
)
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoKVM: task switch: translate guest segment limit to virt-extension byte granular field
Marcelo Tosatti [Wed, 13 Aug 2008 15:00:29 +0000 (18:00 +0300)]
KVM: task switch: translate guest segment limit to virt-extension byte granular field

(cherry picked from commit c93cd3a58845012df2d658fecd0ac99f7008d753)

If 'g' is one then limit is 4kb granular.

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoKVM: Avoid instruction emulation when event delivery is pending
Avi Kivity [Wed, 13 Aug 2008 15:00:28 +0000 (18:00 +0300)]
KVM: Avoid instruction emulation when event delivery is pending

(cherry-picked from commit 577bdc496614ced56d999bbb425e85adf2386490)

When an event (such as an interrupt) is injected, and the stack is
shadowed (and therefore write protected), the guest will exit.  The
current code will see that the stack is shadowed and emulate a few
instructions, each time postponing the injection.  Eventually the
injection may succeed, but at that time the guest may be unwilling
to accept the interrupt (for example, the TPR may have changed).

This occurs every once in a while during a Windows 2008 boot.

Fix by unshadowing the fault address if the fault was due to an event
injection.

Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
16 years agoKVM: task switch: use seg regs provided by subarch instead of reading from GDT
Marcelo Tosatti [Wed, 13 Aug 2008 15:00:27 +0000 (18:00 +0300)]
KVM: task switch: use seg regs provided by subarch instead of reading from GDT

(cherry-picked from commit 34198bf8426276a2ce1e97056a0f02d43637e5ae)

There is no guarantee that the old TSS descriptor in the GDT contains
the proper base address. This is the case for Windows installation's
reboot-via-triplefault.

Use guest registers instead. Also translate the address properly.

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>