firefly-linux-kernel-4.4.55.git
14 years agotmpfs: insert tmpfs cache pages to inactive list at first
KOSAKI Motohiro [Mon, 24 May 2010 21:31:48 +0000 (14:31 -0700)]
tmpfs: insert tmpfs cache pages to inactive list at first

commit e9d6c157385e4efa61cb8293e425c9d8beba70d3 upstream.

Shaohua Li reported parallel file copy on tmpfs can lead to OOM killer.
This is regression of caused by commit 9ff473b9a7 ("vmscan: evict
streaming IO first").  Wow, It is 2 years old patch!

Currently, tmpfs file cache is inserted active list at first.  This means
that the insertion doesn't only increase numbers of pages in anon LRU, but
it also reduces anon scanning ratio.  Therefore, vmscan will get totally
confused.  It scans almost only file LRU even though the system has plenty
unused tmpfs pages.

Historically, lru_cache_add_active_anon() was used for two reasons.
1) Intend to priotize shmem page rather than regular file cache.
2) Intend to avoid reclaim priority inversion of used once pages.

But we've lost both motivation because (1) Now we have separate anon and
file LRU list.  then, to insert active list doesn't help such priotize.
(2) In past, one pte access bit will cause page activation.  then to
insert inactive list with pte access bit mean higher priority than to
insert active list.  Its priority inversion may lead to uninteded lru
chun.  but it was already solved by commit 645747462 (vmscan: detect
mapped file pages used only once).  (Thanks Hannes, you are great!)

Thus, now we can use lru_cache_add_anon() instead.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: Shaohua Li <shaohua.li@intel.com>
Reviewed-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
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>
14 years agoBlackfin: set ARCH_KMALLOC_MINALIGN
FUJITA Tomonori [Thu, 20 May 2010 03:21:38 +0000 (23:21 -0400)]
Blackfin: set ARCH_KMALLOC_MINALIGN

commit 76b99699a2bbf9efdb578f9a38a202af2ecb354b upstream.

Architectures that handle DMA-non-coherent memory need to set
ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe:
the buffer doesn't share a cache with the others.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoxtensa: set ARCH_KMALLOC_MINALIGN
FUJITA Tomonori [Mon, 24 May 2010 21:31:45 +0000 (14:31 -0700)]
xtensa: set ARCH_KMALLOC_MINALIGN

commit 498900fc9cd1adbad1ba6b55ed9d8f2f5d655ca3 upstream.

Architectures that handle DMA-non-coherent memory need to set
ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the
buffer doesn't share a cache with the others.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Chris Zankel <chris@zankel.net>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
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>
14 years agofrv: set ARCH_KMALLOC_MINALIGN
FUJITA Tomonori [Mon, 24 May 2010 21:32:54 +0000 (14:32 -0700)]
frv: set ARCH_KMALLOC_MINALIGN

commit 69dcf3db03626c4f18de624e8632454ea12ff260 upstream.

Architectures that handle DMA-non-coherent memory need to set
ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the
buffer doesn't share a cache with the others.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
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>
14 years agortc: s3c: initialize driver data before using it
Maurus Cuelenaere [Fri, 4 Jun 2010 21:14:44 +0000 (14:14 -0700)]
rtc: s3c: initialize driver data before using it

commit e893de59a4982791368b3ce412bc67dd601a88a0 upstream.

s3c_rtc_setfreq() uses the platform driver data to derive struct rtc_device,
so make sure drvdata is set _before_ s3c_rtc_setfreq() is called.

Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Maurus Cuelenaere <mcuelenaere@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>
14 years agortc-cmos: do dev_set_drvdata() earlier in the initialization
Dan Carpenter [Mon, 24 May 2010 21:33:49 +0000 (14:33 -0700)]
rtc-cmos: do dev_set_drvdata() earlier in the initialization

commit 6ba8bcd457d9fc793ac9435aa2e4138f571d4ec5 upstream.

The bug is an oops when dev_get_drvdata() returned null in
cmos_update_irq_enable().  The call tree looks like this:
  rtc_dev_ioctl()
    => rtc_update_irq_enable()
      => cmos_update_irq_enable()

It's caused by a race condition in the module initialization.  It is
rtc_device_register() which makes the ioctl operations live so I moved
the call to dev_set_drvdata() before the call to rtc_device_register().

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15963

Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Malte Schroder <maltesch@gmx.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
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>
14 years agom68k: set ARCH_KMALLOC_MINALIGN
FUJITA Tomonori [Sun, 23 May 2010 17:38:14 +0000 (19:38 +0200)]
m68k: set ARCH_KMALLOC_MINALIGN

commit dd6c26a66bdc629a500174ffe73b010b070b9f1b upstream.

Architectures that handle DMA-non-coherent memory need to set
ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the
buffer doesn't share a cache with the others.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomn10300: set ARCH_KMALLOC_MINALIGN
FUJITA Tomonori [Mon, 24 May 2010 21:32:58 +0000 (14:32 -0700)]
mn10300: set ARCH_KMALLOC_MINALIGN

commit 6cdafaae41d52e6ef9a5c5be23602ef083e4d0f9 upstream.

Architectures that handle DMA-non-coherent memory need to set
ARCH_KMALLOC_MINALIGN to make sure that kmalloc'ed buffer is DMA-safe: the
buffer doesn't share a cache with the others.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: David Howells <dhowells@redhat.com>
Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
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>
14 years agoexofs: confusion between kmap() and kmap_atomic() api
Dan Carpenter [Fri, 7 May 2010 09:05:33 +0000 (11:05 +0200)]
exofs: confusion between kmap() and kmap_atomic() api

commit ddf08f4b90a413892bbb9bb2e8a57aed991cd47d upstream.

For kmap_atomic() we call kunmap_atomic() on the returned pointer.
That's different from kmap() and kunmap() and so it's easy to get them
backwards.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agox86/amd-iommu: Fix suspend/resume with IOMMU
Joerg Roedel [Tue, 1 Jun 2010 09:41:44 +0000 (11:41 +0200)]
x86/amd-iommu: Fix suspend/resume with IOMMU

This is a suspend resume fix for 2.6.32-stable inclusion. The
problem with this patch is that it is not upstream because the code
changed with 2.6.33 and the function where this bug is in was
removed. So this fix does not make sense anymore for anything later than
2.6.32. The patch was tested by multiple partys and is confirmed to fix
the broken suspend/resume issue with the 2.6.32 kernel.

This patch fixes suspend/resume with AMD IOMMU enabled.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomd: set mddev readonly flag on blkdev BLKROSET ioctl
Dan Williams [Tue, 11 May 2010 22:25:37 +0000 (08:25 +1000)]
md: set mddev readonly flag on blkdev BLKROSET ioctl

commit e2218350465e7e0931676b4849b594c978437bce upstream.

When the user sets the block device to readwrite then the mddev should
follow suit.  Otherwise, the BUG_ON in md_write_start() will be set to
trigger.

The reverse direction, setting mddev->ro to match a set readonly
request, can be ignored because the blkdev level readonly flag precludes
the need to have mddev->ro set correctly.  Nevermind the fact that
setting mddev->ro to 1 may fail if the array is in use.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomd: Fix read balancing in RAID1 and RAID10 on drives > 2TB
NeilBrown [Fri, 7 May 2010 22:20:17 +0000 (08:20 +1000)]
md: Fix read balancing in RAID1 and RAID10 on drives > 2TB

commit af3a2cd6b8a479345786e7fe5e199ad2f6240e56 upstream.

read_balance uses a "unsigned long" for a sector number which
will get truncated beyond 2TB.
This will cause read-balancing to be non-optimal, and can cause
data to be read from the 'wrong' branch during a resync.  This has a
very small chance of returning wrong data.

Reported-by: Jordan Russell <jr-list-2010@quo.to>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomd/raid1: fix counting of write targets.
NeilBrown [Tue, 18 May 2010 05:27:13 +0000 (15:27 +1000)]
md/raid1: fix counting of write targets.

commit 964147d5c86d63be79b442c30f3783d49860c078 upstream.

There is a very small race window when writing to a
RAID1 such that if a device is marked faulty at exactly the wrong
time, the write-in-progress will not be sent to the device,
but the bitmap (if present) will be updated to say that
the write was sent.

Then if the device turned out to still be usable as was re-added
to the array, the bitmap-based-resync would skip resyncing that
block, possibly leading to corruption.  This would only be a problem
if no further writes were issued to that area of the device (i.e.
that bitmap chunk).

Suitable for any pending -stable kernel.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agowriteback: disable periodic old data writeback for !dirty_writeback_centisecs
Jens Axboe [Mon, 17 May 2010 10:51:03 +0000 (12:51 +0200)]
writeback: disable periodic old data writeback for !dirty_writeback_centisecs

commit 69b62d01ec44fe0d505d89917392347732135a4d upstream.

Prior to 2.6.32, setting /proc/sys/vm/dirty_writeback_centisecs disabled
periodic dirty writeback from kupdate. This got broken and now causes
excessive sys CPU usage if set to zero, as we'll keep beating on
schedule().

Reported-by: Justin Maggard <jmaggard10@gmail.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agopowerpc/oprofile: fix potential buffer overrun in op_model_cell.c
Denis Kirjanov [Tue, 1 Jun 2010 19:43:34 +0000 (15:43 -0400)]
powerpc/oprofile: fix potential buffer overrun in op_model_cell.c

commit 238c1a78c957f3dc7cb848b161dcf4805793ed56 upstream.

Fix potential initial_lfsr buffer overrun.
Writing past the end of the buffer could happen when index == ENTRIES

Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agopowerpc/pseries: Make query_cpu_stopped callable outside hotplug cpu
Michael Neuling [Wed, 28 Apr 2010 13:39:41 +0000 (13:39 +0000)]
powerpc/pseries: Make query_cpu_stopped callable outside hotplug cpu

commit f8b67691828321f5c85bb853283aa101ae673130 upstream.

This moves query_cpu_stopped() out of the hotplug cpu code and into
smp.c so it can called in other places and renames it to
smp_query_cpu_stopped().

It also cleans up the return values by adding some #defines

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agopowerpc/pseries: Only call start-cpu when a CPU is stopped
Michael Neuling [Wed, 28 Apr 2010 13:39:41 +0000 (13:39 +0000)]
powerpc/pseries: Only call start-cpu when a CPU is stopped

commit aef40e87d866355ffd279ab21021de733242d0d5 upstream.

Currently we always call start-cpu irrespective of if the CPU is
stopped or not. Unfortunatley on POWER7, firmware seems to not like
start-cpu being called when a cpu already been started.  This was not
the case on POWER6 and earlier.

This patch checks to see if the CPU is stopped or not via an
query-cpu-stopped-state call, and only calls start-cpu on CPUs which
are stopped.

This fixes a bug with kexec on POWER7 on PHYP where only the primary
thread would make it to the second kernel.

Reported-by: Ankita Garg <ankita@linux.vnet.ibm.com>
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agopowerpc: Fix handling of strncmp with zero len
Jeff Mahoney [Wed, 17 Mar 2010 10:55:51 +0000 (10:55 +0000)]
powerpc: Fix handling of strncmp with zero len

commit 637a99022fb119b90fb281715d13172f0394fc12 upstream.

Commit 0119536c, which added the assembly version of strncmp to
powerpc, mentions that it adds two instructions to the version from
boot/string.S to allow it to handle len=0. Unfortunately, it doesn't
always return 0 when that is the case. The length is passed in r5, but
the return value is passed back in r3. In certain cases, this will
happen to work. Otherwise it will pass back the address of the first
string as the return value.

This patch lifts the len <= 0 handling code from memcpy to handle that
case.

Reported by: Christian_Sellars@symantec.com
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agodrm/radeon/kms/atom: fix typo in LVDS panel info parsing
Alex Deucher [Tue, 18 May 2010 04:23:15 +0000 (00:23 -0400)]
drm/radeon/kms/atom: fix typo in LVDS panel info parsing

commit 1ff26a3604d0292988d4cade0e49ba9918dbfd46 upstream.

Fixes LVDS issues on some laptops; notably laptops with
2048x1536 panels.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agodrm/edid: Fix 1024x768@85Hz
Adam Jackson [Thu, 13 May 2010 18:55:28 +0000 (14:55 -0400)]
drm/edid: Fix 1024x768@85Hz

commit 61dd98fad58f945ed720ba132681acb58fcee015 upstream.

Having hsync both start and end on pixel 1072 ain't gonna work very
well.  Matches the X server's list.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomm: hugetlb: fix clear_huge_page()
Andrea Arcangeli [Fri, 8 Jan 2010 22:43:05 +0000 (14:43 -0800)]
mm: hugetlb: fix clear_huge_page()

commit 74dbdd239bb1348ad86d28b18574d9c1f28b62ca upstream.

sz is in bytes, MAX_ORDER_NR_PAGES is in pages.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: David Gibson <dwg@au1.ibm.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: David Rientjes <rientjes@google.com>
Cc: Lee Schermerhorn <lee.schermerhorn@hp.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>
14 years agovirtio_net: Make delayed refill more reliable
Herbert Xu [Mon, 25 Jan 2010 23:51:01 +0000 (15:51 -0800)]
virtio_net: Make delayed refill more reliable

commit 39d321577405e8e269fd238b278aaf2425fa788a upstream.

I have seen RX stalls on a machine that experienced a suspected
OOM.  After the stall, the RX buffer is empty on the guest side
and there are exactly 16 entries available on the host side.  As
the number of entries is less than that required by a maximal
skb, the host cannot proceed.

The guest did not have a refill job scheduled.

My diagnosis is that an OOM had occured, with the delayed refill
job scheduled.  The job was able to allocate at least one skb, but
not enough to overcome the minimum required by the host to proceed.

As the refill job would only reschedule itself if it failed completely
to allocate any skbs, this would lead to an RX stall.

The following patch removes this stall possibility by always
rescheduling the refill job until the ring is totally refilled.

Testing has shown that the RX stall no longer occurs whereas
previously it would occur within a day.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Bruce Rogers <brogers@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoPCI: Disable MSI for MCP55 on P5N32-E SLI
Ben Hutchings [Sun, 16 May 2010 01:28:49 +0000 (02:28 +0100)]
PCI: Disable MSI for MCP55 on P5N32-E SLI

commit e4146bb9088c01c8b6e82be11f0c371f8aff023c upstream.

As reported in <http://bugs.debian.org/552299>, MSI appears to be
broken for this on-board device.  We already have a quirk for the
P5N32-SLI Premium; extend it to cover both variants of the board.

Reported-by: Romain DEGEZ <romain.degez@smartjog.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoPCI quirks: disable msi on AMD rs4xx internal gfx bridges
Alex Deucher [Tue, 18 May 2010 14:42:53 +0000 (10:42 -0400)]
PCI quirks: disable msi on AMD rs4xx internal gfx bridges

commit 9313ff450400e6a2ab10fe6b9bdb12a828329410 upstream.

Doesn't work reliably for internal gfx.  Fixes kernel bug
https://bugzilla.kernel.org/show_bug.cgi?id=15626.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoPCI quirk: Disable MSI on VIA K8T890 systems
Matthew Wilcox [Wed, 24 Mar 2010 13:11:01 +0000 (07:11 -0600)]
PCI quirk: Disable MSI on VIA K8T890 systems

commit 134b345081534235dbf228b1005c14590e0570ba upstream.

Bugzilla 15287 indicates that there's a problem with Message Signalled
Interrupts on VIA K8T890 systems.  Add a quirk to disable MSI on these
systems.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Tested-by: Jan Kreuzer <kontrollator@gmx.de>
Tested-by: lh <jarryson@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agocan: Fix SJA1000 command register writes on SMP systems
Oliver Hartkopp [Tue, 18 May 2010 21:03:10 +0000 (14:03 -0700)]
can: Fix SJA1000 command register writes on SMP systems

commit 57c8a456640fa3ca777652f11f2db4179a3e66b6 upstream.

The SJA1000 command register is concurrently written in the rx-path to free
the receive buffer _and_ in the tx-path to start the transmission.

The SJA1000 data sheet, 6.4.4 COMMAND REGISTER (CMR) states:
"Between two commands at least one internal clock cycle is needed in
order to proceed. The internal clock is half of the external oscillator
frequency."

On SMP systems the current implementation leads to a write stall in the
tx-path, which can be solved by adding some general locking and some time
to settle the write_reg() operation for the command register.

Thanks to Klaus Hitschler for the original fix and detailed problem
description.

This patch applies on net-2.6 and (with some offsets) on net-next-2.6 .

Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agodrivers/base/cpu.c: fix the output from /sys/devices/system/cpu/offline
Jan Beulich [Tue, 27 Apr 2010 21:01:20 +0000 (14:01 -0700)]
drivers/base/cpu.c: fix the output from /sys/devices/system/cpu/offline

commit cdc6e3d3968052cebb2f2ddcd742bff29fbd1a90 upstream.

Without CONFIG_CPUMASK_OFFSTACK, simply inverting cpu_online_mask leads
to CPUs beyond nr_cpu_ids to be displayed twice and CPUs not even
possible to be displayed as offline.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agodrm/i915: Reject bind_to_gtt() early if object > aperture
Chris Wilson [Thu, 27 May 2010 12:18:21 +0000 (13:18 +0100)]
drm/i915: Reject bind_to_gtt() early if object > aperture

commit 654fc6073f68efa3b6c466825749e73e7fbb92cd upstream.

If the object is bigger than the entire aperture, reject it early
before evicting everything in a vain attempt to find space.

v2: Use E2BIG as suggested by Owain G. Ainsworth.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomac80211: fix rts threshold check
Shanyu Zhao [Tue, 27 Apr 2010 18:15:12 +0000 (11:15 -0700)]
mac80211: fix rts threshold check

commit a2c40249a36d0b4d76d1caf6bf806e4ae5b06e8a upstream.

Currently whenever rts thresold is set, every packet will use RTS
protection no matter its size exceeds the threshold or not. This is
due to a bug in the rts threshold check.
if (len > tx->local->hw.wiphy->rts_threshold) {
txrc.rts = rts = true;
}
Basically it is comparing an int (len) and a u32 (rts_threshold),
and the variable len is assigned as:
len = min_t(int, tx->skb->len + FCS_LEN,
 tx->local->hw.wiphy->frag_threshold);
However, when frag_threshold is "-1", len is always "-1", which is
0xffffffff therefore rts is always set to true.

Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomac80211: Fix robust management frame handling (MFP)
Jouni Malinen [Mon, 29 Mar 2010 05:29:52 +0000 (22:29 -0700)]
mac80211: Fix robust management frame handling (MFP)

commit d211e90e28a074447584729018a39910d691d1a8 upstream.

Commit e34e09401ee9888dd662b2fca5d607794a56daf2 incorrectly removed
use of ieee80211_has_protected() from the management frame case and in
practice, made this validation drop all Action frames when MFP is
enabled. This should have only been done for frames with Protected
field set to zero.

Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomac80211: give warning if building w/out rate ctrl algorithm
Andres Salomon [Fri, 26 Feb 2010 00:18:47 +0000 (19:18 -0500)]
mac80211: give warning if building w/out rate ctrl algorithm

commit c2ef355bf3ef0b8006b96128726684fba47ac928 upstream.

I discovered that if EMBEDDED=y, one can accidentally build a mac80211 stack
and drivers w/ no rate control algorithm.  For drivers like RTL8187 that don't
supply their own RC algorithms, this will cause ieee80211_register_hw to
fail (making the driver unusable).

This will tell kconfig to provide a warning if no rate control algorithms
have been selected.  That'll at least warn the user; users that know that
their drivers supply a rate control algorithm can safely ignore the
warning, and those who don't know (or who expect to be using multiple
drivers) can select a default RC algorithm.

Signed-off-by: Andres Salomon <dilinger@collabora.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: xHCI: Fix wrong usage of macro TRB_TYPE
Andiry Xu [Tue, 11 May 2010 02:57:17 +0000 (19:57 -0700)]
USB: xHCI: Fix wrong usage of macro TRB_TYPE

commit 54b5acf3acb7a1f83ec281d111d3e2812cd7ad9d upstream.

Macro TRB_TYPE is misused in some places. Fix the wrong usage.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: xhci: Fix check for room on the ring.
Sarah Sharp [Tue, 18 May 2010 23:05:26 +0000 (16:05 -0700)]
USB: xhci: Fix check for room on the ring.

commit 44ebd037c54f80db3121ac9f5fe6e677b76e11d5 upstream.

The length of the scatter gather list a driver can enqueue is limited by
the bus' sg_tablesize to 62 entries.  Each entry will be described by at
least one transfer request block (TRB).  If the entry's buffer crosses a
64KB boundary, then that entry will have to be described by two or more
TRBs.  So even if the USB device driver respects sg_tablesize, the whole
scatter list may take more than 62 TRBs to describe, and won't fit on
the ring.

Don't assume that an empty ring means there is enough room on the
transfer ring.  The old code would unconditionally queue this too-large
transfer, and over write the beginning of the transfer.  This would mean
the cycle bit was unchanged in those overwritten transfers, causing the
hardware to think it didn't own the TRBs, and the host would seem to
hang.

Now drivers may see submit_urb() fail with -ENOMEM if the transfers are
too big to fit on the ring.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: xhci: Fix issue with set interface after stall.
Sarah Sharp [Thu, 6 May 2010 20:40:08 +0000 (13:40 -0700)]
USB: xhci: Fix issue with set interface after stall.

commit 1624ae1c19e227096ba85bfc389d9b99cb6f7dde upstream.

When the USB core installs a new interface, it unconditionally clears the
halts on all the endpoints on the new interface.  Usually the xHCI host
needs to know when an endpoint is reset, so it can change its internal
endpoint state.  In this case, it doesn't care, because the endpoints were
never halted in the first place.

To avoid issuing a redundant Reset Endpoint command, the xHCI driver looks
at xhci_virt_ep->stopped_td to determine if the endpoint was actually
halted.  However, the functions that handle the stall never set that
variable to NULL after it dealt with the stall.  So if an endpoint stalled
and a Reset Endpoint command completed, and then the class driver tried to
install a new alternate setting, the xHCI driver would access the old
xhci_virt_ep->stopped_td pointer.  A similar problem occurs if the
endpoint has been stopped to cancel a transfer.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: EHCI: clear PHCD before resuming
Alek Du [Mon, 10 May 2010 03:17:49 +0000 (11:17 +0800)]
USB: EHCI: clear PHCD before resuming

commit eab80de01cb398419ef3305f35abcb367c647c8b upstream.

This is a bug fix for PHCD (phy clock disable) low power feature:
After PHCD is set, any write to PORTSC register is illegal, so when
resume ports, clear PHCD bit first.

Signed-off-by: Alek Du <alek.du@intel.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: unusual-dev: Add bad sense flag for Appotech ax203 based picture frames
Hans de Goede [Thu, 29 Apr 2010 10:59:04 +0000 (12:59 +0200)]
USB: unusual-dev: Add bad sense flag for Appotech ax203 based picture frames

commit a78f4f1a16d87f3d33158d036af94e48e32f8aad upstream.

These Appotech controllers are found in Picture Frames, they provide a
(buggy) emulation of a cdrom drive which contains the windows software
Uploading of pictures happens over the corresponding /dev/sg device.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: mxc: gadget: Fix bitfield for calculating maximum packet size
Dinh Nguyen [Tue, 4 May 2010 15:03:01 +0000 (10:03 -0500)]
USB: mxc: gadget: Fix bitfield for calculating maximum packet size

commit 88e3b59b5adce5b12e205af0e34d518ba0dcdc0c upstream.

The max packet length bit mask used for isochronous endpoints
should be 0x7FF instead of 0x8FF. 0x8FF will actually clear
higher-order bits in the max packet length field.

This patch applies to 2.6.34-rc6.

Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: kl5usb105: fix memory leak
Johan Hovold [Tue, 18 May 2010 22:01:38 +0000 (00:01 +0200)]
USB: kl5usb105: fix memory leak

commit 313b0d80c1717ffe8f64b455a4d323996748b91a upstream.

Private data was not freed on error path in startup.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: ir-usb: fix double free
Johan Hovold [Thu, 13 May 2010 19:02:00 +0000 (21:02 +0200)]
USB: ir-usb: fix double free

commit 2ff78c0c2b67120c8e503268da3f177cae2228a2 upstream.

If the user specifies a custom bulk buffer size we get a double free at
port release.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: option.c: OLIVETTI OLICARD100 support
Nils Radtke [Mon, 17 May 2010 12:14:11 +0000 (14:14 +0200)]
USB: option.c: OLIVETTI OLICARD100 support

commit 86234d4975ce084d14711283a3bfc69305f97602 upstream.

This patch adds support for an olivetti olicard100 HЅDPA usb-stick.

This device is a zeroCD one with ID 0b3c:c700 that needs switching via
eject or usb-modeswitch with
MessageContent="5553424312345678000000000000061b000000030000000000000000000000".
After switching it has ID 0b3c:c000 and provides 5 serial ports ttyUSB[0-4].
Port 0 (modem) and 4 are interrupt ports.

Signed-off-by: Nils Radtke <lkml@Think-Future.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: serial: option: add cinterion device id
Greg Kroah-Hartman [Tue, 27 Apr 2010 16:38:51 +0000 (09:38 -0700)]
USB: serial: option: add cinterion device id

commit 6f44bcb60bfa58590142545096b64f44144f0bc1 upstream.

This adds a device id for a Cinterion device.

Reported-by: John Race <John.Race@roscom.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: option.c: Add Pirelli VID/PID and indicate Pirelli's modem interface is 0xff
spark [Fri, 5 Mar 2010 06:18:05 +0000 (14:18 +0800)]
USB: option.c: Add Pirelli VID/PID and indicate Pirelli's modem interface is 0xff

commit 33c387529b7931248c6637bf9720ac7504a0b28b upstream.

Signed-off-by: spark <spark@bandrich.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: option: add PID for ZTE product
zhao1980ming [Sun, 2 May 2010 16:06:37 +0000 (00:06 +0800)]
USB: option: add PID for ZTE product

commit a71ee85e1d74e862d68cc9b2f2ab6a806d2550c9 upstream.

this patch adds ZTE modem devices

Signed-off-by: Joey <zhao.ming9@zte.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: kobil: fix memory leak
Johan Hovold [Sat, 15 May 2010 15:53:43 +0000 (17:53 +0200)]
USB: kobil: fix memory leak

commit c0f631d1948658b27349545b2cbcb4b32f010c7a upstream.

An urb transfer buffer is allocated at every open but was never freed.

This driver is a bit of a mess...

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: CP210x New Device IDs 11 New device IDs
Craig Shelley [Sat, 15 May 2010 12:36:38 +0000 (13:36 +0100)]
USB: CP210x New Device IDs 11 New device IDs

commit eefd9029fde4d90d59804eeb54880ab8db5c1866 upstream.

Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoUSB: visor: fix memory leak
Johan Hovold [Sat, 15 May 2010 15:53:48 +0000 (17:53 +0200)]
USB: visor: fix memory leak

commit 199b113978015309dd02c69844c19a1be3f4dbcf upstream.

Fix memory leak for some devices (Sony Clie 3.5) due to port private
data not being freed on release.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoar9170usb: fix panic triggered by undersized rxstream buffer
Christian Lamparter [Tue, 23 Mar 2010 20:51:14 +0000 (21:51 +0100)]
ar9170usb: fix panic triggered by undersized rxstream buffer

commit 879999cec9489f8942ebce3ec1b5f23ef948dda7 upstream.

While ar9170's USB transport packet size is currently set to 8KiB,
the PHY is capable of receiving AMPDUs with up to 64KiB.
Such a large frame will be split over several rx URBs and
exceed the previously allocated space for rx stream reconstruction.

This patch increases the buffer size to 64KiB which is
in fact the phy & rx stream designed size limit.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=15591
Reported-by: Christian Mehlis <mehlis@inf.fu-berlin.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoar9170usb: add a couple more USB IDs
Christian Lamparter [Tue, 13 Apr 2010 16:10:26 +0000 (18:10 +0200)]
ar9170usb: add a couple more USB IDs

commit 94d0bbe849190255b93fede8eb46809a38f9b8bf upstream.

This patch adds the following 5 entries to the usbid device table:

 * Netgear WNA1000
 * Proxim ORiNOCO Dual Band 802.11n USB Adapter
 * 3Com Dual Band 802.11n USB Adapter
 * H3C Dual Band 802.11n USB Adapter
 * WNC Generic 11n USB dongle

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoHID: Add the GYR4101US USB ID to hid-gyration
Cory Maccarrone [Sat, 22 May 2010 20:00:28 +0000 (13:00 -0700)]
HID: Add the GYR4101US USB ID to hid-gyration

commit c2fd1a4ebf9127c280d227acb635eb1df213439c upstream.

This change adds in the USB product ID for the Gyration
GYR4101US USB media center remote control.  This remote
is similar enough to the other two devices that this driver
can be used without any other changes to get full support
for the remote.

Signed-off-by: Cory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoV4L/DVB: gspca - stv06xx: Remove the 046d:08da from the stv06xx driver
Erik Andrén [Mon, 8 Mar 2010 20:16:00 +0000 (17:16 -0300)]
V4L/DVB: gspca - stv06xx: Remove the 046d:08da from the stv06xx driver

commit 55e0b489a39bb635a44f769d620e44c70d9c065b upstream.

The 046d:08da usb id shouldn't be associated with the stv06xx driver as they're
not compatible with each other.
This fixes a bug where Quickcam Messenger cams fail to use its proper driver
(gspca-zc3xx), rendering the camera inoperable.

Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Tested-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoACPI: video: fix acpi_backlight=video
Kamal Mostafa [Sat, 1 May 2010 19:09:49 +0000 (12:09 -0700)]
ACPI: video: fix acpi_backlight=video

commit eeb4bcb4771679d7b3446c0293334faee11b090a upstream.

Make "acpi_backlight=video" param enable ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO
as intended, instead of incorrectly enabling video output switching.

BugLink: http://bugs.launchpad.net/bugs/573120
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Acked-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: hda: Use LPIB for a Shuttle device
Daniel T Chen [Sat, 29 May 2010 15:04:11 +0000 (11:04 -0400)]
ALSA: hda: Use LPIB for a Shuttle device

commit 61bb42c37dfa9016dcacc86bcd41362ab2457d4a upstream.

BugLink: https://launchpad.net/bugs/551949
Symptom: On the reporter's Shuttle device, using PulseAudio in Ubuntu
10.04 LTS results in "popping clicking" audio with the PA crashing
shortly thereafter.

Test case: Using Ubuntu 10.04 LTS (Linux 2.6.32.12), Linux 2.6.33, or
Linux 2.6.34, adjust the HDA device's volume with PulseAudio.

Resolution: add SSID for this machine to the position_fix quirk table,
explicitly specifying the LPIB method.

Reported-and-Tested-By: Christian Mehlis <mehlis@inf.fu-berlin.de>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: hda: Use LPIB for Sony VPCS11V9E
Daniel T Chen [Thu, 27 May 2010 22:32:18 +0000 (18:32 -0400)]
ALSA: hda: Use LPIB for Sony VPCS11V9E

commit e96d3127760a2fc509bca6bf7e61e8bc61497aeb upstream.

BugLink: https://launchpad.net/bugs/586347
Symptom: On the Sony VPCS11V9E, using GStreamer-based applications with
PulseAudio in Ubuntu 10.04 LTS results in stuttering audio. It appears
to worsen with increased I/O.

Test case: use Rhythmbox under increased I/O pressure. This symptom is
reproducible in the current daily stable alsa-driver snapshots (at least
up until 21 May 2010; later snapshots fail to build from source due to
missing preprocessor directives when compiled against 2.6.32).

Resolution: add SSID for this machine to the position_fix quirk table,
explicitly specifying the LPIB method.

Reported-and-Tested-By: Lauri Kainulainen <lauri@sokkelo.net>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: hda: Use LPIB for Acer Aspire 5110
Daniel T Chen [Sat, 22 May 2010 16:05:41 +0000 (12:05 -0400)]
ALSA: hda: Use LPIB for Acer Aspire 5110

commit 7a68be94e22e7643038726ebc14360752a91800b upstream.

BugLink: https://launchpad.net/bugs/583983
Symptom: on a significant number of hardware, booting from a live cd
results in capture working correctly, but once the distribution is
installed, booting from the install results in capture not working.

Test case: boot from Ubuntu 10.04 LTS live cd; capture works correctly.
Install to HD and reboot; capture does not work. Reproduced with 2.6.32
mainline build (vanilla kernel.org compile).

Resolution: add SSID for Acer Aspire 5110 to the position_fix quirk
table, explicitly specifying the LPIB method.

I'll be sending additional patches for these SSIDs as bug reports are
confirmed.

Reported-and-Tested-By: Leo
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: hda: Use LPIB for Toshiba A100-259
Daniel T Chen [Sat, 22 May 2010 17:12:22 +0000 (13:12 -0400)]
ALSA: hda: Use LPIB for Toshiba A100-259

commit 4e0938dba7fccf37a4aecba4d937da7f312b5d55 upstream.

BugLink: https://launchpad.net/bugs/549560
Symptom: on a significant number of hardware, booting from a live cd
results in capture working correctly, but once the distribution is
installed, booting from the install results in capture not working.

Test case: boot from Ubuntu 10.04 LTS live cd; capture works correctly.
Install to HD and reboot; capture does not work. Reproduced with 2.6.32
mainline build (vanilla kernel.org compile)

Resolution: add SSID for Toshiba A100-259 to the position_fix quirk
table, explicitly specifying the LPIB method.

I'll be sending additional patches for these SSIDs as bug reports are
confirmed.

This patch also trivially sorts the quirk table in ascending order by
subsystem vendor.

Reported-and-Tested-by: <davide.molteni@gmail.com>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: hda: Fix model quirk for Dell M1730
Daniel T Chen [Mon, 24 May 2010 00:47:45 +0000 (20:47 -0400)]
ALSA: hda: Fix model quirk for Dell M1730

commit 66668b6fb6861fad7f6bfef6646ac84693474c9a upstream.

BugLink: https://launchpad.net/bugs/576160
Symptom: Currently (2.6.32.12) the Dell M1730 uses the 3stack model
quirk. Unfortunately this means that capture is not functional out-
of-the-box despite ensuring that capture settings are unmuted and
raised fully.

Test case: boot from Ubuntu 10.04 LTS live cd; capture does not
work.

Resolution: Correct the model quirk for Dell M1730 to rely on the
BIOS configuration.

This patch also trivially sorts the quirk into the correct section
based on the comments.

Reported-and-Tested-By: <picdragon99@msn.com>
Tested-By: Daren Hayward
Tested-By: Tobias Krais
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomutex: Fix optimistic spinning vs. BKL
Tony Breeds [Wed, 19 May 2010 05:46:36 +0000 (15:46 +1000)]
mutex: Fix optimistic spinning vs. BKL

commit fd6be105b883244127a734ac9f14ae94a022dcc0 upstream.

Currently, we can hit a nasty case with optimistic
spinning on mutexes:

    CPU A tries to take a mutex, while holding the BKL

    CPU B tried to take the BLK while holding the mutex

This looks like a AB-BA scenario but in practice, is
allowed and happens due to the auto-release on
schedule() nature of the BKL.

In that case, the optimistic spinning code can get us
into a situation where instead of going to sleep, A
will spin waiting for B who is spinning waiting for
A, and the only way out of that loop is the
need_resched() test in mutex_spin_on_owner().

This patch fixes it by completely disabling spinning
if we own the BKL. This adds one more detail to the
extensive list of reasons why it's a bad idea for
kernel code to be holding the BKL.

Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
LKML-Reference: <20100519054636.GC12389@ozlabs.org>
[ added an unlikely() attribute to the branch ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agolibata: don't flush dcache on slab pages
Sebastian Andrzej Siewior [Sun, 21 Mar 2010 21:52:23 +0000 (22:52 +0100)]
libata: don't flush dcache on slab pages

commit 3842e835490cdf17013b30a788f6311bdcfd0571 upstream.

page_mapping() check this via VM_BUG_ON(PageSlab(page)) so we bug here
with the according debuging turned on.

Future TODO: replace this with a flush_dcache_page_for_pio() API

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agolibata: disable ATAPI AN by default
Tejun Heo [Wed, 19 May 2010 13:38:58 +0000 (15:38 +0200)]
libata: disable ATAPI AN by default

commit e7ecd435692ca9bde9d124be30b3a26e672ea6c2 upstream.

There are ATAPI devices which raise AN when hit by commands issued by
open().  This leads to infinite loop of AN -> MEDIA_CHANGE uevent ->
udev open() to check media -> AN.

Both ACS and SerialATA standards don't define in which case ATAPI
devices are supposed to raise or not raise AN.  They both list media
insertion event as a possible use case for ATAPI ANs but there is no
clear description of what constitutes such events.  As such, it seems
a bit too naive to export ANs directly to userland as MEDIA_CHANGE
events without further verification (which should behave similarly to
windows as it apparently is the only thing that some hardware vendors
are testing against).

This patch adds libata.atapi_an module parameter and disables ATAPI AN
by default for now.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Nick Bowler <nbowler@elliptictech.com>
Cc: David Zeuthen <david@fubar.dk>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoposix_timer: Fix error path in timer_create
Andrey Vagin [Mon, 24 May 2010 19:15:33 +0000 (12:15 -0700)]
posix_timer: Fix error path in timer_create

commit 45e0fffc8a7778282e6a1514a6ae3e7ae6545111 upstream.

Move CLOCK_DISPATCH(which_clock, timer_create, (new_timer)) after all
posible EFAULT erros.

*_timer_create may allocate/get resources.
(for example posix_cpu_timer_create does get_task_struct)

[ tglx: fold the remove crappy comment patch into this ]

Signed-off-by: Andrey Vagin <avagin@openvz.org>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Pavel Emelyanov <xemul@openvz.org>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoFix racy use of anon_inode_getfd() in perf_event.c
Al Viro [Wed, 26 May 2010 21:40:29 +0000 (17:40 -0400)]
Fix racy use of anon_inode_getfd() in perf_event.c

commit ea635c64e007061f6468ece5cc9cc62d41d4ecf2 upstream.

once anon_inode_getfd() is called, you can't expect *anything* about
struct file that descriptor points to - another thread might be doing
whatever it likes with descriptor table at that point.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agostaging: vt6655: Fix kernel BUG on driver wpa initialization
Larry Finger [Mon, 10 May 2010 03:10:02 +0000 (22:10 -0500)]
staging: vt6655: Fix kernel BUG on driver wpa initialization

commit f65515275ea3e45fdcd0fb78455f542d6fdca086 upstream.

In http://bugzilla.novell.com/show_bug.cgi?id=597299, the vt6655 driver
generates a kernel BUG on a NULL pointer dereference at NULL. This problem
has been traced to a failure in the wpa_set_wpadev() routine. As the vt6656
driver does not call this routine, the vt6655 code is similarly set to skip
the call.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Richard Meek <osl2008@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoStaging: add Add Sitecom WL-349 to rtl8192su
Rodrigo Linfati [Wed, 28 Apr 2010 20:32:13 +0000 (22:32 +0200)]
Staging: add Add Sitecom WL-349 to rtl8192su

commit 64a5a09218626464be35e0229d85b2ab0fcf03fd upstream.

Add usb id of Sitecom WL-349 to rtl8192su

Signed-off-by: Rodrigo Linfati <rodrigo@linfati.cl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agortl8180: fix tx status reporting
John W. Linville [Wed, 28 Apr 2010 23:14:42 +0000 (19:14 -0400)]
rtl8180: fix tx status reporting

commit d989ff7cf8d14f1b523f63ba0bf2ec1a9b7c25bc upstream.

When reporting Tx status, indicate that only one rate was used.
Otherwise, the rate is frozen at rate index 0 (i.e. 1Mb/s).

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoARCNET: Limit com20020 PCI ID matches for SOHARD cards
Andreas Bombe [Tue, 18 May 2010 06:12:46 +0000 (23:12 -0700)]
ARCNET: Limit com20020 PCI ID matches for SOHARD cards

commit e7971c80a8e0299f91272ad8e8ac4167623e1862 upstream.

The SH SOHARD ARCNET cards are implemented using generic PLX Technology
PCI<->IOBus bridges. Subvendor and subdevice IDs were not specified,
causing the driver to attach to any such bridge and likely crash the
system by attempting to initialize an unrelated device.

Fix by specifying subvendor and subdevice according to the values found
in the PCI-ID Repository at http://pci-ids.ucw.cz/ .

Signed-off-by: Andreas Bombe <aeb@debian.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agosata_nv: use ata_pci_sff_activate_host() instead of ata_host_activate()
Tejun Heo [Fri, 14 May 2010 09:48:50 +0000 (11:48 +0200)]
sata_nv: use ata_pci_sff_activate_host() instead of ata_host_activate()

commit 95cc2c70c139936a2142bcd583da8af6f9d88efb upstream.

sata_nv was incorrectly using ata_host_activate() instead of
ata_pci_sff_activate_host() leading to IRQ assignment failure in
legacy mode.  Fix it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoNFSD: don't report compiled-out versions as present
Pavel Emelyanov [Fri, 14 May 2010 11:33:36 +0000 (15:33 +0400)]
NFSD: don't report compiled-out versions as present

commit 15ddb4aec54422ead137b03ea4e9b3f5db3f7cc2 upstream.

The /proc/fs/nfsd/versions file calls nfsd_vers() to check whether
the particular nfsd version is present/available. The problem is
that once I turn off e.g. NFSD-V4 this call returns -1 which is
true from the callers POV which is wrong.

The proposal is to report false in that case.

The bug has existed since 6658d3a7bbfd1768 "[PATCH] knfsd: remove
nfsd_versbits as intermediate storage for desired versions".

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agocpumask: fix compat getaffinity
KOSAKI Motohiro [Wed, 19 May 2010 00:37:41 +0000 (09:37 +0900)]
cpumask: fix compat getaffinity

commit fa9dc265ace9774e62f0e31108e5f47911124bda upstream.

Commit a45185d2d "cpumask: convert kernel/compat.c" broke libnuma, which
abuses sched_getaffinity to find out NR_CPUS in order to parse
/sys/devices/system/node/node*/cpumap.

On NUMA systems with less than 32 possibly CPUs, the current
compat_sys_sched_getaffinity now returns '4' instead of the actual
NR_CPUS/8, which makes libnuma bail out when parsing the cpumap.

The libnuma call sched_getaffinity(0, bitmap, 4096) at first.  It mean
the libnuma expect the return value of sched_getaffinity() is either len
argument or NR_CPUS.  But it doesn't expect to return nr_cpu_ids.

Strictly speaking, userland requirement are

1) Glibc assume the return value mean the lengh of initialized
   of mask argument. E.g. if sched_getaffinity(1024) return 128,
   glibc make zero fill rest 896 byte.
2) Libnuma assume the return value can be used to guess NR_CPUS
   in kernel. It assume len-arg<NR_CPUS makes -EINVAL. But
   it try len=4096 at first and 4096 is always bigger than
   NR_CPUS. Then, if we remove strange min_length normalization,
   we never hit -EINVAL case.

sched_getaffinity() already solved this issue.  This patch adapts
compat_sys_sched_getaffinity() to match the non-compat case.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Ken Werner <ken.werner@web.de>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agooprofile: remove double ring buffering
Andi Kleen [Thu, 1 Apr 2010 01:17:25 +0000 (03:17 +0200)]
oprofile: remove double ring buffering

commit cb6e943ccf19ab6d3189147e9d625a992e016084 upstream.

oprofile used a double buffer scheme for its cpu event buffer
to avoid races on reading with the old locked ring buffer.

But that is obsolete now with the new ring buffer, so simply
use a single buffer. This greatly simplifies the code and avoids
a lot of sample drops on large runs, especially with call graph.

Based on suggestions from Steven Rostedt

For stable kernels from v2.6.32, but not earlier.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agooprofile/x86: fix uninitialized counter usage during cpu hotplug
Robert Richter [Mon, 3 May 2010 17:44:32 +0000 (19:44 +0200)]
oprofile/x86: fix uninitialized counter usage during cpu hotplug

commit 2623a1d55a6260c855e1f6d1895900b50b40a896 upstream.

This fixes a NULL pointer dereference that is triggered when taking a
cpu offline after oprofile was initialized, e.g.:

 $ opcontrol --init
 $ opcontrol --start-daemon
 $ opcontrol --shutdown
 $ opcontrol --deinit
 $ echo 0 > /sys/devices/system/cpu/cpu1/online

See the crash dump below. Though the counter has been disabled the cpu
notifier is still active and trying to use already freed counter data.

This fix is for linux-stable. To proper fix this, the hotplug code
must be rewritten. Thus I will leave a WARN_ON_ONCE() message with
this patch.

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff8132ad57>] op_amd_stop+0x2d/0x8e
PGD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu1/online
CPU 1
Modules linked in:

Pid: 0, comm: swapper Not tainted 2.6.34-rc5-oprofile-x86_64-standard-00210-g8c00f06 #16 Anaheim/Anaheim
RIP: 0010:[<ffffffff8132ad57>]  [<ffffffff8132ad57>] op_amd_stop+0x2d/0x8e
RSP: 0018:ffff880001843f28  EFLAGS: 00010006
RAX: 0000000000000000 RBX: 0000000000000000 RCX: dead000000200200
RDX: ffff880001843f68 RSI: dead000000100100 RDI: 0000000000000000
RBP: ffff880001843f48 R08: 0000000000000000 R09: ffff880001843f08
R10: ffffffff8102c9a5 R11: ffff88000184ea80 R12: 0000000000000000
R13: ffff88000184f6c0 R14: 0000000000000000 R15: 0000000000000000
FS:  00007fec6a92e6f0(0000) GS:ffff880001840000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000000163b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffff88042fcd8000, task ffff88042fcd51d0)
Stack:
 ffff880001843f48 0000000000000001 ffff88042e9f7d38 ffff880001843f68
<0> ffff880001843f58 ffffffff8132a602 ffff880001843f98 ffffffff810521b3
<0> ffff880001843f68 ffff880001843f68 ffff880001843f88 ffff88042fcd9fd8
Call Trace:
 <IRQ>
 [<ffffffff8132a602>] nmi_cpu_stop+0x21/0x23
 [<ffffffff810521b3>] generic_smp_call_function_single_interrupt+0xdf/0x11b
 [<ffffffff8101804f>] smp_call_function_single_interrupt+0x22/0x31
 [<ffffffff810029f3>] call_function_single_interrupt+0x13/0x20
 <EOI>
 [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12
 [<ffffffff81008701>] ? default_idle+0x22/0x37
 [<ffffffff8100896d>] c1e_idle+0xdf/0xe6
 [<ffffffff813f1170>] ? atomic_notifier_call_chain+0x13/0x15
 [<ffffffff810012fb>] cpu_idle+0x4b/0x7e
 [<ffffffff813e8a4e>] start_secondary+0x1ae/0x1b2
Code: 89 e5 41 55 49 89 fd 41 54 45 31 e4 53 31 db 48 83 ec 08 89 df e8 be f8 ff ff 48 98 48 83 3c c5 10 67 7a 81 00 74 1f 49 8b 45 08 <42> 8b 0c 20 0f 32 48 c1 e2 20 25 ff ff bf ff 48 09 d0 48 89 c2
RIP  [<ffffffff8132ad57>] op_amd_stop+0x2d/0x8e
 RSP <ffff880001843f28>
CR2: 0000000000000000
---[ end trace 679ac372d674b757 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 0, comm: swapper Tainted: G      D    2.6.34-rc5-oprofile-x86_64-standard-00210-g8c00f06 #16
Call Trace:
 <IRQ>  [<ffffffff813ebd6a>] panic+0x9e/0x10c
 [<ffffffff810474b0>] ? up+0x34/0x39
 [<ffffffff81031ccc>] ? kmsg_dump+0x112/0x12c
 [<ffffffff813eeff1>] oops_end+0x81/0x8e
 [<ffffffff8101efee>] no_context+0x1f3/0x202
 [<ffffffff8101f1b7>] __bad_area_nosemaphore+0x1ba/0x1e0
 [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a
 [<ffffffff810264dc>] ? activate_task+0x42/0x53
 [<ffffffff8102c967>] ? try_to_wake_up+0x272/0x284
 [<ffffffff8101f1eb>] bad_area_nosemaphore+0xe/0x10
 [<ffffffff813f0f3f>] do_page_fault+0x1c8/0x37c
 [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a
 [<ffffffff813ee55f>] page_fault+0x1f/0x30
 [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12
 [<ffffffff8132ad57>] ? op_amd_stop+0x2d/0x8e
 [<ffffffff8132ad46>] ? op_amd_stop+0x1c/0x8e
 [<ffffffff8132a602>] nmi_cpu_stop+0x21/0x23
 [<ffffffff810521b3>] generic_smp_call_function_single_interrupt+0xdf/0x11b
 [<ffffffff8101804f>] smp_call_function_single_interrupt+0x22/0x31
 [<ffffffff810029f3>] call_function_single_interrupt+0x13/0x20
 <EOI>  [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12
 [<ffffffff81008701>] ? default_idle+0x22/0x37
 [<ffffffff8100896d>] c1e_idle+0xdf/0xe6
 [<ffffffff813f1170>] ? atomic_notifier_call_chain+0x13/0x15
 [<ffffffff810012fb>] cpu_idle+0x4b/0x7e
 [<ffffffff813e8a4e>] start_secondary+0x1ae/0x1b2
------------[ cut here ]------------
WARNING: at /local/rrichter/.source/linux/arch/x86/kernel/smp.c:118 native_smp_send_reschedule+0x27/0x53()
Hardware name: Anaheim
Modules linked in:
Pid: 0, comm: swapper Tainted: G      D    2.6.34-rc5-oprofile-x86_64-standard-00210-g8c00f06 #16
Call Trace:
 <IRQ>  [<ffffffff81017f32>] ? native_smp_send_reschedule+0x27/0x53
 [<ffffffff81030ee2>] warn_slowpath_common+0x77/0xa4
 [<ffffffff81030f1e>] warn_slowpath_null+0xf/0x11
 [<ffffffff81017f32>] native_smp_send_reschedule+0x27/0x53
 [<ffffffff8102634b>] resched_task+0x60/0x62
 [<ffffffff8102653a>] check_preempt_curr_idle+0x10/0x12
 [<ffffffff8102c8ea>] try_to_wake_up+0x1f5/0x284
 [<ffffffff8102c986>] default_wake_function+0xd/0xf
 [<ffffffff810a110d>] pollwake+0x57/0x5a
 [<ffffffff8102c979>] ? default_wake_function+0x0/0xf
 [<ffffffff81026be5>] __wake_up_common+0x46/0x75
 [<ffffffff81026ed0>] __wake_up+0x38/0x50
 [<ffffffff81031694>] printk_tick+0x39/0x3b
 [<ffffffff8103ac37>] update_process_times+0x3f/0x5c
 [<ffffffff8104dc63>] tick_periodic+0x5d/0x69
 [<ffffffff8104dc90>] tick_handle_periodic+0x21/0x71
 [<ffffffff81018fd0>] smp_apic_timer_interrupt+0x82/0x95
 [<ffffffff81002853>] apic_timer_interrupt+0x13/0x20
 [<ffffffff81030cb5>] ? panic_blink_one_second+0x0/0x7b
 [<ffffffff813ebdd6>] ? panic+0x10a/0x10c
 [<ffffffff810474b0>] ? up+0x34/0x39
 [<ffffffff81031ccc>] ? kmsg_dump+0x112/0x12c
 [<ffffffff813eeff1>] ? oops_end+0x81/0x8e
 [<ffffffff8101efee>] ? no_context+0x1f3/0x202
 [<ffffffff8101f1b7>] ? __bad_area_nosemaphore+0x1ba/0x1e0
 [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a
 [<ffffffff810264dc>] ? activate_task+0x42/0x53
 [<ffffffff8102c967>] ? try_to_wake_up+0x272/0x284
 [<ffffffff8101f1eb>] ? bad_area_nosemaphore+0xe/0x10
 [<ffffffff813f0f3f>] ? do_page_fault+0x1c8/0x37c
 [<ffffffff81028d24>] ? enqueue_task_fair+0x16d/0x17a
 [<ffffffff813ee55f>] ? page_fault+0x1f/0x30
 [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12
 [<ffffffff8132ad57>] ? op_amd_stop+0x2d/0x8e
 [<ffffffff8132ad46>] ? op_amd_stop+0x1c/0x8e
 [<ffffffff8132a602>] ? nmi_cpu_stop+0x21/0x23
 [<ffffffff810521b3>] ? generic_smp_call_function_single_interrupt+0xdf/0x11b
 [<ffffffff8101804f>] ? smp_call_function_single_interrupt+0x22/0x31
 [<ffffffff810029f3>] ? call_function_single_interrupt+0x13/0x20
 <EOI>  [<ffffffff8102c9a5>] ? wake_up_process+0x10/0x12
 [<ffffffff81008701>] ? default_idle+0x22/0x37
 [<ffffffff8100896d>] ? c1e_idle+0xdf/0xe6
 [<ffffffff813f1170>] ? atomic_notifier_call_chain+0x13/0x15
 [<ffffffff810012fb>] ? cpu_idle+0x4b/0x7e
 [<ffffffff813e8a4e>] ? start_secondary+0x1ae/0x1b2
---[ end trace 679ac372d674b758 ]---

Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoixgbe: Fix return of invalid txq
Krishna Kumar [Wed, 3 Feb 2010 13:13:10 +0000 (13:13 +0000)]
ixgbe: Fix return of invalid txq

commit fdd3d631cddad20ad9d3e1eb7dbf26825a8a121f upstream.

a developer had complained of getting lots of warnings:

"eth16 selects TX queue 98, but real number of TX queues is 64"

http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg02200.html

As there was no follow up on that bug, I am submitting this
patch assuming that the other return points will not return
invalid txq's, and also that this fixes the bug (not tested).

Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoLinux 2.6.32.15
Greg Kroah-Hartman [Tue, 1 Jun 2010 16:56:03 +0000 (09:56 -0700)]
Linux 2.6.32.15

14 years agoRevert "modules: fix incorrect percpu usage"
Greg Kroah-Hartman [Tue, 1 Jun 2010 16:46:01 +0000 (09:46 -0700)]
Revert "modules: fix incorrect percpu usage"

This reverts commit ea0a09acd81c6d52c77d80f0d4089795df7bcb58.

It should not have been applied to the .32 kernel tree.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoRevert "lockdep: fix incorrect percpu usage"
Greg Kroah-Hartman [Tue, 1 Jun 2010 16:45:46 +0000 (09:45 -0700)]
Revert "lockdep: fix incorrect percpu usage"

This reverts commit b6b3dcd55e2327a968833ff3f22eda3b8dd7ef9e.

It should not have been applied to the .32 kernel tree

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoLinux 2.6.32.14
Greg Kroah-Hartman [Wed, 26 May 2010 21:29:57 +0000 (14:29 -0700)]
Linux 2.6.32.14

14 years agoRevert "parisc: Set PCI CLS early in boot."
Greg Kroah-Hartman [Mon, 24 May 2010 21:58:13 +0000 (14:58 -0700)]
Revert "parisc: Set PCI CLS early in boot."

This reverts the following patch, which shouldn't have been applied
to the .32 stable tree as it causes problems.

  commit 5fd4514bb351b5ecb0da3692fff70741e5ed200c upstream.

  Set the PCI CLS early in the boot process to prevent
  device failures. In pcibios_set_master use the new
  pci_cache_line_size instead of a hard-coded value.

Signed-off-by: Carlos O'Donell <carlos@codesourcery.com>
Reviewed-by: Grant Grundler <grundler@google.com>
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agocrypto: authenc - Add EINPROGRESS check
Herbert Xu [Mon, 26 Apr 2010 01:14:05 +0000 (09:14 +0800)]
crypto: authenc - Add EINPROGRESS check

commit 180ce7e81030e1ef763d58f97f9ab840ff57d848 upstream.

When Steffen originally wrote the authenc async hash patch, he
correctly had EINPROGRESS checks in place so that we did not invoke
the original completion handler with it.

Unfortuantely I told him to remove it before the patch was applied.

As only MAY_BACKLOG request completion handlers are required to
handle EINPROGRESS completions, those checks are really needed.

This patch restores them.

Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoRevert "ath9k: fix lockdep warning when unloading module" on stable kernels
Luis R. Rodriguez [Wed, 19 May 2010 21:33:49 +0000 (17:33 -0400)]
Revert "ath9k: fix lockdep warning when unloading module" on stable kernels

Johannes' patch 34e8950 titled:

mac80211: allow station add/remove to sleep

changed the way mac80211 adds and removes peers. The new
sta_add() / sta_remove() callbacks allowed the driver callbacks
to sleep. Johannes also ported ath9k to use sta_add() / sta_remove()
via the patch 4ca7786 titled:

ath9k: convert to new station add/remove callbacks

but this patch forgot to address a change in locking issue which
Ming Lei eventually found on his 2.6.33-wl #12 build. The 2.6.33-wl
build includes code for the 802.11 subsystem for 2.6.34 though so did
already have the above two patches (ath9k_sta_remove() on his trace),
the 2.6.33 kernel did not however have these two patches. Ming eventually
cured his lockdep warnign via the patch a9f042c titled:

ath9k: fix lockdep warning when unloading module

This went in to 2.6.34 and although it was not marked as a stable
fix it did get trickled down and applied on both 2.6.33 and 2.6.32.

In review, the culprits:

mac80211: allow station add/remove to sleep
git describe --contains 34e895075e21be3e21e71d6317440d1ee7969ad0
v2.6.34-rc1~233^2~49^2~107

ath9k: convert to new station add/remove callbacks
git describe --contains 4ca778605cfec53d8a689f0b57babb93b030c784
v2.6.34-rc1~233^2~49^2~10

ath9k: fix lockdep warning when unloading module

This last one trickled down to 2.6.33 (OK), 2.6.33 (invalid) and 2.6.32 (invalid).

git describe --contains a9f042cbe5284f34ccff15f3084477e11b39b17b
v2.6.34-rc2~48^2~77^2~7
git describe --contains 0524bcfa80f1fffb4e1fe18a0a28900869a58a7c
v2.6.33.2~125
git describe --contains 0dcc9985f34aef3c60bffab3dfc7f7ba3748f35a
v2.6.32.11~79

The patch titled "ath9k: fix lockdep warning when unloading module"
should be reverted on both 2.6.33 and 2.6.32 as it is invalid and
actually ended up causing the following warning:

ADDRCONF(NETDEV_CHANGE): wlan31: link becomes ready
phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0
phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94
phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47
phy0: device now idle
------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x7b/0xa0()
Hardware name: 7660A14
Modules linked in: ath9k(-) mac80211 ath cfg80211 <whatever-bleh-etc>
Pid: 2003, comm: rmmod Not tainted 2.6.32.11 #6
Call Trace:
 [<ffffffff8105d178>] warn_slowpath_common+0x78/0xb0
 [<ffffffff8105d1bf>] warn_slowpath_null+0xf/0x20
 [<ffffffff81063f8b>] local_bh_enable_ip+0x7b/0xa0
 [<ffffffff815121e4>] _spin_unlock_bh+0x14/0x20
 [<ffffffffa034aea5>] ath_tx_node_cleanup+0x185/0x1b0 [ath9k]
 [<ffffffffa0345597>] ath9k_sta_notify+0x57/0xb0 [ath9k]
 [<ffffffffa02ac51a>] __sta_info_unlink+0x15a/0x260 [mac80211]
 [<ffffffffa02ac658>] sta_info_unlink+0x38/0x60 [mac80211]
 [<ffffffffa02b3fbe>] ieee80211_set_disassoc+0x1ae/0x210 [mac80211]
 [<ffffffffa02b42d9>] ieee80211_mgd_deauth+0x109/0x110 [mac80211]
 [<ffffffffa02ba409>] ieee80211_deauth+0x19/0x20 [mac80211]
 [<ffffffffa028160e>] __cfg80211_mlme_deauth+0xee/0x130 [cfg80211]
 [<ffffffff81118540>] ? init_object+0x50/0x90
 [<ffffffffa0285429>] __cfg80211_disconnect+0x159/0x1d0 [cfg80211]
 [<ffffffffa027125f>] cfg80211_netdev_notifier_call+0x10f/0x450 [cfg80211]
 [<ffffffff81514ca7>] notifier_call_chain+0x47/0x90
 [<ffffffff8107f501>] raw_notifier_call_chain+0x11/0x20
 [<ffffffff81442d66>] call_netdevice_notifiers+0x16/0x20
 [<ffffffff8144352d>] dev_close+0x4d/0xa0
 [<ffffffff814439a8>] rollback_registered+0x48/0x120
 [<ffffffff81443a9d>] unregister_netdevice+0x1d/0x70
 [<ffffffffa02b6cc4>] ieee80211_remove_interfaces+0x84/0xc0 [mac80211]
 [<ffffffffa02aa072>] ieee80211_unregister_hw+0x42/0xf0 [mac80211]
 [<ffffffffa0347bde>] ath_detach+0x8e/0x180 [ath9k]
 [<ffffffffa0347ce1>] ath_cleanup+0x11/0x50 [ath9k]
 [<ffffffffa0351a2c>] ath_pci_remove+0x1c/0x20 [ath9k]
 [<ffffffff8129d712>] pci_device_remove+0x32/0x60
 [<ffffffff81332373>] __device_release_driver+0x53/0xb0
 [<ffffffff81332498>] driver_detach+0xc8/0xd0
 [<ffffffff81331405>] bus_remove_driver+0x85/0xe0
 [<ffffffff81332a5a>] driver_unregister+0x5a/0x90
 [<ffffffff8129da00>] pci_unregister_driver+0x40/0xb0
 [<ffffffffa03518d0>] ath_pci_exit+0x10/0x20 [ath9k]
 [<ffffffffa0353cd5>] ath9k_exit+0x9/0x2a [ath9k]
 [<ffffffff81092838>] sys_delete_module+0x1a8/0x270
 [<ffffffff8107ebe9>] ? up_read+0x9/0x10
 [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
---[ end trace fad957019ffdd40b ]---
phy0: Removed STA 00:22:6b:56:fd:e8
phy0: Destroyed STA 00:22:6b:56:fd:e8
wlan31: deauthenticating from 00:22:6b:56:fd:e8 by local choice (reason=3)
ath9k 0000:16:00.0: PCI INT A disabled

The original lockdep fixed an issue where due to the new changes
the driver was not disabling the bottom halves but it is incorrect
to do this on the older kernels since IRQs are already disabled.

Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agonilfs2: fix sync silent failure
Ryusuke Konishi [Mon, 3 May 2010 12:00:48 +0000 (21:00 +0900)]
nilfs2: fix sync silent failure

commit 973bec34bfc1bc2465646181653d67f767d418c8 upstream.

As of 32a88aa1, __sync_filesystem() will return 0 if s_bdi is not set.
And nilfs does not set s_bdi anywhere.  I noticed this problem by the
warning introduced by the recent commit 5129a469 ("Catch filesystem
lacking s_bdi").

 WARNING: at fs/super.c:959 vfs_kern_mount+0xc5/0x14e()
 Hardware name: PowerEdge 2850
 Modules linked in: nilfs2 loop tpm_tis tpm tpm_bios video shpchp pci_hotplug output dcdbas
 Pid: 3773, comm: mount.nilfs2 Not tainted 2.6.34-rc6-debug #38
 Call Trace:
  [<c1028422>] warn_slowpath_common+0x60/0x90
  [<c102845f>] warn_slowpath_null+0xd/0x10
  [<c1095936>] vfs_kern_mount+0xc5/0x14e
  [<c1095a03>] do_kern_mount+0x32/0xbd
  [<c10a811e>] do_mount+0x671/0x6d0
  [<c1073794>] ? __get_free_pages+0x1f/0x21
  [<c10a684f>] ? copy_mount_options+0x2b/0xe2
  [<c107b634>] ? strndup_user+0x48/0x67
  [<c10a81de>] sys_mount+0x61/0x8f
  [<c100280c>] sysenter_do_call+0x12/0x32

This ensures to set s_bdi for nilfs and fixes the sync silent failure.

Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Acked-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agommap_min_addr check CAP_SYS_RAWIO only for write
Kees Cook [Thu, 22 Apr 2010 19:19:17 +0000 (12:19 -0700)]
mmap_min_addr check CAP_SYS_RAWIO only for write

commit 4ae69e6b718589abe97c9625ccbb1e0bc95a8c0e upstream.

Redirecting directly to lsm, here's the patch discussed on lkml:
http://lkml.org/lkml/2010/4/22/219

The mmap_min_addr value is useful information for an admin to see without
being root ("is my system vulnerable to kernel NULL pointer attacks?") and
its setting is trivially easy for an attacker to determine by calling
mmap() in PAGE_SIZE increments starting at 0, so trying to keep it private
has no value.

Only require CAP_SYS_RAWIO if changing the value, not reading it.

Comment from Serge :

  Me, I like to write my passwords with light blue pen on dark blue
  paper, pasted on my window - if you're going to get my password, you're
  gonna get a headache.

Signed-off-by: Kees Cook <kees.cook@canonical.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
(cherry picked from commit 822cceec7248013821d655545ea45d1c6a9d15b3)
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agomegaraid_sas: fix for 32bit apps
Tomas Henzl [Thu, 11 Feb 2010 17:01:50 +0000 (18:01 +0100)]
megaraid_sas: fix for 32bit apps

commit b3dc1a212e5167984616445990c76056034f8eeb upstream.

It looks like this patch -

commit 7b2519afa1abd1b9f63aa1e90879307842422dae
Author: Yang, Bo <Bo.Yang@lsi.com>
Date:   Tue Oct 6 14:52:20 2009 -0600

    [SCSI] megaraid_sas: fix 64 bit sense pointer truncation

has caused a problem for 32bit programs with 64bit os -

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

fix by converting the user space 32bit pointer to a 64 bit one when
needed.

[jejb: fix up some 64 bit warnings]
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Cc: Bo Yang <Bo.Yang@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoCacheFiles: Fix error handling in cachefiles_determine_cache_security()
David Howells [Wed, 12 May 2010 14:34:03 +0000 (15:34 +0100)]
CacheFiles: Fix error handling in cachefiles_determine_cache_security()

commit 7ac512aa8237c43331ffaf77a4fd8b8d684819ba upstream.

cachefiles_determine_cache_security() is expected to return with a
security override in place.  However, if set_create_files_as() fails, we
fail to do this.  In this case, we should just reinstate the security
override that was set by the caller.

Furthermore, if set_create_files_as() fails, we should dispose of the
new credentials we were in the process of creating.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agop54: disable channels with incomplete calibration data sets
Christian Lamparter [Sat, 31 Oct 2009 21:59:27 +0000 (22:59 +0100)]
p54: disable channels with incomplete calibration data sets

commit 93a59d7527147e3656664aa3179f8d19de256081 upstream.

James Grossmann [1] reported that p54 spews out confusing
messages instead of preventing the mayhem from happening.

the reason is that "p54: generate channel list dynamically"
is not perfect. It didn't discard incomplete channel data
sets and therefore p54 advertised to support them as well.

[1]: http://marc.info/?l=linux-wireless&m=125699830215890

Cc: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: James Grossmann <cctsurf@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoiwlwifi: clear all the stop_queue flag after load firmware
Wey-Yi Guy [Tue, 9 Feb 2010 16:14:11 +0000 (08:14 -0800)]
iwlwifi: clear all the stop_queue flag after load firmware

commit a9e10fb9b1c6ad16e73cf2656951fce3a817611e upstream.

All the queues are awake and ready to use after loading firmware,
for firmware reload case, if any queues was stopped before
reload, mac80211 will wake those queues after restart hardware, so make
sure all the flag used to keep track of the queue status are
reset correctly.

Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agorevert "procfs: provide stack information for threads" and its fixup commits
Robin Holt [Tue, 11 May 2010 21:06:46 +0000 (14:06 -0700)]
revert "procfs: provide stack information for threads" and its fixup commits

commit 34441427aab4bdb3069a4ffcda69a99357abcb2e upstream.

Originally, commit d899bf7b ("procfs: provide stack information for
threads") attempted to introduce a new feature for showing where the
threadstack was located and how many pages are being utilized by the
stack.

Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
applied to fix the NO_MMU case.

Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
64-bit") was applied to fix a bug in ia32 executables being loaded.

Commit 9ebd4eba7 ("procfs: fix /proc/<pid>/stat stack pointer for kernel
threads") was applied to fix a bug which had kernel threads printing a
userland stack address.

Commit 1306d603f ('proc: partially revert "procfs: provide stack
information for threads"') was then applied to revert the stack pages
being used to solve a significant performance regression.

This patch nearly undoes the effect of all these patches.

The reason for reverting these is it provides an unusable value in
field 28.  For x86_64, a fork will result in the task->stack_start
value being updated to the current user top of stack and not the stack
start address.  This unpredictability of the stack_start value makes
it worthless.  That includes the intended use of showing how much stack
space a thread has.

Other architectures will get different values.  As an example, ia64
gets 0.  The do_fork() and copy_process() functions appear to treat the
stack_start and stack_size parameters as architecture specific.

I only partially reverted c44972f1 ("procfs: disable per-task stack usage
on NOMMU") .  If I had completely reverted it, I would have had to change
mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
configured.  Since I could not test the builds without significant effort,
I decided to not change mm/Makefile.

I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
information for threads on 64-bit") .  I left the KSTK_ESP() change in
place as that seemed worthwhile.

Signed-off-by: Robin Holt <holt@sgi.com>
Cc: Stefani Seibold <stefani@seibold.net>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Ingo Molnar <mingo@elte.hu>
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>
14 years agoproc: partially revert "procfs: provide stack information for threads"
KOSAKI Motohiro [Fri, 8 Jan 2010 22:42:56 +0000 (14:42 -0800)]
proc: partially revert "procfs: provide stack information for threads"

commit 1306d603fcf1f6682f8575d1ff23631a24184b21 upstream.

Commit d899bf7b (procfs: provide stack information for threads) introduced
to show stack information in /proc/{pid}/status.  But it cause large
performance regression.  Unfortunately /proc/{pid}/status is used ps
command too and ps is one of most important component.  Because both to
take mmap_sem and page table walk are heavily operation.

If many process run, the ps performance is,

[before d899bf7b]

% perf stat ps >/dev/null

 Performance counter stats for 'ps':

     4090.435806  task-clock-msecs         #      0.032 CPUs
             229  context-switches         #      0.000 M/sec
               0  CPU-migrations           #      0.000 M/sec
             234  page-faults              #      0.000 M/sec
      8587565207  cycles                   #   2099.425 M/sec
      9866662403  instructions             #      1.149 IPC
      3789415411  cache-references         #    926.409 M/sec
        30419509  cache-misses             #      7.437 M/sec

   128.859521955  seconds time elapsed

[after d899bf7b]

% perf stat  ps  > /dev/null

 Performance counter stats for 'ps':

     4305.081146  task-clock-msecs         #      0.028 CPUs
             480  context-switches         #      0.000 M/sec
               2  CPU-migrations           #      0.000 M/sec
             237  page-faults              #      0.000 M/sec
      9021211334  cycles                   #   2095.480 M/sec
     10605887536  instructions             #      1.176 IPC
      3612650999  cache-references         #    839.160 M/sec
        23917502  cache-misses             #      5.556 M/sec

   152.277819582  seconds time elapsed

Thus, this patch revert it. Fortunately /proc/{pid}/task/{tid}/smaps
provide almost same information. we can use it.

Commit d899bf7b introduced two features:

 1) Add the annotattion of [thread stack: xxxx] mark to
    /proc/{pid}/task/{tid}/maps.
 2) Add StackUsage field to /proc/{pid}/status.

I only revert (2), because I haven't seen (1) cause regression.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Stefani Seibold <stefani@seibold.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.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>
14 years agoALSA: hda - New Intel HDA controller
Vitaliy Kulikov [Mon, 15 Mar 2010 08:01:26 +0000 (09:01 +0100)]
ALSA: hda - New Intel HDA controller

commit c602c8ad45d6ee6ad91fc544513cc96f70790983 upstream.

Added a PCI controller id on new Dell laptops.

Signed-off-by: Vitaliy Kulikov <Vitaliy.Kulikov@idt.com>
Cc: AmenophisIII <AmenophisIII@gmx.at>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoBtrfs: check for read permission on src file in the clone ioctl
Dan Rosenberg [Sat, 15 May 2010 15:27:37 +0000 (11:27 -0400)]
Btrfs: check for read permission on src file in the clone ioctl

commit 5dc6416414fb3ec6e2825fd4d20c8bf1d7fe0395 upstream.

The existing code would have allowed you to clone a file that was
only open for writing

Signed-off-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agox86, amd: Check X86_FEATURE_OSVW bit before accessing OSVW MSRs
Andreas Herrmann [Tue, 27 Apr 2010 10:13:48 +0000 (12:13 +0200)]
x86, amd: Check X86_FEATURE_OSVW bit before accessing OSVW MSRs

commit f01487119dda3d9f58c9729c7361ecc50a61c188 upstream.

If host CPU is exposed to a guest the OSVW MSRs are not guaranteed
to be present and a GP fault occurs. Thus checking the feature flag is
essential.

Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
LKML-Reference: <20100427101348.GC4489@alberich.amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agox86, cacheinfo: Turn off L3 cache index disable feature in virtualized environments
Frank Arnold [Thu, 22 Apr 2010 14:06:59 +0000 (16:06 +0200)]
x86, cacheinfo: Turn off L3 cache index disable feature in virtualized environments

commit 7f284d3cc96e02468a42e045f77af11e5ff8b095 upstream.

When running a quest kernel on xen we get:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
IP: [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df
PGD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in:

Pid: 0, comm: swapper Tainted: G        W  2.6.34-rc3 #1 /HVM domU
RIP: 0010:[<ffffffff8142f2fb>]  [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x
2ca/0x3df
RSP: 0018:ffff880002203e08  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000060
RDX: 0000000000000000 RSI: 0000000000000040 RDI: 0000000000000000
RBP: ffff880002203ed8 R08: 00000000000017c0 R09: ffff880002203e38
R10: ffff8800023d5d40 R11: ffffffff81a01e28 R12: ffff880187e6f5c0
R13: ffff880002203e34 R14: ffff880002203e58 R15: ffff880002203e68
FS:  0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000038 CR3: 0000000001a3c000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a44020)
Stack:
 ffffffff810d7ecb ffff880002203e20 ffffffff81059140 ffff880002203e30
<0> ffffffff810d7ec9 0000000002203e40 000000000050d140 ffff880002203e70
<0> 0000000002008140 0000000000000086 ffff880040020140 ffffffff81068b8b
Call Trace:
 <IRQ>
 [<ffffffff810d7ecb>] ? sync_supers_timer_fn+0x0/0x1c
 [<ffffffff81059140>] ? mod_timer+0x23/0x25
 [<ffffffff810d7ec9>] ? arm_supers_timer+0x34/0x36
 [<ffffffff81068b8b>] ? hrtimer_get_next_event+0xa7/0xc3
 [<ffffffff81058e85>] ? get_next_timer_interrupt+0x19a/0x20d
 [<ffffffff8142fa23>] get_cpu_leaves+0x5c/0x232
 [<ffffffff8106a7b1>] ? sched_clock_local+0x1c/0x82
 [<ffffffff8106a9a0>] ? sched_clock_tick+0x75/0x7a
 [<ffffffff8107748c>] generic_smp_call_function_single_interrupt+0xae/0xd0
 [<ffffffff8101f6ef>] smp_call_function_single_interrupt+0x18/0x27
 [<ffffffff8100a773>] call_function_single_interrupt+0x13/0x20
 <EOI>
 [<ffffffff8143c468>] ? notifier_call_chain+0x14/0x63
 [<ffffffff810295c6>] ? native_safe_halt+0xc/0xd
 [<ffffffff810114eb>] ? default_idle+0x36/0x53
 [<ffffffff81008c22>] cpu_idle+0xaa/0xe4
 [<ffffffff81423a9a>] rest_init+0x7e/0x80
 [<ffffffff81b10dd2>] start_kernel+0x40e/0x419
 [<ffffffff81b102c8>] x86_64_start_reservations+0xb3/0xb7
 [<ffffffff81b103c4>] x86_64_start_kernel+0xf8/0x107
Code: 14 d5 40 ff ae 81 8b 14 02 31 c0 3b 15 47 1c 8b 00 7d 0e 48 8b 05 36 1c 8b
 00 48 63 d2 48 8b 04 d0 c7 85 5c ff ff ff 00 00 00 00 <8b> 70 38 48 8d 8d 5c ff
 ff ff 48 8b 78 10 ba c4 01 00 00 e8 eb
RIP  [<ffffffff8142f2fb>] cpuid4_cache_lookup_regs+0x2ca/0x3df
 RSP <ffff880002203e08>
CR2: 0000000000000038
---[ end trace a7919e7f17c0a726 ]---

The L3 cache index disable feature of AMD CPUs has to be disabled if the
kernel is running as guest on top of a hypervisor because northbridge
devices are not available to the guest. Currently, this fixes a boot
crash on top of Xen. In the future this will become an issue on KVM as
well.

Check if northbridge devices are present and do not enable the feature
if there are none.

[ hpa: backported to 2.6.34 ]

Signed-off-by: Frank Arnold <frank.arnold@amd.com>
LKML-Reference: <1271945222-5283-3-git-send-email-bp@amd64.org>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agox86, k8: Fix build error when K8_NB is disabled
Borislav Petkov [Sat, 24 Apr 2010 07:56:53 +0000 (09:56 +0200)]
x86, k8: Fix build error when K8_NB is disabled

commit ade029e2aaacc8965a548b0b0f80c5bee97ffc68 upstream.

K8_NB depends on PCI and when the last is disabled (allnoconfig) we fail
at the final linking stage due to missing exported num_k8_northbridges.
Add a header stub for that.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
LKML-Reference: <20100503183036.GJ26107@aftab>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoprofile: fix stats and data leakage
Hugh Dickins [Sat, 15 May 2010 02:44:10 +0000 (19:44 -0700)]
profile: fix stats and data leakage

commit 16a2164bb03612efe79a76c73da6da44445b9287 upstream.

If the kernel is large or the profiling step small, /proc/profile
leaks data and readprofile shows silly stats, until readprofile -r
has reset the buffer: clear the prof_buffer when it is vmalloc()ed.

Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoinotify: don't leak user struct on inotify release
Pavel Emelyanov [Wed, 12 May 2010 22:34:07 +0000 (15:34 -0700)]
inotify: don't leak user struct on inotify release

commit b3b38d842fa367d862b83e7670af4e0fd6a80fc0 upstream.

inotify_new_group() receives a get_uid-ed user_struct and saves the
reference on group->inotify_data.user.  The problem is that free_uid() is
never called on it.

Issue seem to be introduced by 63c882a0 (inotify: reimplement inotify
using fsnotify) after 2.6.30.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Eric Paris <eparis@parisplace.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoinotify: race use after free/double free in inotify inode marks
Eric Paris [Tue, 11 May 2010 21:17:40 +0000 (17:17 -0400)]
inotify: race use after free/double free in inotify inode marks

commit e08733446e72b983fed850fc5d8bd21b386feb29 upstream.

There is a race in the inotify add/rm watch code.  A task can find and
remove a mark which doesn't have all of it's references.  This can
result in a use after free/double free situation.

Task A Task B
------------ -----------
inotify_new_watch()
 allocate a mark (refcnt == 1)
 add it to the idr
inotify_rm_watch()
 inotify_remove_from_idr()
  fsnotify_put_mark()
      refcnt hits 0, free
 take reference because we are on idr
 [at this point it is a use after free]
 [time goes on]
 refcnt may hit 0 again, double free

The fix is to take the reference BEFORE the object can be found in the
idr.

Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: hda: Fix 0 dB for Lenovo models using Conexant CX20549 (Venice)
Daniel T Chen [Mon, 10 May 2010 19:50:04 +0000 (21:50 +0200)]
ALSA: hda: Fix 0 dB for Lenovo models using Conexant CX20549 (Venice)

commit 0ebf9e3692d640917fb792a7494d05e1f5b1058f upstream.

Reference: http://mailman.alsa-project.org/pipermail/alsa-devel/2010-May/027525.html

As reported on the mailing list, we also need to cap to the 0 dB offset
for Lenovo models, else the sound will be distorted.

Reported-and-Tested-by: Tim Starling <tstarling@wikimedia.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoALSA: ice1724 - Fix ESI Maya44 capture source control
Takashi Iwai [Wed, 12 May 2010 14:43:32 +0000 (16:43 +0200)]
ALSA: ice1724 - Fix ESI Maya44 capture source control

commit 8213466596bf10b75887754773ee13c10cf86f5c upstream.

The capture source control of maya44 was wrongly coded with the bit
shift instead of the bit mask.  Also, the slot for line-in was
wrongly assigned (slot 5 instead of 4).

Reported-by: Alex Chernyshoff <alexdsp@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoserial: imx.c: fix CTS trigger level lower to avoid lost chars
Valentin Longchamp [Wed, 5 May 2010 09:47:07 +0000 (11:47 +0200)]
serial: imx.c: fix CTS trigger level lower to avoid lost chars

commit 1c5250d6163dac28be3afabdfb6c723f107051b7 upstream.

The imx CTS trigger level is left at its reset value that is 32
chars. Since the RX FIFO has 32 entries, when CTS is raised, the
FIFO already is full. However, some serial port devices first empty
their TX FIFO before stopping when CTS is raised, resulting in lost
chars.

This patch sets the trigger level lower so that other chars arrive
after CTS is raised, there is still room for 16 of them.

Signed-off-by: Valentin Longchamp<valentin.longchamp@epfl.ch>
Tested-by: Philippe Rétornaz<philippe.retornaz@epfl.ch>
Acked-by: Wolfram Sang<w.sang@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agocifs: guard against hardlinking directories
Jeff Layton [Tue, 11 May 2010 18:59:55 +0000 (14:59 -0400)]
cifs: guard against hardlinking directories

commit 3d69438031b00c601c991ab447cafb7d5c3c59a6 upstream.

When we made serverino the default, we trusted that the field sent by the
server in the "uniqueid" field was actually unique. It turns out that it
isn't reliably so.

Samba, in particular, will just put the st_ino in the uniqueid field when
unix extensions are enabled. When a share spans multiple filesystems, it's
quite possible that there will be collisions. This is a server bug, but
when the inodes in question are a directory (as is often the case) and
there is a collision with the root inode of the mount, the result is a
kernel panic on umount.

Fix this by checking explicitly for directory inodes with the same
uniqueid. If that is the case, then we can assume that using server inode
numbers will be a problem and that they should be disabled.

Fixes Samba bugzilla 7407

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-and-Tested-by: Suresh Jayaraman <sjayaraman@suse.de>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agopowerpc/perf_event: Fix oops due to perf_event_do_pending call
Paul Mackerras [Tue, 13 Apr 2010 20:46:04 +0000 (20:46 +0000)]
powerpc/perf_event: Fix oops due to perf_event_do_pending call

commit 0fe1ac48bef018bed896307cd12f6ca9b5e704ab upstream.

Anton Blanchard found that large POWER systems would occasionally
crash in the exception exit path when profiling with perf_events.
The symptom was that an interrupt would occur late in the exit path
when the MSR[RI] (recoverable interrupt) bit was clear.  Interrupts
should be hard-disabled at this point but they were enabled.  Because
the interrupt was not recoverable the system panicked.

The reason is that the exception exit path was calling
perf_event_do_pending after hard-disabling interrupts, and
perf_event_do_pending will re-enable interrupts.

The simplest and cleanest fix for this is to use the same mechanism
that 32-bit powerpc does, namely to cause a self-IPI by setting the
decrementer to 1.  This means we can remove the tests in the exception
exit path and raw_local_irq_restore.

This also makes sure that the call to perf_event_do_pending from
timer_interrupt() happens within irq_enter/irq_exit.  (Note that
calling perf_event_do_pending from timer_interrupt does not mean that
there is a possible 1/HZ latency; setting the decrementer to 1 ensures
that the timer interrupt will happen immediately, i.e. within one
timebase tick, which is a few nanoseconds or 10s of nanoseconds.)

Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
14 years agoptrace: fix return value of do_syscall_trace_enter()
Gerald Schaefer [Wed, 12 May 2010 07:32:12 +0000 (09:32 +0200)]
ptrace: fix return value of do_syscall_trace_enter()

commit 545c174d1f093a462b4bb9131b23d5ea72a600e1 upstream.

strace may change the system call number, so regs->gprs[2] must not
be read before tracehook_report_syscall_entry(). This fixes a bug
where "strace -f" will hang after a vfork().

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>