Joerg Roedel [Wed, 3 Feb 2010 15:13:08 +0000 (16:13 +0100)]
x86/amd-iommu: Fix IOMMU-API initialization for iommu=pt
commit
f5325094379158e6b876ea0010c807bf7890ec8f upstream
This patch moves the initialization of the iommu-api out of
the dma-ops initialization code. This ensures that the
iommu-api is initialized even with iommu=pt.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rafael J. Wysocki [Thu, 4 Feb 2010 22:00:41 +0000 (14:00 -0800)]
pktgen: Fix freezing problem
commit
1b3f720bf033fde1fbb6231f9b156b918c5f68d8 upstream.
Add missing try_to_freeze() to one of the pktgen_thread_worker() code
paths so that it doesn't block suspend/hibernation.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=15006
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Thu, 28 Jan 2010 07:04:15 +0000 (16:04 +0900)]
ahci: add Acer G725 to broken suspend list
commit
cedc9bf906dae044443d403371c887affdb44168 upstream.
Acer G725 shares the same suspend problem with the HP laptops which
lose ATA devices on resume. New firmware which fixes the problem is
already available. Add G725 with old firmwares to the broken suspend
list.
This problem has been reported in bko#15104.
http://bugzilla.kernel.org/show_bug.cgi?id=15104
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Jani-Matti Hätinen <jani-matti.hatinen@iki.fi>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Catalin Marinas [Thu, 4 Feb 2010 06:04:50 +0000 (01:04 -0500)]
Call flush_dcache_page after PIO data transfers in libata-sff.c
commit
2d68b7fe55d9e19a8a868224ed0dfd6526568521 upstream.
flush_dcache_page() must be called after (!ATA_TFLAG_WRITE) the
data copying to avoid D-cache aliasing with user space or I-D cache
coherency issues (when reading data from an ATA device using PIO,
the kernel dirties the D-cache but there is no flush_dcache_page()
required on Harvard architectures).
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sergey Matyukevich [Tue, 2 Feb 2010 21:43:59 +0000 (13:43 -0800)]
rtc-fm3130: add missing braces
commit
f4b5162820de60204afa5c8639335f4931b7fb0c upstream.
Add missing braces for multiline 'if' statements in fm3130_probe.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: Sergey Lapin <slapin@ossfans.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>
Al Viro [Fri, 29 Jan 2010 03:11:38 +0000 (22:11 -0500)]
befs: fix leak
commit
8dd5ca532c2d2c2b85f16bc038ebfff05b8853e1 upstream.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Murray [Wed, 13 Jan 2010 12:45:03 +0000 (23:15 +1030)]
ALSA: hda - Improved MacBook (Pro) 5,1 / 5,2 support
commit
a76221d47ef2b73ff16c0fef00a784026308ea02 upstream.
This patch adds support for automatically muting the speakers when headphones
are inserted, as well as relabelling the headphone widgets from the
non-standard "HP" to the standard "Headphone" for the mb5 model.
Signed-off-by: Alex Murray <murray.alex@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Mon, 8 Feb 2010 23:00:39 +0000 (15:00 -0800)]
dst: call cond_resched() in dst_gc_task()
commit
2fc1b5dd99f66d93ffc23fd8df82d384c1a354c8 upstream.
Kernel bugzilla #15239
On some workloads, it is quite possible to get a huge dst list to
process in dst_gc_task(), and trigger soft lockup detection.
Fix is to call cond_resched(), as we run in process context.
Reported-by: Pawel Staszewski <pstaszewski@itcare.pl>
Tested-by: Pawel Staszewski <pstaszewski@itcare.pl>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Takashi Iwai [Fri, 12 Feb 2010 17:17:06 +0000 (18:17 +0100)]
ALSA: hda - use WARN_ON_ONCE() for zero-division detection
commit
d6d8bf549393484e906913f02fa3c9518a2819b6 upstream.
Replace the zero-division warning message with WARN_ON_ONCE() per the
advice by Linus. This shouldn't happen, but if it happens, it's
possible that the bug happens often due to buggy IRQs.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Matt Fleming [Fri, 11 Dec 2009 22:58:17 +0000 (22:58 +0000)]
sh: Couple kernel and user write page perm bits for CONFIG_X2TLB
commit
fcb4ebd678858850e8b029909064175cb627868d upstream.
pte_write() should check whether the permissions include either the user
or kernel write permission bits. Likewise, pte_wrprotect() needs to
remove both the kernel and user write bits.
Without this patch handle_tlbmiss() doesn't handle faulting in pages
from the P3 area (our vmalloc space) because of a write. Mappings of the
P3 space have the _PAGE_EXT_KERN_WRITE bit but not _PAGE_EXT_USER_WRITE.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kashyap, Desai [Mon, 25 Jan 2010 10:50:52 +0000 (16:20 +0530)]
SCSI: mptfusion : mptscsih_abort return value should be SUCCESS instead of value 0.
commit
9858ae38011d699d4c2fa7f3493a47accf43a0f5 upstream.
retval should be SUCCESS/FAILED which is defined at scsi.h
retval = 0 is directing wrong return value. It must be retval = SUCCESS.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wu Fengguang [Fri, 5 Feb 2010 20:02:13 +0000 (15:02 -0500)]
devmem: fix kmem write bug on memory holes
commit
c85e9a97c4102ce2e83112da850d838cfab5ab13 upstream
devmem: fix kmem write bug on memory holes
[ cebbert@redhat.com : backport to 2.6.32 ]
write_kmem() used to assume vwrite() always return the full buffer length.
However now vwrite() could return 0 to indicate memory hole. This
creates a bug that "buf" is not advanced accordingly.
Fix it to simply ignore the return value, hence the memory hole.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tejun Heo <tj@kernel.org>
Cc: Nick Piggin <npiggin@suse.de>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
KAMEZAWA Hiroyuki [Fri, 5 Feb 2010 20:01:09 +0000 (15:01 -0500)]
devmem: check vmalloc address on kmem read/write
commit
325fda71d0badc1073dc59f12a948f24ff05796a
[ cebbert@redhat.com : backport to 2.6.32 ]
devmem: check vmalloc address on kmem read/write
Otherwise vmalloc_to_page() will BUG().
This also makes the kmem read/write implementation aligned with mem(4):
"References to nonexistent locations cause errors to be returned." Here we
return -ENXIO (inspired by Hugh) if no bytes have been transfered to/from
user space, otherwise return partial read/write results.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wu Fengguang [Fri, 5 Feb 2010 20:00:52 +0000 (15:00 -0500)]
/dev/mem: introduce size_inside_page()
commit
f222318e9c3a315723e3524fb9d6566b2430db44 upstream
/dev/mem: introduce size_inside_page()
[ cebbert@redhat.com : backport to 2.6.32 ]
[ subset of original patch, for just /dev/kmem ]
Introduce size_inside_page() to replace duplicate /dev/mem code.
Also apply it to /dev/kmem, whose alignment logic was buggy.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Len Brown [Sat, 30 Jan 2010 23:01:42 +0000 (18:01 -0500)]
dell-wmi, hp-wmi, msi-wmi: check wmi_get_event_data() return value
commit
fda11e61ff8a4e3a8ebbd434e46560b67cc0ca9d upstream
[ backport to 2.6.32 ]
When acpi_evaluate_object() is passed ACPI_ALLOCATE_BUFFER,
the caller must kfree the returned buffer if AE_OK is returned.
The callers of wmi_get_event_data() pass ACPI_ALLOCATE_BUFFER,
and thus must check its return value before accessing
or kfree() on the buffer.
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Anisse Astier [Sat, 30 Jan 2010 23:00:17 +0000 (18:00 -0500)]
wmi: Free the allocated acpi objects through wmi_get_event_data
commit
3e9b988e4edf065d39c1343937f717319b1c1065 upstream
[ backported to 2.6.32 ]
These function allocate an acpi object by calling wmi_get_event_data, which
then calls acpi_evaluate_object, and it is not freed afterwards.
And kernel doc is fixed for parameters of wmi_get_event_data.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Herbert Xu [Sun, 31 Jan 2010 22:17:56 +0000 (09:17 +1100)]
crypto: padlock-sha - Add import/export support
commit
a8d7ac279743077965afeca0c9ed748507b68e89 upstream.
As the padlock driver for SHA uses a software fallback to perform
partial hashing, it must implement custom import/export functions.
Otherwise hmac which depends on import/export for prehashing will
not work with padlock-sha.
Reported-by: Wolfgang Walter <wolfgang.walter@stwm.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stefan Haberland [Mon, 7 Dec 2009 11:51:52 +0000 (12:51 +0100)]
dasd: remove strings from s390dbf
commit
b8ed5dd54895647c2690575aad6f07748c2c618a upstream.
Remove strings from s390 debugfeature entries that could lead to a
crash when the data is read from dbf because the strings do not exist
any more.
Signed-off-by: Stefan Haberland <stefan.haberland@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhenyu Wang [Wed, 25 Nov 2009 05:09:39 +0000 (13:09 +0800)]
drm/i915: Don't wait interruptible for possible plane buffer flush
commit
b9241ea31fae4887104e5d1b3b18f4009c25a0c4 upstream.
When we setup buffer for display plane, we'll check any pending
required GPU flush and possible make interruptible wait for flush
complete. But that wait would be most possibly to fail in case of
signals received for X process, which will then fail modeset process
and put display engine in unconsistent state. The result could be
blank screen or CPU hang, and DDX driver would always turn on outputs
DPMS after whatever modeset fails or not.
So this one creates new helper for setup display plane buffer, and
when needing flush using uninterruptible wait for that.
This one should fix bug like https://bugs.freedesktop.org/show_bug.cgi?id=24009.
Also fixing mode switch stress test on Ironlake.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Vetter [Tue, 15 Sep 2009 20:57:32 +0000 (22:57 +0200)]
drm/i915: add i915_lp_ring_sync helper
commit
48764bf43f746113fc77877d7e80f2df23ca4cbb upstream.
This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhenyu Wang [Mon, 28 Dec 2009 05:23:36 +0000 (13:23 +0800)]
drm/i915: remove full registers dump debug
commit
823f68fd646da6a39a9c0d3eb4c60d69dab5aa13 upstream.
This one reverts
9e3a6d155ed0a7636b926a798dd7221ea107b274.
As reported by http://bugzilla.kernel.org/show_bug.cgi?id=14485,
this dump will cause hang problem on some machine. If something
really needs this kind of full registers dump, that could be done
within intel-gpu-tools.
Cc: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Mon, 8 Feb 2010 19:18:07 +0000 (11:18 -0800)]
netfilter: nf_conntrack: fix hash resizing with namespaces
commit
d696c7bdaa55e2208e56c6f98e6bc1599f34286d upstream.
As noticed by Jon Masters <jonathan@jonmasters.org>, the conntrack hash
size is global and not per namespace, but modifiable at runtime through
/sys/module/nf_conntrack/hashsize. Changing the hash size will only
resize the hash in the current namespace however, so other namespaces
will use an invalid hash size. This can cause crashes when enlarging
the hashsize, or false negative lookups when shrinking it.
Move the hash size into the per-namespace data and only use the global
hash size to initialize the per-namespace value when instanciating a
new namespace. Additionally restrict hash resizing to init_net for
now as other namespaces are not handled currently.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexey Dobriyan [Mon, 8 Feb 2010 19:17:43 +0000 (11:17 -0800)]
netfilter: xtables: compat out of scope fix
commit
14c7dbe043d01a83a30633ab6b109ba2ac61d9f7 upstream.
As per C99 6.2.4(2) when temporary table data goes out of scope,
the behaviour is undefined:
if (compat) {
struct foo tmp;
...
private = &tmp;
}
[dereference private]
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexey Dobriyan [Mon, 8 Feb 2010 19:17:22 +0000 (11:17 -0800)]
netfilter: nf_conntrack: restrict runtime expect hashsize modifications
commit
13ccdfc2af03e09e60791f7d4bc4ccf53398af7c upstream.
Expectation hashtable size was simply glued to a variable with no code
to rehash expectations, so it was a bug to allow writing to it.
Make "expect_hashsize" readonly.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Mon, 8 Feb 2010 19:16:56 +0000 (11:16 -0800)]
netfilter: nf_conntrack: per netns nf_conntrack_cachep
commit
5b3501faa8741d50617ce4191c20061c6ef36cb3 upstream.
nf_conntrack_cachep is currently shared by all netns instances, but
because of SLAB_DESTROY_BY_RCU special semantics, this is wrong.
If we use a shared slab cache, one object can instantly flight between
one hash table (netns ONE) to another one (netns TWO), and concurrent
reader (doing a lookup in netns ONE, 'finding' an object of netns TWO)
can be fooled without notice, because no RCU grace period has to be
observed between object freeing and its reuse.
We dont have this problem with UDP/TCP slab caches because TCP/UDP
hashtables are global to the machine (and each object has a pointer to
its netns).
If we use per netns conntrack hash tables, we also *must* use per netns
conntrack slab caches, to guarantee an object can not escape from one
namespace to another one.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
[Patrick: added unique slab name allocation]
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Mon, 8 Feb 2010 19:16:26 +0000 (11:16 -0800)]
netfilter: nf_conntrack: fix memory corruption with multiple namespaces
commit
9edd7ca0a3e3999c260642c92fa008892d82ca6e upstream.
As discovered by Jon Masters <jonathan@jonmasters.org>, the "untracked"
conntrack, which is located in the data section, might be accidentally
freed when a new namespace is instantiated while the untracked conntrack
is attached to a skb because the reference count it re-initialized.
The best fix would be to use a seperate untracked conntrack per
namespace since it includes a namespace pointer. Unfortunately this is
not possible without larger changes since the namespace is not easily
available everywhere we need it. For now move the untracked conntrack
initialization to the init_net setup function to make sure the reference
count is not re-initialized and handle cleanup in the init_net cleanup
function to make sure namespaces can exit properly while the untracked
conntrack is in use in other namespaces.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Borislav Petkov [Thu, 11 Feb 2010 16:15:57 +0000 (17:15 +0100)]
amd64_edac: Do not falsely trigger kerneloops
commit
cab4d27764d5a8654212b3e96eb0ae793aec5b94 upstream.
An unfortunate "WARNING" in the message amd64_edac dumps when the system
doesn't support DRAM ECC or ECC checking is not enabled in the BIOS
used to trigger kerneloops which qualified the message as an OOPS thus
misleading the users. See, e.g.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/422536
http://bugzilla.kernel.org/show_bug.cgi?id=15238
Downgrade the message level to KERN_NOTICE and fix the formulation.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Acked-by: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcel Selhorst [Wed, 10 Feb 2010 21:56:32 +0000 (13:56 -0800)]
tpm_infineon: fix suspend/resume handler for pnp_driver
commit
93716b9470fbfd9efdc7d0f2445cb34635de3f6d upstream.
When suspending, tpm_infineon calls the generic suspend function of the
TPM framework. However, the TPM framework does not return and the system
hangs upon suspend. When sending the necessary command "TPM_SaveState"
directly within the driver, suspending and resuming works fine.
Signed-off-by: Marcel Selhorst <m.selhorst@sirrix.com>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Debora Velarde <debora@linux.vnet.ibm.com>
Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.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>
Marcelo Tosatti [Fri, 29 Jan 2010 19:28:41 +0000 (17:28 -0200)]
KVM: PIT: control word is write-only
commit
ee73f656a604d5aa9df86a97102e4e462dd79924 upstream.
PIT control word (address 0x43) is write-only, reads are undefined.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jason Wang [Wed, 27 Jan 2010 11:13:49 +0000 (19:13 +0800)]
kvmclock: count total_sleep_time when updating guest clock
commit
923de3cf5bf12049628019010e36623fca5ef6d1 upstream.
Current kvm wallclock does not consider the total_sleep_time which could cause
wrong wallclock in guest after host suspend/resume. This patch solve
this issue by counting total_sleep_time to get the correct host boot time.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jason Wang [Wed, 27 Jan 2010 11:13:40 +0000 (19:13 +0800)]
Export the symbol of getboottime and mmonotonic_to_bootbased
commit
c93d89f3dbf0202bf19c07960ca8602b48c2f9a0 upstream.
Export getboottime and monotonic_to_bootbased in order to let them
could be used by following patch.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Francesco Lavra [Sun, 7 Feb 2010 12:49:58 +0000 (09:49 -0300)]
V4L/DVB: dvb-core: fix initialization of feeds list in demux filter
commit
691c9ae099b9bcb5c27125af00a4a90120977458 upstream.
A DVB demultiplexer device can be used to set up either a PES filter or
a section filter. In the former case, the ts field of the feed union of
struct dmxdev_filter is used, in the latter case the sec field of the
same union is used.
The ts field is a struct list_head, and is currently initialized in the
open() method of the demux device. When for a given demuxer a section
filter is set up, the sec field is played with, thus if a PES filter
needs to be set up after that the ts field will be corrupted, causing a
kernel oops.
This fix moves the list head initialization to
dvb_dmxdev_pes_filter_set(), so that the ts field is properly
initialized every time a PES filter is set up.
Signed-off-by: Francesco Lavra <francescolavra@interfree.it>
Reviewed-by: Andy Walls <awalls@radix.net>
Tested-by: hermann pitton <hermann-pitton@arcor.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Tue, 9 Feb 2010 01:31:47 +0000 (12:31 +1100)]
md: fix 'degraded' calculation when starting a reshape.
commit
9eb07c259207d048e3ee8be2a77b2a4680b1edd4 upstream.
This code was written long ago when it was not possible to
reshape a degraded array. Now it is so the current level of
degraded-ness needs to be taken in to account. Also newly addded
devices should only reduce degradedness if they are deemed to be
in-sync.
In particular, if you convert a RAID5 to a RAID6, and increase the
number of devices at the same time, then the 5->6 conversion will
make the array degraded so the current code will produce a wrong
value for 'degraded' - "-1" to be precise.
If the reshape runs to completion end_reshape will calculate a correct
new value for 'degraded', but if a device fails during the reshape an
incorrect decision might be made based on the incorrect value of
"degraded".
This patch is suitable for 2.6.32-stable and if they are still open,
2.6.31-stable and 2.6.30-stable as well.
Reported-by: Michael Evans <mjevans1983@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Mon, 8 Feb 2010 14:32:40 +0000 (09:32 -0500)]
NFS: Fix the mapping of the NFSERR_SERVERFAULT error
commit
fdcb45777a3d1689c5541e1f85ee3ebbd197d2c1 upstream.
It was recently pointed out that the NFSERR_SERVERFAULT error, which is
designed to inform the user of a serious internal error on the server, was
being mapped to an error value that is internal to the kernel.
This patch maps it to the error EREMOTEIO, which is exported to userland
through errno.h.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Mon, 8 Feb 2010 14:32:27 +0000 (09:32 -0500)]
NFS: Fix a bug in nfs_fscache_release_page()
commit
2c1740098c708b465e87637b237feb2fd98f129a upstream.
Not having an fscache cookie is perfectly valid if the user didn't mount
with the fscache option.
This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=15234
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Wed, 3 Feb 2010 13:27:35 +0000 (08:27 -0500)]
NFS: Fix a umount race
commit
387c149b54b4321cbc790dadbd4f8eedb5a90468 upstream.
Ensure that we unregister the bdi before kill_anon_super() calls
ida_remove() on our device name.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Wed, 3 Feb 2010 13:27:22 +0000 (08:27 -0500)]
NFS: Fix an Oops when truncating a file
commit
9f557cd8073104b39528794d44e129331ded649f upstream.
The VM/VFS does not allow mapping->a_ops->invalidatepage() to fail.
Unfortunately, nfs_wb_page_cancel() may fail if a fatal signal occurs.
Since the NFS code assumes that the page stays mapped for as long as the
writeback is active, we can end up Oopsing (among other things).
The only safe fix here is to convert nfs_wait_on_request(), so as to make
it uninterruptible (as is already the case with wait_on_page_writeback()).
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Tue, 26 Jan 2010 20:42:21 +0000 (15:42 -0500)]
NFSv4: Ensure that the NFSv4 locking can recover from stateid errors
commit
2bee72a6aa1e6d0a4f5da56217f0d0bbbdd0d9a3 upstream.
In most cases, we just want to mark the lock_stateid sequence id as being
uninitialised.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Tue, 26 Jan 2010 20:42:30 +0000 (15:42 -0500)]
NFSv4: Don't allow posix locking against servers that don't support it
commit
8e469ebd6dc32cbaf620e134d79f740bf0ebab79 upstream.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Tue, 26 Jan 2010 20:41:53 +0000 (15:41 -0500)]
NFS: Try to commit unstable writes in nfs_release_page()
commit
82be934a59ff891cac598727e5a862ba2b9d1fac upstream.
If someone calls nfs_release_page(), we presumably already know that the
page is clean, however it may be holding an unstable write.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Tue, 26 Jan 2010 20:41:34 +0000 (15:41 -0500)]
NFS: Fix a reference leak in nfs_wb_cancel_page()
commit
c9edda7140ec6a22accf7f2f86da362dfbfd41fc upstream.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Layton [Fri, 5 Feb 2010 18:14:00 +0000 (13:14 -0500)]
cifs: fix length calculation for converted unicode readdir names
commit
f12f98dba6ea1517cd7fbb912208893b9c014c15 upstream.
cifs_from_ucs2 returns the length of the converted name, including the
length of the NULL terminator. We don't want to include the NULL
terminator in the dentry name length however since that'll throw off the
hash calculation for the dentry cache.
I believe that this is the root cause of several problems that have
cropped up recently that seem to be papered over with the "noserverino"
mount option. More confirmation of that would be good, but this is
clearly a bug and it fixes at least one reproducible problem that
was reported.
This patch fixes at least this reproducer in this kernel.org bug:
http://bugzilla.kernel.org/show_bug.cgi?id=15088#c12
Reported-by: Bjorn Tore Sund <bjorn.sund@it.uib.no>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michael Neuling [Wed, 10 Feb 2010 21:56:42 +0000 (13:56 -0800)]
fs/exec.c: restrict initial stack space expansion to rlimit
commit
803bf5ec259941936262d10ecc84511b76a20921 upstream.
When reserving stack space for a new process, make sure we're not
attempting to expand the stack by more than rlimit allows.
This fixes a bug caused by
b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm:
variable length argument support") and unmasked by
fc63cf237078c86214abcb2ee9926d8ad289da9b ("exec: setup_arg_pages() fails
to return errors").
This bug means that when limiting the stack to less the 20*PAGE_SIZE (eg.
80K on 4K pages or 'ulimit -s 79') all processes will be killed before
they start. This is particularly bad with 64K pages, where a ulimit below
1280K will kill every process.
To test, do:
'ulimit -s 15; ls'
before and after the patch is applied. Before it's applied, 'ls' should
be killed. After the patch is applied, 'ls' should no longer be killed.
A stack limit of 15KB since it's small enough to trigger 20*PAGE_SIZE.
Also 15KB not a multiple of PAGE_SIZE, which is a trickier case to handle
correctly with this code.
4K pages should be fine to test with.
[kosaki.motohiro@jp.fujitsu.com: cleanup]
[akpm@linux-foundation.org: cleanup cleanup]
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Americo Wang <xiyou.wangcong@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Serge Hallyn <serue@us.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Slaby [Thu, 19 Nov 2009 16:16:37 +0000 (17:16 +0100)]
resource: add helpers for fetching rlimits
commit
3e10e716abf3c71bdb5d86b8f507f9e72236c9cd upstream.
We want to be sure that compiler fetches the limit variable only
once, so add helpers for fetching current and maximal resource
limits which do that.
Add them to sched.h (instead of resource.h) due to circular dependency
sched.h->resource.h->task_struct
Alternative would be to create a separate res_access.h or similar.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: James Morris <jmorris@namei.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Williams [Wed, 13 Jan 2010 20:33:12 +0000 (13:33 -0700)]
ioat: fix infinite timeout checking in ioat2_quiesce
commit
7e55a70c5b9a57c12f49c44b0847c9343d4f54e4 upstream.
Fix typo in ioat2_quiesce. check 'tmo' is zero, not 'end'. Also applies
to 2.6.32.3
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stephen M. Cameron [Fri, 5 Feb 2010 12:14:04 +0000 (13:14 +0100)]
cciss: Make cciss_seq_show handle holes in the h->drv[] array
commit
531c2dc70d339c5dfa8c3eb628c3459dc6f3a075 upstream.
It is possible (and expected) for there to be holes in the h->drv[]
array, that is, some elements may be NULL pointers. cciss_seq_show
needs to be made aware of this possibility to avoid an Oops.
To reproduce the Oops which this fixes:
1) Create two "arrays" in the Array Configuratino Utility and
several logical drives on each array.
2) cat /proc/driver/cciss/cciss* in an infinite loop
3) delete some of the logical drives in the first "array."
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jun'ichi Nomura [Fri, 29 Jan 2010 00:56:22 +0000 (09:56 +0900)]
freeze_bdev: don't deactivate successfully frozen MS_RDONLY sb
commit
4b06e5b9ad8abb20105b2b25e42c509ebe9b2d76 upstream.
Thanks Thomas and Christoph for testing and review.
I removed 'smp_wmb()' before up_write from the previous patch,
since up_write() should have necessary ordering constraints.
(I.e. the change of s_frozen is visible to others after up_write)
I'm quite sure the change is harmless but if you are uncomfortable
with Tested-by/Reviewed-by on the modified patch, please remove them.
If MS_RDONLY, freeze_bdev should just up_write(s_umount) instead of
deactivate_locked_super().
Also, keep sb->s_frozen consistent so that remount can check the frozen state.
Otherwise a crash reported here can happen:
http://lkml.org/lkml/2010/1/16/37
http://lkml.org/lkml/2010/1/28/53
This patch should be applied for 2.6.32 stable series, too.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: Thomas Backlund <tmb@mandriva.org>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Renninger [Mon, 14 Dec 2009 10:44:15 +0000 (11:44 +0100)]
CPUFREQ: Fix use after free of struct powernow_k8_data
commit
557a701c16553b0b691dbb64ef30361115a80f64 upstream.
Easy fix for a regression introduced in 2.6.31.
On managed CPUs the cpufreq.c core will call driver->exit(cpu) on the
managed cpus and powernow_k8 will free the core's data.
Later driver->get(cpu) function might get called trying to read out the
current freq of a managed cpu and the NULL pointer check does not work on
the freed object -> better set it to NULL.
->get() is unsigned and must return 0 as invalid frequency.
Reference:
http://bugzilla.kernel.org/show_bug.cgi?id=14391
Signed-off-by: Thomas Renninger <trenn@suse.de>
Tested-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jody Bruchon [Sat, 6 Feb 2010 15:46:26 +0000 (10:46 -0500)]
ALSA: hda-intel: Avoid divide by zero crash
commit
fed08d036f2aabd8d0c684439de37f8ebec2bbc2 upstream.
On my AMD780V chipset, hda_intel.c can crash the kernel with a divide by
zero
for as-yet unknown reasons. A simple check for zero prevents it, though
the problem that causes it remains. Since the workaround is harmless and
won't affect anyone except victims of this bug, it should be safe;
moreover,
because this crash can be triggered by a user-mode application, there are
denial of service implications on the systems affected by the bug without
the patch.
Signed-off-by: Jody Bruchon <jody@nctritech.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Thu, 11 Feb 2010 19:20:48 +0000 (19:20 +0000)]
regulator: Fix display of null constraints for regulators
commit
973e9a2795b3b41d8408a0bb6f87b783c5efc88a upstream.
If the regulator constraints are empty and there is no voltage
reported then nothing will be added to the text displayed for the
constraints, leading to random stack data being printed. This is
unlikely to happen for practical regulators since most will at
least report a voltage but should still be fixed.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Vetter [Sun, 7 Feb 2010 15:20:18 +0000 (16:20 +0100)]
drm/i915: Update write_domains on active list after flush.
commit
99fcb766a3a50466fe31d743260a3400c1aee855 upstream.
Before changing the status of a buffer with a pending write we will await
upon a new flush for that buffer. So we can take advantage of any flushes
posted whilst the buffer is active and pending processing by the GPU, by
clearing its write_domain and updating its last_rendering_seqno -- thus
saving a potential flush in deep queues and improves flushing behaviour
upon eviction for both GTT space and fences.
In order to reduce the time spent searching the active list for matching
write_domains, we move those to a separate list whose elements are
the buffers belong to the active/flushing list with pending writes.
Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported
by me.
In addition to better performance, this also fixes a real bug. Before
this changes, i915_gem_evict_everything didn't work as advertised. When
the gpu was actually busy and processing request, the flush and subsequent
wait would not move active and dirty buffers to the inactive list, but
just to the flushing list. Which triggered the BUG_ON at the end of this
function. With the more tight dirty buffer tracking, all currently busy and
dirty buffers get moved to the inactive list by one i915_gem_flush operation.
I've left the BUG_ON I've used to prove this in there.
References:
Bug 25911 - 2.10.0 causes kernel oops and system hangs
http://bugs.freedesktop.org/show_bug.cgi?id=25911
Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops
within seconds after login
http://bugs.freedesktop.org/show_bug.cgi?id=26101
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Adam Lantos <hege@playma.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Wilson [Tue, 9 Feb 2010 14:14:36 +0000 (14:14 +0000)]
drm/i915: Increase fb alignment to 64k
commit
fd2e8ea597222b8f38ae8948776a61ea7958232e upstream.
An untiled framebuffer must be aligned to 64k. This is normally handled
by intel_pin_and_fence_fb_obj(), but the intelfb_create() likes to be
different and do the pinning itself. However, it aligns the buffer
object incorrectly for pre-i965 chipsets causing a PGTBL_ERR when it is
installed onto the output.
Fixes:
KMS error message while initializing modesetting -
render error detected: EIR: 0x10 [i915]
http://bugs.freedesktop.org/show_bug.cgi?id=22936
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>
Jesse Barnes [Sat, 6 Feb 2010 18:41:53 +0000 (10:41 -0800)]
drm/i915: handle FBC and self-refresh better
commit
ee25df2bc379728c45d81e04cf87984db1425edf upstream.
On 945, we need to avoid entering self-refresh if the compressor is
busy, or we may cause display FIFO underruns leading to ugly flicker.
Fixes fdo bug #24314, kernel bug #15043.
Tested-by: Alexander Lam <lambchop468@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Julien Cristau <jcristau@debian.org> (fd.o #25371)
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 5 Feb 2010 16:48:13 +0000 (17:48 +0100)]
i2c-tiny-usb: Fix on big-endian systems
commit
1c010ff8912cbc08d80e865aab9c32b6b00c527d upstream.
The functionality bit vector is always returned as a little-endian
32-bit number by the device, so it must be byte-swapped to the host
endianness.
On the other hand, the delay value is handled by the USB stack, so no
byte swapping is needed on our side.
This fixes bug #15105:
http://bugzilla.kernel.org/show_bug.cgi?id=15105
Reported-by: Jens Richter <jens@richter-stutensee.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Jens Richter <jens@richter-stutensee.de>
Cc: Till Harbaum <till@harbaum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paul Mundt [Thu, 4 Feb 2010 06:57:58 +0000 (06:57 +0000)]
usb: r8a66597-hcd: Flush the D-cache for the pipe-in transfer buffers.
commit
2717568e7c44fe7dc3f4f52ea823811cfeede2b5 upstream.
This implements the same D-cache flushing logic for r8a66597-hcd as
Catalin's isp1760 (http://patchwork.kernel.org/patch/76391/) change,
with the same note applying here as well:
When the HDC driver writes the data to the transfer buffers it
pollutes the D-cache (unlike DMA drivers where the device writes
the data). If the corresponding pages get mapped into user space,
there are no additional cache flushing operations performed and
this causes random user space faults on architectures with
separate I and D caches (Harvard) or those with aliasing D-cache.
This fixes up crashes during USB boot on SH7724 and others:
http://marc.info/?l=linux-sh&m=
126439837308912&w=2
Reported-by: Goda Yusuke <goda.yusuke@renesas.com>
Tested-by: Goda Yusuke <goda.yusuke@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Acked-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Fri, 11 Dec 2009 01:26:10 +0000 (09:26 +0800)]
drm/i915: Add MALATA PC-81005 to ACPI LID quirk list
commit
a3cb5195f6db58dbebd8a31b877ddce082c9b63d upstream.
The MALATA PC-81005 laptop always reports that the LID status is closed and we
can't use it reliabily for LVDS detection. So add this box into the quirk list.
https://bugs.freedesktop.org/show_bug.cgi?id=25523
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Review-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Hector <hector1987@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Thu, 21 Jan 2010 07:20:18 +0000 (15:20 +0800)]
drm/i915: Fix the incorrect DMI string for Samsung SX20S laptop
commit
f034b12dbb5749b11e9390e15e93ffa87ece8038 upstream.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reported-by: Philipp Kohlbecher <xt28@gmx.de>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhao Yakui [Wed, 6 Jan 2010 05:30:36 +0000 (13:30 +0800)]
drm/i915: Add HP nx9020/SamsungSX20S to ACPI LID quirk list
commit
40f33a92100f4d9b6e85ad642100cfe42d7ff57d upstream.
The HP comaq nx9020/Samsung SX20S laptop always report that the LID status is
closed and we can't use it reliabily for LVDS detection. So add the two boxes
into the quirk list.
http://bugzilla.kernel.org/show_bug.cgi?id=14957
http://bugzilla.kernel.org/show_bug.cgi?id=14554
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Anholt [Tue, 1 Dec 2009 19:56:30 +0000 (11:56 -0800)]
drm/i915: Fix DDC on some systems by clearing BIOS GMBUS setup.
commit
f0217c42c9ab3d772e543f635ce628b9478f70b6 upstream.
This is a sync of a fix I made in the old UMS code. If the BIOS uses
the GMBUS and doesn't clear that setup, then our bit-banging I2C can
fail, leading to monitors not being detected.
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: maximilian attems <max@stro.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David John [Wed, 27 Jan 2010 09:49:08 +0000 (15:19 +0530)]
drm/i915: Disable SR when more than one pipe is enabled
commit
33c5fd121eabbccc9103daf6cda36941eb3c349f upstream.
Self Refresh should be disabled on dual plane configs. Otherwise, as
the SR watermark is not calculated for such configs, switching to non
VGA mode causes FIFO underrun and display flicker.
This fixes Korg Bug #14897.
Signed-off-by: David John <davidjon@xenontk.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jesse Barnes [Mon, 19 Oct 2009 01:08:17 +0000 (10:08 +0900)]
drm/i915: enable self-refresh on 965
commit
1dc7546d1a73664e5d117715b214bea9cae5951c upstream.
Need to calculate the SR watermark and enable it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Zhenyu Wang [Mon, 25 Jan 2010 02:35:16 +0000 (10:35 +0800)]
drm/i915: disable hotplug detect before Ironlake CRT detect
commit
eceb784cec4dc0fcc2993d9ee4a7c0d111ada80a upstream.
This tries to fix CRT detect loop hang seen on some Ironlake form
factor, to clear up hotplug detect state before taking CRT detect
to make sure next hotplug detect cycle is consistent.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jaroslav Kysela [Tue, 2 Feb 2010 18:58:25 +0000 (19:58 +0100)]
ALSA: ctxfi - fix PTP address initialization
commit
21956b61f594f7924d98240da74bc81c28601fa9 upstream.
After hours of debugging, I finally found the reason why some source
and runtime combination does not work. The PTP (page table pages)
address must be aligned. I am not sure how much, but alignment to
PAGE_SIZE is sufficient. Also, use ALSA's page allocation routines
to ensure proper virtual -> physical address translation.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ray Copeland [Fri, 5 Feb 2010 18:58:35 +0000 (19:58 +0100)]
hwmon: (adt7462) Wrong ADT7462_VOLT_COUNT
commit
85f8d3e5faea8bd36c3e5196f8334f7db45e19b2 upstream.
The #define ADT7462_VOLT_COUNT is wrong, it should be 13 not 12. All the
for loops that use this as a limit count are of the typical form, "for
(n = 0; n < ADT7462_VOLT_COUNT; n++)", so to loop through all voltages
w/o missing the last one it is necessary for the count to be one greater
than it is. (Specifically, you will miss the +1.5V 3GPIO input with count
= 12 vs. 13.)
Signed-off-by: Ray Copeland <ray.copeland@aprius.com>
Acked-by: "Darrick J. Wong" <djwong@us.ibm.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 5 Feb 2010 18:58:36 +0000 (19:58 +0100)]
hwmon: (lm78) Request I/O ports individually for probing
commit
197027e6ef830d60e10f76efc8d12bf3b6c35db5 upstream.
Different motherboards have different PNP declarations for LM78/LM79
chips. Some declare the whole range of I/O ports (8 ports), some
declare only the useful ports (2 ports at offset 5) and some declare
fancy ranges, for example 4 ports at offset 4. To properly handle all
cases, request all ports individually for probing. After we have
determined that we really have an LM78 or LM79 chip, the useful port
range will be requested again, as a single block.
This fixes the driver on the Olivetti M3000 DT 540, at least.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Fri, 5 Feb 2010 18:58:36 +0000 (19:58 +0100)]
hwmon: (w83781d) Request I/O ports individually for probing
commit
b0bcdd3cd0adb85a7686b396ba50493871b1135c upstream.
Different motherboards have different PNP declarations for
W83781D/W83782D chips. Some declare the whole range of I/O ports (8
ports), some declare only the useful ports (2 ports at offset 5) and
some declare fancy ranges, for example 4 ports at offset 4. To
properly handle all cases, request all ports individually for probing.
After we have determined that we really have a W83781D or W83782D
chip, the useful port range will be requested again, as a single
block.
I did not see a board which needs this yet, but I know of one for lm78
driver and I'd like to keep the logic of these two drivers in sync.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Sun, 7 Feb 2010 18:11:23 +0000 (10:11 -0800)]
Fix race in tty_fasync() properly
commit
80e1e823989ec44d8e35bdfddadbddcffec90424 upstream.
This reverts commit
703625118069 ("tty: fix race in tty_fasync") and
commit
b04da8bfdfbb ("fnctl: f_modown should call write_lock_irqsave/
restore") that tried to fix up some of the fallout but was incomplete.
It turns out that we really cannot hold 'tty->ctrl_lock' over calling
__f_setown, because not only did that cause problems with interrupt
disables (which the second commit fixed), it also causes a potential
ABBA deadlock due to lock ordering.
Thanks to Tetsuo Handa for following up on the issue, and running
lockdep to show the problem. It goes roughly like this:
- f_getown gets filp->f_owner.lock for reading without interrupts
disabled, so an interrupt that happens while that lock is held can
cause a lockdep chain from f_owner.lock -> sighand->siglock.
- at the same time, the tty->ctrl_lock -> f_owner.lock chain that
commit
703625118069 introduced, together with the pre-existing
sighand->siglock -> tty->ctrl_lock chain means that we have a lock
dependency the other way too.
So instead of extending tty->ctrl_lock over the whole __f_setown() call,
we now just take a reference to the 'pid' structure while holding the
lock, and then release it after having done the __f_setown. That still
guarantees that 'struct pid' won't go away from under us, which is all
we really ever needed.
Reported-and-tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Américo Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Wed, 3 Feb 2010 08:33:05 +0000 (09:33 +0100)]
futex: Handle futex value corruption gracefully
commit
59647b6ac3050dd964bc556fe6ef22f4db5b935c upstream.
The WARN_ON in lookup_pi_state which complains about a mismatch
between pi_state->owner->pid and the pid which we retrieved from the
user space futex is completely bogus.
The code just emits the warning and then continues despite the fact
that it detected an inconsistent state of the futex. A conveniant way
for user space to spam the syslog.
Replace the WARN_ON by a consistency check. If the values do not match
return -EINVAL and let user space deal with the mess it created.
This also fixes the missing task_pid_vnr() when we compare the
pi_state->owner pid with the futex value.
Reported-by: Jermome Marchand <jmarchan@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Darren Hart <dvhltc@us.ibm.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Gleixner [Tue, 2 Feb 2010 10:40:27 +0000 (11:40 +0100)]
futex: Handle user space corruption gracefully
commit
51246bfd189064079c54421507236fd2723b18f3 upstream.
If the owner of a PI futex dies we fix up the pi_state and set
pi_state->owner to NULL. When a malicious or just sloppy programmed
user space application sets the futex value to 0 e.g. by calling
pthread_mutex_init(), then the futex can be acquired again. A new
waiter manages to enqueue itself on the pi_state w/o damage, but on
unlock the kernel dereferences pi_state->owner and oopses.
Prevent this by checking pi_state->owner in the unlock path. If
pi_state->owner is not current we know that user space manipulated the
futex value. Ignore the mess and return -EINVAL.
This catches the above case and also the case where a task hijacks the
futex by setting the tid value and then tries to unlock it.
Reported-by: Jermome Marchand <jmarchan@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Darren Hart <dvhltc@us.ibm.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mikael Pettersson [Sat, 23 Jan 2010 21:36:29 +0000 (22:36 +0100)]
futex_lock_pi() key refcnt fix
commit
5ecb01cfdf96c5f465192bdb2a4fd4a61a24c6cc upstream.
This fixes a futex key reference count bug in futex_lock_pi(),
where a key's reference count is incremented twice but decremented
only once, causing the backing object to not be released.
If the futex is created in a temporary file in an ext3 file system,
this bug causes the file's inode to become an "undead" orphan,
which causes an oops from a BUG_ON() in ext3_put_super() when the
file system is unmounted. glibc's test suite is known to trigger this,
see <http://bugzilla.kernel.org/show_bug.cgi?id=14256>.
The bug is a regression from 2.6.28-git3, namely Peter Zijlstra's
38d47c1b7075bd7ec3881141bb3629da58f88dab "[PATCH] futex: rely on
get_user_pages() for shared futexes". That commit made get_futex_key()
also increment the reference count of the futex key, and updated its
callers to decrement the key's reference count before returning.
Unfortunately the normal exit path in futex_lock_pi() wasn't corrected:
the reference count is incremented by get_futex_key() and queue_lock(),
but the normal exit path only decrements once, via unqueue_me_pi().
The fix is to put_futex_key() after unqueue_me_pi(), since 2.6.31
this is easily done by 'goto out_put_key' rather than 'goto out'.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Darren Hart <dvhltc@us.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Sat, 6 Feb 2010 00:16:50 +0000 (16:16 -0800)]
Fix potential crash with sys_move_pages
commit
6f5a55f1a6c5abee15a0e878e5c74d9f1569b8b0 upstream.
We incorrectly depended on the 'node_state/node_isset()' functions
testing the node range, rather than checking it explicitly. That's not
reliable, even if it might often happen to work. So do the proper
explicit test.
Reported-by: Marcus Meissner <meissner@suse.de>
Acked-and-tested-by: Brice Goglin <Brice.Goglin@inria.fr>
Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Tue, 9 Feb 2010 12:57:19 +0000 (04:57 -0800)]
Linux 2.6.32.8
jamal [Thu, 4 Feb 2010 19:50:56 +0000 (14:50 -0500)]
NET: fix oops at bootime in sysctl code
This fixes the boot time oops on the 2.6.32-stable tree. It is needed
only in this tree due to the divergance from upstream.
From: jamal <hadi@cyberus.ca>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andreas Schwab [Sat, 30 Jan 2010 10:20:59 +0000 (10:20 +0000)]
powerpc: TIF_ABI_PENDING bit removal
commit
94f28da8409c6059135e89ac64a0839993124155 upstream.
Here are the powerpc bits to remove TIF_ABI_PENDING now that
set_personality() is called at the appropriate place in exec.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felix Fietkau [Tue, 19 Jan 2010 19:51:32 +0000 (20:51 +0100)]
ath9k: fix beacon slot/buffer leak
commit
74401773f80b6d42f7a4c6994ca0cca883b03745 upstream.
When cleaning up beacon buffers and slots, ath9k currently checks if
sc->ah->opmode is set to a beacon related mode before cleaning up
buffers.
An unfortunate ordering of interface up/down commands can lead to
sc->ah->opmode being set to monitor mode, while there are AP interfaces
present on the same wiphy.
Always cleaning up beacon buffers if present fixes this issue.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felix Fietkau [Sat, 23 Jan 2010 19:04:18 +0000 (20:04 +0100)]
ath9k: fix eeprom INI values override for 2GHz-only cards
commit
aa8bc9ef18a2c5b2b97e1f36ee9604cf15743f96 upstream.
Among other changes, this commit:
commit
06d0f0663e11cab4ec5f2c143a118d71a12fbbe9
Author: Sujith <Sujith.Manoharan@atheros.com>
Date: Thu Feb 12 10:06:45 2009 +0530
ath9k: Enable Fractional N mode
changed the hw attach code to fix up initialization values only for
dual band devices, however the commit message did not give a reason as
to why this would be useful or necessary.
According to tests by Jorge Boncompte, this breaks at least some
2GHz-only cards, so the code should be changed back to the
unconditional INI fixup.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Jorge Boncompte <jorge@dti2.net>
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thadeu Lima de Souza Cascardo [Tue, 2 Feb 2010 21:44:17 +0000 (13:44 -0800)]
pktcdvd: removing device does not remove its sysfs dir
commit
ca0bf64d99f6e3f6e2fe2585e52a0ac57354beac upstream.
This is the counterpart to
cba767175becadc5c4016cceb7bfdd2c7fe722f4
("pktcdvd: remove broken dev_t export of class devices"). Device is not
registered using dev_t, so it should not be destroyed using device_destroy
which looks up the device by dev_t. This will fail and adding the device
again will fail with the "duplicate name" error. This is fixed using
device_unregister instead of device_destroy.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Peter Osterlund <petero2@telia.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jens Axboe <jens.axboe@oracle.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>
Richard Röjfors [Tue, 2 Feb 2010 21:44:12 +0000 (13:44 -0800)]
uartlite: fix crash when using as console
commit
03eac7bb882a75e6ee5705288f7ec36ad2e7d0d5 upstream.
Move the ulite_console_setup to the .devinit section since it might be
called on probe, which is in devinit. Fixes the crash below where the
uartlite hw is probed after the .init section is freed from the kernel.
uartlite: ttyUL0 at MMIO 0xc8000100 (irq = 30) is a uartlite
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<
c176720e>] ulite_console_setup+0x6f/0xa8
*pdpt =
0000000036fb0001 *pde =
0000000000000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1f.1/host0/uevent
Modules linked in: puffin(+) serio_raw
Pid: 151, comm: modprobe Not tainted (2.6.31.5-1.0.b1-b1 #1) POULSBO
EIP: 0060:[<
c176720e>] EFLAGS:
00010246 CPU: 0
EIP is at ulite_console_setup+0x6f/0xa8
EAX:
c16ec824 EBX:
c16ec824 ECX:
c176719f EDX:
00000000
ESI:
00000000 EDI:
c17b42c4 EBP:
f6fd1cf0 ESP:
f6fd1cd8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 151, ti=
f6fd0000 task=
f6fa1020 task.ti=
f6fd0000)
Stack:
c1031f51 00000000 00000000 00000246 c182237c f7742000 f6fd1d5c c11fd316
<0>
c16ec85c f77420d4 0000001e 00000000 00000000 c1633e78 4f494d4d 63783020
<0>
30303038 00303031 f6fd1d3c c10e0786 f6fd1d48 00000000 f6fd1d48 00000000
Call Trace:
[<
c1031f51>] ? register_console+0xf6/0x1fc
[<
c11fd316>] ? uart_add_one_port+0x237/0x2bb
[<
c10e0786>] ? sysfs_add_one+0x13/0xd3
[<
c10e142f>] ? sysfs_do_create_link+0xba/0xfc
[<
c146f200>] ? ulite_probe+0x198/0x1eb
[<
c12064ee>] ? platform_drv_probe+0xc/0xe
[<
c120597b>] ? driver_probe_device+0x79/0x105
[<
c1205a8e>] ? __device_attach+0x28/0x30
[<
c120511f>] ? bus_for_each_drv+0x3d/0x67
[<
c1205af9>] ? device_attach+0x44/0x58
[<
c1205a66>] ? __device_attach+0x0/0x30
[<
c1204fb8>] ? bus_probe_device+0x1f/0x34
[<
c1203e68>] ? device_add+0x385/0x4c0
[<
c148491f>] ? _write_unlock+0x8/0x1f
[<
c1206aac>] ? platform_device_add+0xd9/0x11c
[<
c120c685>] ? mfd_add_devices+0x165/0x1bc
[<
f831b378>] ? puffin_probe+0x2d0/0x390 [puffin]
[<
c11a08ef>] ? pci_match_device+0xa0/0xa7
[<
c11a07bc>] ? local_pci_probe+0xe/0x10
[<
c11a11db>] ? pci_device_probe+0x43/0x66
[<
c120597b>] ? driver_probe_device+0x79/0x105
[<
c1205a4a>] ? __driver_attach+0x43/0x5f
[<
c120535d>] ? bus_for_each_dev+0x3d/0x67
[<
c1205852>] ? driver_attach+0x14/0x16
[<
c1205a07>] ? __driver_attach+0x0/0x5f
[<
c1204dea>] ? bus_add_driver+0xf9/0x220
[<
c1205c8f>] ? driver_register+0x8b/0xeb
[<
c11a1518>] ? __pci_register_driver+0x43/0x9f
[<
c10477ef>] ? __blocking_notifier_call_chain+0x40/0x4c
[<
f831f000>] ? puffin_init+0x0/0x48 [puffin]
[<
f831f017>] ? puffin_init+0x17/0x48 [puffin]
[<
c1001139>] ? do_one_initcall+0x4c/0x131
[<
c105607b>] ? sys_init_module+0xa7/0x1b7
[<
c1002a61>] ? syscall_call+0x7/0xb
Code: 6e 74 00 00 00 92 33 00 00 18 00 0e 01 73 79 6e 63 65 2d 72 65 67 69 73 74 72 79 0c 00 49 32
00 00 14 00 09 01 61 6c 73 61 2d 69 <6e> 66 6f 00 00 00 42 37 00 00 10 00 07 01 6b 69 6c 6c 61 6c 6c
EIP: [<
c176720e>] ulite_console_setup+0x6f/0xa8 SS:ESP 0068:
f6fd1cd8
CR2:
0000000000000000
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Julia Lawall [Tue, 2 Feb 2010 22:31:36 +0000 (09:31 +1100)]
kernel/cred.c: use kmem_cache_free
commit
b8a1d37c5f981cdd2e83c9fd98198832324cd57a upstream.
Free memory allocated using kmem_cache_zalloc using kmem_cache_free rather
than kfree.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,E,c;
@@
x = \(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...)
... when != x = E
when != &x
?-kfree(x)
+kmem_cache_free(c,x)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: Steve Dickson <steved@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Tue, 26 Jan 2010 18:27:09 +0000 (18:27 +0000)]
starfire: clean up properly if firmware loading fails
commit
c928febf4bc703ea542340e5a208e0445d998839 upstream.
netdev_open() will return without cleaning up net device or hardware state
if firmware loading fails. This results in a BUG() on a second attempt to
bring the interface up, reported in
<http://bugzilla.kernel.org/show_bug.cgi?id=15091>, and probably has even
worse effects if the driver is removed afterwards.
Call netdev_close() to clean up on failure.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15091
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Reported-by: Michael Moffatt <michael@moffatt.org.nz>
Tested-by: Michael Moffatt <michael@moffatt.org.nz>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alberto Panizzo [Tue, 2 Feb 2010 21:43:59 +0000 (13:43 -0800)]
mx3fb: some debug and initialisation fixes
commit
b3cb53721890879d7bde31f5f9eefd4edf41ab64 upstream.
Fix the kernel oops when dev_dbg is called with mx3_fbi->txd == NULL
Fix the late initialisation of mx3fb->backlight_level. If not, in the
chain of function started by init_fb_chan(), in __blank() call
sdc_set_brightness(mx3fb, mx3fb->backlight_level) that will shut down the
CONTRAST PWM output.
Signed-off-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
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>
Uwe Kleine-König [Tue, 2 Feb 2010 21:44:10 +0000 (13:44 -0800)]
imxfb: correct location of callbacks in suspend and resume
commit
1ec562035ba64e724652cb12b8a770b3906e9bf5 upstream.
The probe function passes a pointer to a struct fb_info to
platform_set_drvdata(), so don't interpret the return value of
platform_get_drvdata() as a pointer to struct imxfb_info.
The original imxfb_info *fbi backlight_power was NULL but in imxfb_suspend
it was 4 resulting in an oops as imxfb_suspend calls
imxfb_disable_controller(fbi) which in turn has
if (fbi->backlight_power)
fbi->backlight_power(0);
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <kernel@pengutronix.de>
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>
Zhu Yi [Tue, 26 Jan 2010 07:58:57 +0000 (15:58 +0800)]
mac80211: fix NULL pointer dereference when ftrace is enabled
commit
3092ad054406f069991ca561adc74f2d9fbb6867 upstream.
I got below kernel oops when I try to bring down the network interface if
ftrace is enabled. The root cause is drv_ampdu_action() is passed with a
NULL ssn pointer in the BA session tear down case. We need to check and
avoid dereferencing it in trace entry assignment.
BUG: unable to handle kernel NULL pointer dereference
Modules linked in: at (null)
IP: [<
f98fe02a>] ftrace_raw_event_drv_ampdu_action+0x10a/0x160 [mac80211]
*pde =
00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[...]
Call Trace:
[<
f98fdf20>] ? ftrace_raw_event_drv_ampdu_action+0x0/0x160 [mac80211]
[<
f98dac4c>] ? __ieee80211_stop_rx_ba_session+0xfc/0x220 [mac80211]
[<
f98d97fb>] ? ieee80211_sta_tear_down_BA_sessions+0x3b/0x50 [mac80211]
[<
f98dc6f6>] ? ieee80211_set_disassoc+0xe6/0x230 [mac80211]
[<
f98dc6ac>] ? ieee80211_set_disassoc+0x9c/0x230 [mac80211]
[<
f98dcbb8>] ? ieee80211_mgd_deauth+0x158/0x170 [mac80211]
[<
f98e4bdb>] ? ieee80211_deauth+0x1b/0x20 [mac80211]
[<
f8987f49>] ? __cfg80211_mlme_deauth+0xe9/0x120 [cfg80211]
[<
f898b870>] ? __cfg80211_disconnect+0x170/0x1d0 [cfg80211]
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
anfei zhou [Tue, 2 Feb 2010 21:44:02 +0000 (13:44 -0800)]
mm: flush dcache before writing into page to avoid alias
commit
931e80e4b3263db75c8e34f078d22f11bbabd3a3 upstream.
The cache alias problem will happen if the changes of user shared mapping
is not flushed before copying, then user and kernel mapping may be mapped
into two different cache line, it is impossible to guarantee the coherence
after iov_iter_copy_from_user_atomic. So the right steps should be:
flush_dcache_page(page);
kmap_atomic(page);
write to page;
kunmap_atomic(page);
flush_dcache_page(page);
More precisely, we might create two new APIs flush_dcache_user_page and
flush_dcache_kern_page to replace the two flush_dcache_page accordingly.
Here is a snippet tested on omap2430 with VIPT cache, and I think it is
not ARM-specific:
int val = 0x11111111;
fd = open("abc", O_RDWR);
addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
*(addr+0) = 0x44444444;
tmp = *(addr+0);
*(addr+1) = 0x77777777;
write(fd, &val, sizeof(int));
close(fd);
The results are not always 0x11111111 0x77777777 at the beginning as expected. Sometimes we see 0x44444444 0x77777777.
Signed-off-by: Anfei <anfei.zhou@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: <linux-arch@vger.kernel.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>
David S. Miller [Fri, 29 Jan 2010 05:36:21 +0000 (21:36 -0800)]
be2net: Fix memset() arg ordering.
commit
d291b9af1a1a12f59a464494900c6e0db26e2ec3 upstream.
Noticed by Ben Hutchings.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ajit Khaparde [Wed, 27 Jan 2010 21:56:44 +0000 (21:56 +0000)]
be2net: Bug fix to support newer generation of BE ASIC
commit
7b139c83c590d4965259aad8889cbb08104b2891 upstream.
Bug fix in be2net for newer generation of BladeEngine ASIC.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Evgeniy Polyakov [Tue, 2 Feb 2010 23:58:48 +0000 (15:58 -0800)]
connector: Delete buggy notification code.
commit
f98bfbd78c37c5946cc53089da32a5f741efdeb7 upstream.
On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote:
> > There are at least two ways to fix it: using a big cannon and a small
> > one. The former way is to disable notification registration, since it is
> > not used by anyone at all. Second way is to check whether calling
> > process is root and its destination group is -1 (kind of priveledged
> > one) before command is dispatched to workqueue.
>
> Well if no one is using it, removing it makes the most sense, right?
>
> No objection from me, care to make up a patch either way for this?
Getting it is not used, let's drop support for notifications about
(un)registered events from connector.
Another option was to check credentials on receiving, but we can always
restore it without bugs if needed, but genetlink has a wider code base
and none complained, that userspace can not get notification when some
other clients were (un)registered.
Kudos for Sebastian Krahmer <krahmer@suse.de>, who found a bug in the
code.
Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Magnus Damm [Wed, 27 Jan 2010 07:41:19 +0000 (07:41 +0000)]
usb: r8a66597-hdc disable interrupts fix
commit
e5ff15bec96ba18698dae5de0bbf7e6a0653ca65 upstream.
This patch improves disable_controller() in the r8a66597-hdc
driver to disable all interrupts and clear status flags. It
also makes sure that disable_controller() is called during
probe(). This fixes the relatively rare case of unexpected
pending interrupts after kexec reboot.
Signed-off-by: Magnus Damm <damm@opensource.se>
Acked-by: Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chuck Ebbert [Sat, 30 Jan 2010 19:28:19 +0000 (20:28 +0100)]
block: fix bugs in bio-integrity mempool usage
commit
9e9432c267e4047db98b9d4fba95099c6effcef9 upstream.
Fix two bugs in the bio integrity code:
use_bip_pool() always returns 0 because it checks against the wrong limit,
causing the mempool to be used only when regular allocation fails.
When the mempool is used as a fallback we don't free the data properly.
Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Herbert Xu [Mon, 1 Feb 2010 10:48:28 +0000 (21:48 +1100)]
random: Remove unused inode variable
commit
cd1510cb5f892907fe1a662f90b41fb3a42954e0 upstream.
The previous changeset left behind an unused inode variable.
This patch removes it.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Matt Mackall [Fri, 29 Jan 2010 08:50:36 +0000 (21:50 +1300)]
random: drop weird m_time/a_time manipulation
commit
a996996dd75a9086b12d1cb4010f26e1748993f0 upstream.
No other driver does anything remotely like this that I know of except
for the tty drivers, and I can't see any reason for random/urandom to do
it. In fact, it's a (trivial, harmless) timing information leak. And
obviously, it generates power- and flash-cycle wasting I/O, especially
if combined with something like hwrngd. Also, it breaks ubifs's
expectations.
Signed-off-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Linus Torvalds [Tue, 2 Feb 2010 20:37:44 +0000 (12:37 -0800)]
Fix 'flush_old_exec()/setup_new_exec()' split
commit
7ab02af428c2d312c0cf8fb0b01cc1eb21131a3d upstream.
Commit
221af7f87b9 ("Split 'flush_old_exec' into two functions") split
the function at the point of no return - ie right where there were no
more error cases to check. That made sense from a technical standpoint,
but when we then also combined it with the actual personality setting
going in between flush_old_exec() and setup_new_exec(), it needs to be a
bit more careful.
In particular, we need to make sure that we really flush the old
personality bits in the 'flush' stage, rather than later in the 'setup'
stage, since otherwise we might be flushing the _new_ personality state
that we're just setting up.
So this moves the flags and personality flushing (and 'flush_thread()',
which is the arch-specific function that generally resets lazy FP state
etc) of the old process into flush_old_exec(), so that it doesn't affect
any state that execve() is setting up for the new process environment.
This was reported by Michal Simek as breaking his Microblaze qemu
environment.
Reported-and-tested-by: Michal Simek <michal.simek@petalogix.com>
Cc: Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dmitry Monakhov [Wed, 27 Jan 2010 19:44:36 +0000 (22:44 +0300)]
block: fix bio_add_page for non trivial merge_bvec_fn case
commit
1d6165851cd8e3f919d446cd6da35dee44e8837e upstream.
We have to properly decrease bi_size in order to merge_bvec_fn return
right result. Otherwise this result in false merge rejects for two
absolutely valid bio_vecs. This may cause significant performance
penalty for example fs_block_size == 1k and block device is raid0 with
small chunk_size = 8k. Then it is impossible to merge 7-th fs-block in
to bio which already has 6 fs-blocks.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nick Piggin [Mon, 1 Feb 2010 11:25:57 +0000 (22:25 +1100)]
mm: purge fragmented percpu vmap blocks
commit
02b709df817c0db174f249cc59e5f7fd01b64d92 upstream.
Improve handling of fragmented per-CPU vmaps. We previously don't free
up per-CPU maps until all its addresses have been used and freed. So
fragmented blocks could fill up vmalloc space even if they actually had
no active vmap regions within them.
Add some logic to allow all CPUs to have these blocks purged in the case
of failure to allocate a new vm area, and also put some logic to trim
such blocks of a current CPU if we hit them in the allocation path (so
as to avoid a large build up of them).
Christoph reported some vmap allocation failures when using the per CPU
vmap APIs in XFS, which cannot be reproduced after this patch and the
previous bug fix.
Cc: linux-mm@kvack.org
Tested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nick Piggin [Mon, 1 Feb 2010 11:24:18 +0000 (22:24 +1100)]
mm: percpu-vmap fix RCU list walking
commit
de5604231ce4bc8db1bc1dcd27d8540cbedf1518 upstream.
RCU list walking of the per-cpu vmap cache was broken. It did not use
RCU primitives, and also the union of free_list and rcu_head is
obviously wrong (because free_list is indeed the list we are RCU
walking).
While we are there, remove a couple of unused fields from an earlier
iteration.
These APIs aren't actually used anywhere, because of problems with the
XFS conversion. Christoph has now verified that the problems are solved
with these patches. Also it is an exported interface, so I think it
will be good to be merged now (and Christoph wants to get the XFS
changes into their local tree).
Cc: linux-mm@kvack.org
Tested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Mon, 11 Jan 2010 02:14:44 +0000 (11:14 +0900)]
libata: retry link resume if necessary
commit
5040ab67a2c6d5710ba497dc52a8f7035729d7b0 upstream.
Interestingly, when SIDPR is used in ata_piix, writes to DET in
SControl sometimes get ignored leading to detection failure. Update
sata_link_resume() such that it reads back SControl after clearing DET
and retry if it's not clear.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: fengxiangjun <fengxiangjun@neusoft.com>
Reported-by: Jim Faulkner <jfaulkne@ccs.neu.edu>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suravee Suthikulpanit [Mon, 18 Jan 2010 17:25:36 +0000 (11:25 -0600)]
oprofile/x86: fix crash when profiling more than 28 events
commit
d8cc108f4fab42b380c6b3f3356f99e8dd5372e2 upstream.
With multiplexing enabled oprofile crashs when profiling more than 28
events. This patch fixes this.
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andi Kleen [Thu, 21 Jan 2010 22:26:27 +0000 (23:26 +0100)]
oprofile/x86: add Xeon 7500 series support
commit
e83e452b0692c9c13372540deb88a77d4ae2553d upstream.
Add Xeon 7500 series support to oprofile.
Straight forward: it's the same as Core i7, so just detect
the model number. No user space changes needed.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Glauber Costa [Mon, 1 Feb 2010 18:54:05 +0000 (16:54 -0200)]
KVM: allow userspace to adjust kvmclock offset
(cherry picked from
afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d)
When we migrate a kvm guest that uses pvclock between two hosts, we may
suffer a large skew. This is because there can be significant differences
between the monotonic clock of the hosts involved. When a new host with
a much larger monotonic time starts running the guest, the view of time
will be significantly impacted.
Situation is much worse when we do the opposite, and migrate to a host with
a smaller monotonic clock.
This proposed ioctl will allow userspace to inform us what is the monotonic
clock value in the source host, so we can keep the time skew short, and
more importantly, never goes backwards. Userspace may also need to trigger
the current data, since from the first migration onwards, it won't be
reflected by a simple call to clock_gettime() anymore.
[marcelo: future-proof abi with a flags field]
[jan: fix KVM_GET_CLOCK by clearing flags field instead of checking it]
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jarek Poplawski [Sat, 16 Jan 2010 09:04:04 +0000 (01:04 -0800)]
ax25: netrom: rose: Fix timer oopses
[ Upstream commit
d00c362f1b0ff54161e0a42b4554ac621a9ef92d ]
Wrong ax25_cb refcounting in ax25_send_frame() and by its callers can
cause timer oopses (first reported with 2.6.29.6 kernel).
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=14905
Reported-by: Bernard Pidoux <bpidoux@free.fr>
Tested-by: Bernard Pidoux <bpidoux@free.fr>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>