Colin Cross [Tue, 11 Jan 2011 01:18:52 +0000 (17:18 -0800)]
Merge branch 'android-2.6.36' into android-tegra-2.6.36
Colin Cross [Tue, 11 Jan 2011 01:18:42 +0000 (17:18 -0800)]
Merge branch 'linux-tegra-2.6.36' into android-tegra-2.6.36
Simon Wilson [Sat, 8 Jan 2011 02:46:34 +0000 (18:46 -0800)]
cgroup: leave cg_list valid upon cgroup_exit
A thread/process in cgroup_attach_task() could have called
list_del(&tsk->cg_list) after cgroup_exit() had already called
list_del() on the same list. Since it only checked for
!list_empty(&tsk->cg_list) before doing this, the list_del()
call would thus be made twice.
The solution is to leave tsk->cg_list in a valid state in
cgroup_exit() with list_del_init(&tsk->cg_list), which leaves
an empty list.
Change-Id: I4e7c1d0665fced629f5ca033c18dd98afe080e0c
Signed-off-by: Simon Wilson <simonwilson@google.com>
Arve Hjønnevåg [Sat, 8 Jan 2011 03:00:01 +0000 (19:00 -0800)]
rtc: alarm: Update hrtimer if alarm at the head of the queue is reprogrammed
If an alarm was restarted with a value that moved it away from the head
of a queue, the hrtimer would not be updated. This would cause unnecessary
wakeups.
Change-Id: If379f8dd92b0bdb3173bd8d057adfe0dc1d15259
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Benoit Goby [Mon, 10 Jan 2011 22:58:00 +0000 (14:58 -0800)]
ARM: tegra: Fix powergate_debugfs_init return value
Change-Id: Iff865e0f74e1667aa6e998a63d33d3b4cd09694c
Signed-off-by: Benoit Goby <benoit@android.com>
Rebecca Schultz Zavin [Fri, 3 Dec 2010 23:43:33 +0000 (15:43 -0800)]
video: tegra: nvmap: Add carveout killer
This change attempts to reclaim carveout memory by killing
other carveout users when an allocation fails. Processes
are killed in order of priority from lowest to highest, and then
from largest to smallest users.
Change-Id: Iee8a6f36269bc8165d691000a153dbf9f4337775
Signed-off-by: Rebecca Schultz Zavin <rebecca@android.com>
Colin Cross [Mon, 10 Jan 2011 03:20:14 +0000 (19:20 -0800)]
Merge branch 'linux-tegra-2.6.36' into android-tegra-2.6.36
Stephen Warren [Wed, 5 Jan 2011 00:47:55 +0000 (17:47 -0700)]
ARM: tegra: pll_a clock fixes
Increase the max_frequency entries for clocks that can be driven from pll_a
to match the fastest pll_a table entry.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
Stephen Warren [Wed, 5 Jan 2011 21:24:12 +0000 (14:24 -0700)]
ARM: tegra: Prevent requeuing in-progress DMA requests
If a request already in the queue is passed to tegra_dma_enqueue_req,
tegra_dma_req.node->{next,prev} will end up pointing to itself instead
of at tegra_dma_channel.list, which is the way a the end-of-list
should be set up. When the DMA request completes and is list_del'd,
the list head will still point at it, yet the node's next/prev will
contain the list poison values. When the next DMA request completes,
a kernel panic will occur when those poison values are dereferenced.
This makes the DMA driver more robust in the face of buggy clients.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
Lowell Dennis [Wed, 15 Dec 2010 00:35:17 +0000 (16:35 -0800)]
rtc: tps6586x: Fix error in RTC tick calculations
In the TPS6586x PMU/PMIC RTC support code, when
converting from seconds to ticks using a shift
operator, the most significant bits were being lost
due to seconds being a 32-bit value and ticks being
a 64-bit value. A hard cast was added to avoid this
loss.
Reviewed-by: Lowell Dennis <ldennis@nvidia.com>
Tested-by: Lowell Dennis <ldennis@nvidia.com>
Reviewed-by: Jonathan Mayo <jmayo@nvidia.com>
Reviewed-by: Peter Zu <pzu@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
Jay Cheng [Fri, 7 Jan 2011 07:03:46 +0000 (02:03 -0500)]
usb: ehci: tegra: continues driving FS-J during resume
To prevent USB glitch.
Also only program PTC bits when resume from LP0
Change-Id: Iced668e33f986828d3a483b411055948b5b257e1
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Jay Cheng [Fri, 7 Jan 2011 07:03:46 +0000 (02:03 -0500)]
ARM: tegra: usb_phy: continues driving FS-J during resume
to prevent USB glitch.
Change-Id: Iced668e33f986828d3a483b411055948b5b257e1
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Jay Cheng [Thu, 6 Jan 2011 05:16:18 +0000 (00:16 -0500)]
usb: ehci: tegra: remove reschedule rh_timer
Reschedule rh_timer may cause usb device resume fail, as rh_timer may be
timeout and send USB_REQ_GET_STATUS SETUP control transfer by the time when
the device is handling clear suspend feature, which in turn the device may
drop clear suspend feature request.
Actually on port resume case, the host driver don't need to reschedule
rh_timer to check port status. The host driver will check port status right
after suspend feature is cleared.
Change-Id: I6205e97af49ed4349b6215b851f6b5f1394258d8
Signed-off-by: Jay Cheng <jacheng@nvidia.com>
Colin Cross [Sat, 8 Jan 2011 22:47:29 +0000 (14:47 -0800)]
Merge branch 'linux-tegra-2.6.36' into android-tegra-2.6.36
Conflicts:
drivers/misc/Kconfig
drivers/misc/Makefile
Change-Id: I826244513f799fdd2fb0269abad3271c96661293
Colin Cross [Sat, 8 Jan 2011 21:59:15 +0000 (13:59 -0800)]
ARM: tegra: powergate: Allow calling power up when already powered
Allow calling tegra_powergate_sequence_power_up on a partition
that is already powered. Reset the partition, and return success
with the clock enabled.
Change-Id: I776c6a84091f0bb8faca22d87b3fabf0cfede564
Signed-off-by: Colin Cross <ccross@android.com>
Todd Poynor [Mon, 20 Dec 2010 23:05:52 +0000 (15:05 -0800)]
NCT1008 temperature sensor driver
Replace the PM-only driver for NCT1008 with a new version written by
Varun Wadekar and Dmitriy Gruzman. Add a callback to an alarm
function specified in the board platform data.
Change-Id: Ib429533930ee75af3402d24b0bc286da9f6ee67b
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Greg Meiste [Tue, 16 Nov 2010 19:33:06 +0000 (13:33 -0600)]
misc: Initial NCT1008 driver
Initial version of the NCT1008 driver to turn off the sensor when the
device is suspended. This improves standby current drain.
Change-Id: Ia64613c33c0052434d5e304c434605611e5ef789
Signed-off-by: Greg Meiste <w30289@motorola.com>
Erik Gilling [Sat, 8 Jan 2011 02:45:43 +0000 (18:45 -0800)]
video: tegra: fix debug regs file hang
Change-Id: I2bdfe5ec9f69b7b7960e59bec76fb9b02b61f3fb
Signed-off-by: Erik Gilling <konkers@android.com>
Colin Cross [Sat, 8 Jan 2011 01:20:53 +0000 (17:20 -0800)]
Merge branch 'linux-tegra-2.6.36' into android-tegra-2.6.36
Conflicts:
arch/arm/mm/cache-v6.S
Change-Id: I1a2063218dd705a762a40f4a9dfe504ce1a1d491
Colin Cross [Sat, 8 Jan 2011 01:16:59 +0000 (17:16 -0800)]
Merge branch 'android-2.6.36' into android-tegra-2.6.36
Colin Cross [Sat, 8 Jan 2011 01:14:48 +0000 (17:14 -0800)]
Merge commit 'v2.6.36.3' into linux-tegra-2.6.36
Varun Wadekar [Tue, 28 Dec 2010 09:31:18 +0000 (15:01 +0530)]
crytpo: tegra-aes: make aes_handle_req aynschronous
the encrypt/decrypt callbacks have to return with -EINPROGRESS
error code and the request complete callback needs to be
called from handle_req for aynchronous block ciphers. use
work queue to make the driver asynchronous.
Change-Id: I0dec1185c31e5de7ba039c39d6bd87c8b3487b2a
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Colin Cross [Fri, 7 Jan 2011 22:52:56 +0000 (14:52 -0800)]
input: keyreset: Allow reset function to be overriden
Change-Id: Ibb3dda05772b2e89d7b2646689944d309cb1f74e
Signed-off-by: Colin Cross <ccross@android.com>
Greg Kroah-Hartman [Fri, 7 Jan 2011 22:39:58 +0000 (14:39 -0800)]
Linux 2.6.36.3
MyungJoo Ham [Tue, 23 Nov 2010 10:39:23 +0000 (11:39 +0100)]
ARM: 6490/1: MM: bugfix: initialize spinlock for init_mm.context
init_mm used at kernel/sched.c:idle_task_exit() has spin_lock
(init_mm.context.id_lock) that is not initialized when spin_lock/unlock
is called at an ARM machine. Note that mm_struct.context.id_lock is
usually initialized except for the instance of init_mm at
linux/arch/arm/mm/context.c
Not initializing this spinlock incurs "BUG: pinlock bad magic"
warning when spinlock debug is enabled. We have observed such
instances when testing PM in S5PC210 machines.
Change-Id: I52c6c6d035c220822a5675faaf8d163a3535985d
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Colin Cross <ccross@android.com>
Jean-Francois Moine [Tue, 14 Dec 2010 19:15:37 +0000 (16:15 -0300)]
gspca - sonixj: Add a flag in the driver_info table
commit
c6c14330717f9850b4b4c054b81424b9979cd07d upstream.
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>
Jean-Francois Moine [Tue, 14 Dec 2010 19:16:16 +0000 (16:16 -0300)]
gspca - sonixj: Set the flag for some devices
commit
b2272a49e7df37732d73988f00468ce31e1ebc92 upstream.
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
value as other webcams with the same sensor. For now, only two webcams have
been so detected: the Microsoft's VX1000 and VX3000.
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>
David Kilroy [Tue, 7 Dec 2010 18:50:42 +0000 (18:50 +0000)]
orinoco: initialise priv->hw before assigning the interrupt
commit
229bd792be0bad245b78ed8f119952733a4752e5 upstream.
The interrupt handler takes a lock - but since commit
bcad6e80f3f this
lock goes through an indirection specified in the hermes_t structure.
We must therefore initialise the structure before setting up the
interrupt handler.
Fix orinoco_cs and spectrum_cs
<https://bugzilla.kernel.org/show_bug.cgi?id=23932>
Bisected by: Matt Domsch <Matt_Domsch@dell.com>
Signed-off by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mauro Carvalho Chehab [Thu, 2 Dec 2010 03:57:03 +0000 (01:57 -0200)]
Don't export format_by_forcc on two different drivers
commit
a757ee2216211278680dd8ac869aabe7b4a9970d upstream.
Drivers should append their name on exported symbols, to avoid
conflicts with allyesconfig:
drivers/staging/built-in.o: In function `format_by_fourcc':
/home/v4l/work_trees/linus/drivers/staging/cx25821/cx25821-video.c:96: multiple definition of `format_by_fourcc'
drivers/media/built-in.o:/home/v4l/work_trees/linus/drivers/media/common/saa7146_video.c:88: first defined here
Let's rename both occurences with a small shellscript:
for i in drivers/staging/cx25821/*.[ch]; do sed s,format_by_fourcc,cx25821_format_by_fourcc,g <$i >a && mv a $i; done
for i in drivers/media/common/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done
for i in include/media/saa7146*.[ch]; do sed s,format_by_fourcc,saa7146_format_by_fourcc,g <$i >a && mv a $i; done
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Baruch Siach [Wed, 27 Oct 2010 07:03:52 +0000 (04:03 -0300)]
mx2_camera: fix pixel clock polarity configuration
commit
42cc37fe20cc680fb58fe12ae5ba718d683b8ca2 upstream.
When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we get
the inverted behaviour.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Oleg Nesterov [Fri, 5 Nov 2010 15:53:42 +0000 (16:53 +0100)]
posix-cpu-timers: workaround to suppress the problems with mt exec
commit
e0a70217107e6f9844628120412cb27bb4cea194 upstream.
posix-cpu-timers.c correctly assumes that the dying process does
posix_cpu_timers_exit_group() and removes all !CPUCLOCK_PERTHREAD
timers from signal->cpu_timers list.
But, it also assumes that timer->it.cpu.task is always the group
leader, and thus the dead ->task means the dead thread group.
This is obviously not true after de_thread() changes the leader.
After that almost every posix_cpu_timer_ method has problems.
It is not simple to fix this bug correctly. First of all, I think
that timer->it.cpu should use struct pid instead of task_struct.
Also, the locking should be reworked completely. In particular,
tasklist_lock should not be used at all. This all needs a lot of
nontrivial and hard-to-test changes.
Change __exit_signal() to do posix_cpu_timers_exit_group() when
the old leader dies during exec. This is not the fix, just the
temporary hack to hide the problem for 2.6.37 and stable. IOW,
this is obviously wrong but this is what we currently have anyway:
cpu timers do not work after mt exec.
In theory this change adds another race. The exiting leader can
detach the timers which were attached to the new leader. However,
the window between de_thread() and release_task() is small, we
can pretend that sys_timer_create() was called before de_thread().
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jesper Juhl [Sat, 25 Dec 2010 18:57:41 +0000 (19:57 +0100)]
x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree()
commit
5cdd2de0a76d0ac47f107c8a7b32d75d25768dc1 upstream.
In arch/x86/kernel/microcode_intel.c::generic_load_microcode()
we have this:
while (leftover) {
...
if (get_ucode_data(mc, ucode_ptr, mc_size) ||
microcode_sanity_check(mc) < 0) {
vfree(mc);
break;
}
...
}
if (mc)
vfree(mc);
This will cause a double free of 'mc'. This patch fixes that by
just removing the vfree() call in the loop since 'mc' will be
freed nicely just after we break out of the loop.
There's also a second change in the patch. I noticed a lot of
checks for pointers being NULL before passing them to vfree().
That's completely redundant since vfree() deals gracefully with
being passed a NULL pointer. Removing the redundant checks
yields a nice size decrease for the object file.
Size before the patch:
text data bss dec hex filename
4578 240 1032 5850 16da arch/x86/kernel/microcode_intel.o
Size after the patch:
text data bss dec hex filename
4489 240 984 5713 1651 arch/x86/kernel/microcode_intel.o
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Cc: Shaohua Li <shaohua.li@intel.com>
LKML-Reference: <alpine.LNX.2.00.
1012251946100.10759@swampdragon.chaosbits.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Martin K. Petersen [Wed, 1 Dec 2010 18:41:49 +0000 (19:41 +0100)]
block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
commit
e692cb668fdd5a712c6ed2a2d6f2a36ee83997b4 upstream.
When stacking devices, a request_queue is not always available. This
forced us to have a no_cluster flag in the queue_limits that could be
used as a carrier until the request_queue had been set up for a
metadevice.
There were several problems with that approach. First of all it was up
to the stacking device to remember to set queue flag after stacking had
completed. Also, the queue flag and the queue limits had to be kept in
sync at all times. We got that wrong, which could lead to us issuing
commands that went beyond the max scatterlist limit set by the driver.
The proper fix is to avoid having two flags for tracking the same thing.
We deprecate QUEUE_FLAG_CLUSTER and use the queue limit directly in the
block layer merging functions. The queue_limit 'no_cluster' is turned
into 'cluster' to avoid double negatives and to ease stacking.
Clustering defaults to being enabled as before. The queue flag logic is
removed from the stacking function, and explicitly setting the cluster
flag is no longer necessary in DM and MD.
Reported-by: Ed Lin <ed.lin@promise.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Galbraith [Wed, 8 Dec 2010 10:05:42 +0000 (11:05 +0100)]
Sched: fix skip_clock_update optimization
commit
f26f9aff6aaf67e9a430d16c266f91b13a5bff64 upstream.
idle_balance() drops/retakes rq->lock, leaving the previous task
vulnerable to set_tsk_need_resched(). Clear it after we return
from balancing instead, and in setup_thread_stack() as well, so
no successfully descheduled or never scheduled task has it set.
Need resched confused the skip_clock_update logic, which assumes
that the next call to update_rq_clock() will come nearly immediately
after being set. Make the optimization robust against the waking
a sleeper before it sucessfully deschedules case by checking that
the current task has not been dequeued before setting the flag,
since it is that useless clock update we're trying to save, and
clear unconditionally in schedule() proper instead of conditionally
in put_prev_task().
Signed-off-by: Mike Galbraith <efault@gmx.de>
Reported-by: Bjoern B. Brandenburg <bbb.lst@gmail.com>
Tested-by: Yong Zhang <yong.zhang0@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
1291802742.1417.9.camel@marge.simson.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel T Chen [Tue, 28 Dec 2010 22:20:02 +0000 (17:20 -0500)]
ALSA: hda: Use LPIB quirk for Dell Inspiron m101z/1120
commit
e03fa055bc126e536c7f65862e08a9b143138ea9 upstream.
Sjoerd Simons reports that, without using position_fix=1, recording
experiences overruns. Work around that by applying the LPIB quirk
for his hardware.
Reported-and-tested-by: Sjoerd Simons <sjoerd@debian.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>
Johannes Berg [Wed, 22 Dec 2010 09:15:07 +0000 (10:15 +0100)]
mac80211: fix mesh forwarding
commit
b51aff057c9d0ef6c529dc25fd9f775faf7b6c63 upstream.
Under memory pressure, the mac80211 mesh code
may helpfully print a message that it failed
to clone a mesh frame and then will proceed
to crash trying to use it anyway. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Fri, 3 Dec 2010 14:19:13 +0000 (15:19 +0100)]
libata-sff: fix HSM_ST_ERR handling in __ata_sff_port_intr()
commit
687a993339c4f3a63654746230da3aab8bbdbffd upstream.
While separating out BMDMA irq handler from SFF, commit
c3b28894
(libata-sff: separate out BMDMA irq handler) incorrectly made
__ata_sff_port_intr() consider an IRQ to be an idle one if the host
state was transitioned to HSM_ST_ERR by ata_bmdma_port_intr().
This makes BMDMA drivers ignore IRQs reporting host bus error which
leads to timeouts instead of triggering EH immediately. Fix it by
making __ata_sff_port_intr() consider the IRQ to be an idle one iff
the state is HSM_ST_IDLE. This is equivalent to adding HSM_ST_ERR to
the "break"ing case but less error-prone.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Antonio Toma <antonio.toma@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mimi Zohar [Mon, 3 Jan 2011 22:59:10 +0000 (14:59 -0800)]
ima: fix add LSM rule bug
commit
867c20265459d30a01b021a9c1e81fb4c5832aa9 upstream.
If security_filter_rule_init() doesn't return a rule, then not everything
is as fine as the return code implies.
This bug only occurs when the LSM (eg. SELinux) is disabled at runtime.
Adding an empty LSM rule causes ima_match_rules() to always succeed,
ignoring any remaining rules.
default IMA TCB policy:
# PROC_SUPER_MAGIC
dont_measure fsmagic=0x9fa0
# SYSFS_MAGIC
dont_measure fsmagic=0x62656572
# DEBUGFS_MAGIC
dont_measure fsmagic=0x64626720
# TMPFS_MAGIC
dont_measure fsmagic=0x01021994
# SECURITYFS_MAGIC
dont_measure fsmagic=0x73636673
< LSM specific rule >
dont_measure obj_type=var_log_t
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0
Thus without the patch, with the boot parameters 'tcb selinux=0', adding
the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB
measurement policy, would result in nothing being measured. The patch
prevents the default TCB policy from being replaced.
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Cc: James Morris <jmorris@namei.org>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Cc: David Safford <safford@watson.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>
Saeed Bishara [Tue, 21 Dec 2010 14:53:39 +0000 (16:53 +0200)]
mv_xor: fix race in tasklet function
commit
8333f65ef094e47020cd01452b4637e7daf5a77f upstream.
use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
aquires the spin lock that needed to protect the drivers data.
Signed-off-by: Saeed Bishara <saeed@marvell.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sheng Yang [Wed, 8 Dec 2010 02:49:43 +0000 (10:49 +0800)]
KVM: Fix OSXSAVE after migration
commit
3ea3aa8cf67d3bbe00a19b6a4013d19efa7d0f41 upstream.
CPUID's OSXSAVE is a mirror of CR4.OSXSAVE bit. We need to update the CPUID
after migration.
KVM-Stable-Tag.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Joerg Roedel [Tue, 7 Dec 2010 16:15:05 +0000 (17:15 +0100)]
KVM: SVM: Do not report xsave in supported cpuid
commit
24d1b15f72abe3465e871d11cfc9dc34d1aab8b2 upstream.
To support xsave properly for the guest the SVM module need
software support for it. As long as this is not present do
not report the xsave as supported feature in cpuid.
As a side-effect this patch moves the bit() helper function
into the x86.h file so that it can be used in svm.c too.
KVM-Stable-Tag.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andre Przywara [Wed, 1 Dec 2010 11:17:44 +0000 (12:17 +0100)]
KVM: enlarge number of possible CPUID leaves
commit
73c1160ce377d8fc6d84cb630ebf9658808bec49 upstream.
Currently the number of CPUID leaves KVM handles is limited to 40.
My desktop machine (AthlonII) already has 35 and future CPUs will
expand this well beyond the limit. Extend the limit to 80 to make
room for future processors.
KVM-Stable-Tag.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Rosenberg [Sat, 25 Dec 2010 21:23:40 +0000 (16:23 -0500)]
sound: Prevent buffer overflow in OSS load_mixer_volumes
commit
d81a12bc29ae4038770e05dce4ab7f26fd5880fb upstream.
The load_mixer_volumes() function, which can be triggered by
unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to
a buffer overflow. Because the provided "name" argument isn't
guaranteed to be NULL terminated at the expected 32 bytes, it's possible
to overflow past the end of the last element in the mixer_vols array.
Further exploitation can result in an arbitrary kernel write (via
subsequent calls to load_mixer_volumes()) leading to privilege
escalation, or arbitrary kernel reads via get_mixer_levels(). In
addition, the strcmp() may leak bytes beyond the mixer_vols array.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
KAMEZAWA Hiroyuki [Wed, 29 Dec 2010 22:07:11 +0000 (14:07 -0800)]
memcg: fix wrong VM_BUG_ON() in try_charge()'s mm->owner check
commit
ebb76ce16daf6908dc030dec1c00827d37129fe5 upstream.
At __mem_cgroup_try_charge(), VM_BUG_ON(!mm->owner) is checked.
But as commented in mem_cgroup_from_task(), mm->owner can be NULL
in some racy case. This check of VM_BUG_ON() is bad.
A possible story to hit this is at swapoff()->try_to_unuse(). It passes
mm_struct to mem_cgroup_try_charge_swapin() while mm->owner is NULL. If we
can't get proper mem_cgroup from swap_cgroup information, mm->owner is used
as charge target and we see NULL.
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: Hugh Dickins <hughd@google.com>
Reported-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: Balbir Singh <balbir@linux.vnet.ibm.com>
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>
Eric Anholt [Tue, 21 Dec 2010 02:40:06 +0000 (18:40 -0800)]
drm/i915, intel_ips: When i915 loads after IPS, make IPS relink to i915.
commit
63ee41d794d9c555f84205517a68509848988760 upstream.
The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers. This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS. If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Flynn [Wed, 8 Dec 2010 16:10:21 +0000 (16:10 +0000)]
drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI converter
commit
8316f33766a82907c694267ff911e45e256f09f9 upstream.
The DisplayPort standard (1.1a) states that:
The I2C-over-AUX Reply field is valid only when Native AUX CH Reply
field is AUX_ACK (00). When Native AUX CH Reply field is not 00, then,
I2C-over-AUX Reply field must be 00 and be ignored.
This fixes broken EDID reading when using an active DisplayPort to
duallink DVI converter. If the AUX CH replier chooses to defer the
transaction, a short read occurs and erroneous data is returned as
the i2c reply due to a lack of length checking and failure to check
for AUX ACK.
As a result, broken EDIDs can look like:
0 1 2 3 4 5 6 7 8 9 a b c d e f
0123456789abcdef
00: bc bc bc ff bc bc bc ff bc bc bc ac bc bc bc 45 ???.???.???????E
10: bc bc bc 10 bc bc bc 34 bc bc bc ee bc bc bc 4c ???????4???????L
20: bc bc bc 50 bc bc bc 00 bc bc bc 40 bc bc bc 00 ???P???.???@???.
30: bc bc bc 01 bc bc bc 01 bc bc bc a0 bc bc bc 40 ???????????????@
40: bc bc bc 00 bc bc bc 00 bc bc bc 00 bc bc bc 55 ???.???.???.???U
50: bc bc bc 35 bc bc bc 31 bc bc bc 20 bc bc bc fc ???5???1??? ????
60: bc bc bc 4c bc bc bc 34 bc bc bc 46 bc bc bc 00 ???L???4???F???.
70: bc bc bc 38 bc bc bc 11 bc bc bc 20 bc bc bc 20 ???8??????? ???
80: bc bc bc ff bc bc bc ff bc bc bc ff bc bc bc ff ???.???.???.???.
...
which can lead to:
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>30 30 30 30 30 30 30 32 38 32 30 32 63 63 31 61
000000028202cc1a
<3>28 00 02 8c 00 00 00 00 18 00 00 00 00 00 00 00 (...............
<3>20 4c 61 73 74 20 62 65 61 63 6f 6e 3a 20 33 32 Last beacon: 32
<3>32 30 6d 73 20 61 67 6f 46 00 05 8c 00 00 00 00 20ms agoF.......
<3>36 00 00 00 00 00 00 00 00 0c 57 69 2d 46 69 20 6.........Wi-Fi
<3>52 6f 75 74 65 72 01 08 82 84 8b 96 24 30 48 6c Router......$0Hl
<3>03 01 01 06 02 00 00 2a 01 00 2f 01 00 32 04 0c .......*../..2..
<3>12 18 60 dd 09 00 10 18 02 00 00 01 00 00 18 00 ..`.............
Signed-off-by: David Flynn <davidf@rd.bbc.co.uk>
[ickle: fix up some surrounding checkpatch warnings]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Mon, 20 Dec 2010 16:22:29 +0000 (11:22 -0500)]
drm/radeon/kms: reorder display resume to avoid problems
commit
a93f344d3c04e4b84490c65f2a574387c593be40 upstream.
On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed. Re-program
the mode first, then reset the dpms state.
This fixes the infamous atombios timeouts on resume.
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>
Alex Deucher [Mon, 20 Dec 2010 17:35:03 +0000 (12:35 -0500)]
drm/radeon/kms: fix evergreen asic reset
commit
9f0c4f9c2f835eee1bbb93f96bf9483d56f1892b upstream.
Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Mon, 20 Dec 2010 17:35:04 +0000 (12:35 -0500)]
drm/radeon/kms/evergreen: reset the grbm blocks at resume and init
commit
86f5c9edbb3bac37cc8cee6528a929005ba72aad upstream.
This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.
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>
Mark Brown [Wed, 24 Nov 2010 18:01:39 +0000 (18:01 +0000)]
mfd: Supply IRQ base for WM832x devices
commit
bd7c72ed18d719c1fb0fdf6ff9042d8ab78fdf71 upstream.
Without this the IRQ base will not be correctly configured for the
subdevices.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Thu, 2 Dec 2010 16:25:43 +0000 (16:25 +0000)]
mfd: Support additional parent IDs for wm831x
commit
b93cef556162b0f33399bfe5f307c54f51554e09 upstream.
Some newer device revisions add a second parent ID. Support this in
the device validity checks done at startup.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Robert Richter [Mon, 3 Jan 2011 11:15:14 +0000 (12:15 +0100)]
arch/x86/oprofile/op_model_amd.c: Perform initialisation on a single CPU
commit
c7c25802b39c443b3745cfa973dc49a97a3491f8 upstream.
Disable preemption in init_ibs(). The function only checks the
ibs capabilities and sets up pci devices (if necessary). It runs
only on one cpu but operates with the local APIC and some MSRs,
thus it is better to disable preemption.
[ 7.034377] BUG: using smp_processor_id() in preemptible [
00000000] code: modprobe/483
[ 7.034385] caller is setup_APIC_eilvt+0x155/0x180
[ 7.034389] Pid: 483, comm: modprobe Not tainted 2.6.37-rc1-
20101110+ #1
[ 7.034392] Call Trace:
[ 7.034400] [<
ffffffff812a2b72>] debug_smp_processor_id+0xd2/0xf0
[ 7.034404] [<
ffffffff8101e985>] setup_APIC_eilvt+0x155/0x180
[ ... ]
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=22812
Reported-by: <atswartz@gmail.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Cc: oprofile-list@lists.sourceforge.net <oprofile-list@lists.sourceforge.net>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Dan Carpenter <error27@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <
20110103111514.GM4739@erda.amd.com>
[ small cleanups ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ben Hutchings [Sun, 2 Jan 2011 23:02:42 +0000 (23:02 +0000)]
watchdog: Improve initialisation error message and documentation
commit
551423748a4eba55f2eb0fc250d757986471f187 upstream.
The error message 'NMI watchdog failed to create perf event...'
does not make it clear that this is a fatal error for the
watchdog. It also currently prints the error value as a
pointer, rather than extracting the error code with PTR_ERR().
Fix that.
Add a note to the description of the 'nowatchdog' kernel
parameter to associate it with this message.
Reported-by: Cesare Leonardi <celeonar@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: 599368@bugs.debian.org
Cc: 608138@bugs.debian.org
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
LKML-Reference: <
1294009362.3167.126.camel@localhost>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Fainelli [Fri, 26 Nov 2010 09:39:55 +0000 (10:39 +0100)]
watchdog: Fix null pointer dereference while accessing rdc321x platform_data
commit
3b3c1f24e96c411a95daabb6af9e09c5381f713b upstream.
rdc321x-wdt currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ahmed S. Darwish [Sat, 25 Dec 2010 09:57:09 +0000 (11:57 +0200)]
RAMOOPS: Don't overflow over non-allocated regions
commit
1873bb8115e678ad9fd0aac9dbbc68383bc36e06 upstream.
The current code mis-calculates the ramoops header size, leading to an
overflow over the next record at best, or over a non-allocated region at
worst. Fix that calculation.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Wolfram Sang [Wed, 22 Dec 2010 01:24:24 +0000 (17:24 -0800)]
rtc: rs5c372: fix buffer size
commit
118364948fad7b6c0469ef2d3ddaee447d7a0b5f upstream.
Match the buffer size to the amount of initialized values. Before, it was
one too big and thus destroyed the neighbouring register causing the clock
to run at false speeds.
Reported-by: Andre van Rooyen <a.v.rooyen@sercom.nl>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
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>
Hillf Danton [Wed, 29 Dec 2010 13:55:28 +0000 (21:55 +0800)]
fix freeing user_struct in user cache
commit
4ef9e11d6867f88951e30db910fa015300e31871 upstream.
When racing on adding into user cache, the new allocated from mm slab
is freed without putting user namespace.
Since the user namespace is already operated by getting, putting has
to be issued.
Signed-off-by: Hillf Danton <dhillf@gmail.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Takashi Iwai [Fri, 10 Dec 2010 07:40:31 +0000 (08:40 +0100)]
mmc: Fix re-probing with PM_POST_RESTORE notification
commit
274476f8fe0b6ac9bac542cc39de12c3dd0f43f6 upstream.
In the error-path where PM notifies PM_POST_RESTORE, the rescan-blockage
should be cleared as well. Otherwise it'll be never re-probed.
Also, as a bonus, this fixes a bug in S4 with user-mode suspend in the
current code, as it sends PM_POST_RESTORE instead of
PM_POST_HIBERNATION wrongly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nicolas Ferre [Fri, 10 Dec 2010 18:14:32 +0000 (19:14 +0100)]
mmc: atmel-mci: fix multiblock SDIO transfers
commit
2f1d791882d21a4002a719fb016a1ac21c8bd6b7 upstream.
Based on report made by Yauhen in:
"MMC: Fix multiblock SDIO transfers in AT91 MCI" patch,
I report those changes to the brother driver: atmel-mci.
So, this patch sets SDIO transfer types: SDIO block and SDIO byte
transfers instead of using ordinary MMC block transfers.
It is checking opcode for SDIO CMD53 and setting transfer
type in MCI_CMDR register properly.
Reported-by: Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yauhen Kharuzhy [Thu, 25 Nov 2010 10:11:51 +0000 (12:11 +0200)]
mmc: at91_mci: fix multiblock SDIO transfers
commit
a2255ff45143001fecbc5e5a4b58fcb999d393ae upstream.
The AT91 MCI has special SDIO transfer types: SDIO block and SDIO byte
transfers, but at91_mci driver doesn't use them and handles all SDIO
transfers as ordinary MMC block transfers. This causes problems for
multiple-block SDIO transfers (in particular for 256-bytes blocks).
Fix this situation by checking the opcode for SDIO CMD53 and setting
the transfer type in the AT91_MCI_CMDR register properly.
This patch was tested with libertas SDIO driver: problem with TX
timeouts on big packets was eliminated.
Signed-off-by: Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andres Salomon [Tue, 21 Dec 2010 21:04:52 +0000 (13:04 -0800)]
cs5535-gpio: handle GPIO regs where higher (clear) bits are set
commit
44658a11f312fb9217674cb90b1a11cbe17fd18d upstream.
The default for non-READ_BACK GPIO regs is to have the clear bits set;
this means that our original errata fix was too simplistic. This
changes it to the following behavior:
- when setting GPIOs, ignore the higher order bits (they're for
clearing, we don't need to care about them).
- when clearing GPIOs, keep all the bits, but unset (via XOR) the
lower order bit that negates the clear bit that we care about. That
is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
currently in the register with 0x0400 (GPIO 26's SET bit), and then
OR that with the GPIO 26's CLEAR bit.
Tested-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andres Salomon [Tue, 21 Dec 2010 21:04:42 +0000 (13:04 -0800)]
cs5535-gpio: don't apply errata #36 to edge detect GPIOs
commit
001851659354cce436b749a793f3512a53394d80 upstream.
The edge detect status GPIOs function differently from the other atomic
model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
but writing 1 to the lower bits also clears the bit.
This means that read-modify-write doesn't actually work for it, so don't
apply the errata here. If a negative edge status gets lost after
resume.. well, we tried our best!
Tested-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Fainelli [Fri, 26 Nov 2010 09:39:54 +0000 (10:39 +0100)]
gpio: Fix null pointer dereference while accessing rdc321x platform_data
commit
fa6469cb5b2d16703464c344b943e2c025cb7858 upstream.
rdc321x-gpio currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Thu, 9 Dec 2010 18:29:00 +0000 (10:29 -0800)]
xhci: Fix issue with port array setup and buggy hosts.
commit
f8bbeabc34aa945ab4275abc9a4dfde0aea798ca upstream.
Fix two bugs with the port array setup.
The first bug will only show up with broken xHCI hosts with Extended
Capabilities registers that have duplicate port speed entries for the same
port. The idea with the original code was to set the port_array entry to
-1 if the duplicate port speed entry said the port was a different speed
than the original port speed entry. That would mean that later, the port
would not be exposed to the USB core. Unfortunately, I forgot a continue
statement, and the port_array entry would just be overwritten in the next
line.
The second bug would happen if there are conflicting port speed registers
(so that some entry in port_array is -1), or one of the hardware port
registers was not described in the port speed registers (so that some
entry in port_array is 0). The code that sets up the usb2_ports array
would accidentally claim those ports. That wouldn't really cause any
user-visible issues, but it is a bug.
This patch should go into the stable trees that have the port array and
USB 3.0 port disabling prevention patches.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ken Mills [Mon, 13 Dec 2010 15:28:03 +0000 (15:28 +0000)]
n_gsm: gsm_data_alloc buffer allocation could fail and it is not being checked
commit
093d804611b9a38fe59753b37c29f840518406a9 upstream.
gsm_data_alloc buffer allocation could fail and it is not being checked.
Add check for allocated buffer and return if the buffer allocation
fails.
Signed-off-by: Ken Mills <ken.k.mills@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ken Mills [Mon, 13 Dec 2010 15:27:27 +0000 (15:27 +0000)]
n_gsm: Fix message length handling when building header
commit
be7a7411d63ccad165d66fe8e0b11b2ee336159b upstream.
Fix message length handling when building header
When the message length is greater than 127, the length field in the header
is built incorrectly. According to the spec, when the length is less than 128
the length field is a single byte formatted as:
bbbbbbb1. When it is greater
than 127 then the field is two bytes of the format:
bbbbbbb0 bbbbbbbb.
Signed-off-by: Ken Mills <ken.k.mills@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eduardo Costa [Tue, 14 Dec 2010 20:37:59 +0000 (14:37 -0600)]
p54usb: New USB ID for Gemtek WUBI-100GW
commit
56e6417b49132d4f56e9f2241d31942b90b46315 upstream.
This USB ID is for the WUBI-100GW 802.11g Wireless LAN USB Device that
uses p54usb.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Eduardo Costa <ecosta.tmp@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christian Lamparter [Sat, 11 Dec 2010 11:19:48 +0000 (12:19 +0100)]
p54usb: add 5 more USBIDs
commit
16cad7fba037b34ca32cc0adac65bc089d969fb8 upstream.
This patch adds five more USBIDs to the table.
Source:
http://www.linuxant.com/pipermail/driverloader/2005q3/002307.html
http://wireless.kernel.org/en/users/Drivers/p54/devices (by M. Davis)
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>
Greg Kroah-Hartman [Thu, 16 Dec 2010 23:52:30 +0000 (15:52 -0800)]
Revert "USB: gadget: Allow function access to device ID data during bind()"
commit
dbb442b85a1d82f91cfe0524c4f9b3a5196a10ca upstream.
This reverts commit
1ab83238740ff1e1773d5c13ecac43c60cf4aec4.
Turns out this doesn't allow for the device ids to be overridden
properly, so we need to revert the thing.
Reported-by: Jef Driesen <jefdriesen@telenet.be>
Cc: Robert Lukassen <Robert.Lukassen@tomtom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vitaly Kuznetsov [Tue, 14 Dec 2010 15:16:49 +0000 (10:16 -0500)]
USB: usb-storage: unusual_devs entry for the Samsung YP-CP3
commit
d73a9b3001f29271c2e9f2a806b05a431c5d9591 upstream.
Add an unusual_devs entry for the Samsung YP-CP3 MP4 player.
User was getting the following errors in dmesg:
usb 2-6: reset high speed USB device using ehci_hcd and address 2
usb 2-6: reset high speed USB device using ehci_hcd and address 2
usb 2-6: reset high speed USB device using ehci_hcd and address 2
usb 2-6: USB disconnect, address 2
sd 3:0:0:0: [sdb] Assuming drive cache: write through
sdb:<2>ldm_validate_partition_table(): Disk read failed.
Dev sdb: unable to read RDB block 0
unable to read partition table
Signed-off-by: Vitaly Kuznetsov <vitty@altlinux.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Florian Faber [Wed, 1 Dec 2010 09:11:08 +0000 (10:11 +0100)]
USB: ftdi_sio: Add D.O.Tec PID
commit
5363cdc3c5da9bd431552cf5989ab481596f0c6d upstream.
Add FTDI PID to identify D.O.Tec devices correctly.
Signed-off-by: Florian Faber <faberman@linuxproaudio.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Thomas Sailer [Tue, 14 Dec 2010 15:04:05 +0000 (16:04 +0100)]
USB: misc: uss720.c: add another vendor/product ID
commit
ecc1624a2fff45780959efbcb73ace18fdb3c58d upstream.
Fabio Battaglia report that he has another cable that works with this
driver, so this patch adds its vendor/product ID.
Signed-off-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tavis Ormandy [Thu, 9 Dec 2010 14:29:42 +0000 (15:29 +0100)]
install_special_mapping skips security_file_mmap check.
commit
462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream.
The install_special_mapping routine (used, for example, to setup the
vdso) skips the security check before insert_vm_struct, allowing a local
attacker to bypass the mmap_min_addr security restriction by limiting
the available pages for special mappings.
bprm_mm_init() also skips the check, and although I don't think this can
be used to bypass any restrictions, I don't see any reason not to have
the security check.
$ uname -m
x86_64
$ cat /proc/sys/vm/mmap_min_addr
65536
$ cat install_special_mapping.s
section .bss
resb BSS_SIZE
section .text
global _start
_start:
mov eax, __NR_pause
int 0x80
$ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
$ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
$ ./install_special_mapping &
[1] 14303
$ cat /proc/14303/maps
0000f000-
00010000 r-xp
00000000 00:00 0 [vdso]
00010000-
00011000 r-xp
00001000 00:19
2453665 /home/taviso/install_special_mapping
00011000-
ffffe000 rwxp
00000000 00:00 0 [stack]
It's worth noting that Red Hat are shipping with mmap_min_addr set to
4096.
Signed-off-by: Tavis Ormandy <taviso@google.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Robert Swiecki <swiecki@google.com>
[ Changed to not drop the error code - akpm ]
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yan Li [Wed, 1 Dec 2010 07:51:03 +0000 (23:51 -0800)]
Input: synaptics - fix handling of 2-button ClickPads
commit
3bfa321e662edf90fb8123a02c987c2965fa50bb upstream.
Lenovo S10-3t's ClickPad is a 2-button ClickPad that reports BTN_LEFT
and BTN_RIGHT as normal touchpad, unlike the 1-button ClickPad used in
HP mini 210 that reports solely BTN_MIDDLE.
In 0xc0-cap response, the 1-button ClickPad has the 20-bit set while
2-button ClickPad has the 8-bit set.
This patch makes the kernel only handle 1-button ClickPad specially,
and treat 2-button ClickPad in the same fashion as regular touchpads.
This fixes kernel bug #18122 and MeeGo bug #4807.
Signed-off-by: Yan Li <yan.i.li@intel.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Manoj Iyer [Tue, 23 Nov 2010 06:43:44 +0000 (07:43 +0100)]
ALSA: hda - Enable jack sense for Thinkpad Edge 11
commit
6027277e77df2d2893d906c42f5c9f9abcb731e0 upstream.
Add a quirk entry for Thinkpad Edge 11 as well as other TP Edge models.
Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ivo van Doorn [Mon, 23 Aug 2010 17:56:07 +0000 (19:56 +0200)]
rt2x00: Fix max TX power settings
commit
8d1331b37d5b656a7a8e561f8e9d7661dd00c910 upstream.
During initialization each driver reads the default TX power
for each individual channel. However mac80211 only accepts the
maximum value (which is also handled as default value).
As a result, the TX power of the device was being limited to
the default value, which is often quite low compared to the
real maximum acceptable value.
This patch allows each driver to set the maximum value on a
per-channel basis which is forwarded to mac80211. The default
value will be preserved for now, in case we want to update
mac80211 to differentiate between the maximum and default txpower.
This fixes bug complaining about limited TX power values like:
https://bugzilla.kernel.org/show_bug.cgi?id=16358
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suresh Siddha [Mon, 6 Dec 2010 20:26:30 +0000 (12:26 -0800)]
x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
commit
254e42006c893f45bca48f313536fcba12206418 upstream.
On platforms with Intel 7500 chipset, there were some reports of system
hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled.
During kdump, there is a window where the devices might be still using old
kernel's interrupt information, while the kdump kernel is coming up. This can
cause vt-d faults as the interrupt configuration from the old kernel map to
null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled,
we still have the same issue but in this case we will see benign spurious
interrupt hit the new kernel).
Based on platform config settings, these platforms seem to generate NMI/SMI
when a vt-d fault happens and there were reports that the resulting SMI causes
the system to hang.
Fix it by masking vt-d spec defined errors to platform error reporting logic.
VT-d spec related errors are already handled by the VT-d OS code, so need to
report the same error through other channels.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <
1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com>
Reported-by: Max Asbock <masbock@linux.vnet.ibm.com>
Reported-and-tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenji Kaneshige [Wed, 1 Dec 2010 17:40:32 +0000 (09:40 -0800)]
x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
commit
086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream.
In x2apic mode, we need to set the upper address register of the fault
handling interrupt register of the vt-d hardware. Without this
irq migration of the vt-d fault handling interrupt is broken.
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
LKML-Reference: <
1291225233.2648.39.camel@sbsiddha-MOBL3>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Suresh Siddha [Wed, 1 Dec 2010 06:22:29 +0000 (22:22 -0800)]
x86, vt-d: Handle previous faults after enabling fault handling
commit
7f99d946e71e71d484b7543b49e990508e70d0c0 upstream.
Fault handling is getting enabled after enabling the interrupt-remapping (as
the success of interrupt-remapping can affect the apic mode and hence the
fault handling mode).
Hence there can potentially be some faults between the window of enabling
interrupt-remapping in the vt-d and the fault-handling of the vt-d units.
Handle any previous faults after enabling the vt-d fault handling.
For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the
enable_intr_remapping() and see if we can enable fault handling along with
enabling intr-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <
20101201062244.
630417138@intel.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenji Kaneshige [Wed, 1 Dec 2010 06:22:28 +0000 (22:22 -0800)]
x86: Enable the intr-remap fault handling after local APIC setup
commit
7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream.
Interrupt-remapping gets enabled very early in the boot, as it determines the
apic mode that the processor can use. And the current code enables the vt-d
fault handling before the setup_local_APIC(). And hence the APIC LDR registers
and data structure in the memory may not be initialized. So the vt-d fault
handling in logical xapic/x2apic modes were broken.
Fix this by enabling the vt-d fault handling in the end_local_APIC_setup()
A cleaner fix of enabling fault handling while enabling intr-remapping
will be addressed for v2.6.38. [ Enabling intr-remapping determines the
usage of x2apic mode and the apic mode determines the fault-handling
configuration. ]
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
LKML-Reference: <
20101201062244.
541996375@intel.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
H. Peter Anvin [Tue, 14 Dec 2010 00:01:38 +0000 (16:01 -0800)]
x86, gcc-4.6: Use gcc -m options when building vdso
commit
de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream.
The vdso Makefile passes linker-style -m options not to the linker but
to gcc. This happens to work with earlier gcc, but fails with gcc
4.6. Pass gcc-style -m options, instead.
Note: all currently supported versions of gcc supports -m32, so there
is no reason to conditionalize it any more.
Reported-by: H. J. Lu <hjl.tools@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
LKML-Reference: <tip-*@git.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Metcalf [Tue, 14 Dec 2010 20:57:49 +0000 (15:57 -0500)]
arch/tile: handle CLONE_SETTLS in copy_thread(), not user space
commit
bc4cf2bb271b2d557fc510426755da786fc985be upstream.
Previously we were just setting up the "tp" register in the
new task as started by clone() in libc. However, this is not
quite right, since in principle a signal might be delivered to
the new task before it had its TLS set up. (Of course, this race
window still exists for resetting the libc getpid() cached value
in the new task, in principle. But in any case, we are now doing
this exactly the way all other architectures do it.)
This change is important for 2.6.37 since the tile glibc we will
be submitting upstream will not set TLS in user space any more,
so it will only work on a kernel that has this fix. It should
also be taken for 2.6.36.x in the stable tree if possible.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Slava Pestov [Wed, 24 Nov 2010 23:13:16 +0000 (15:13 -0800)]
tracing: Fix panic when lseek() called on "trace" opened for writing
commit
364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
The file_ops struct for the "trace" special file defined llseek as seq_lseek().
However, if the file was opened for writing only, seq_open() was not called,
and the seek would dereference a null pointer, file->private_data.
This patch introduces a new wrapper for seq_lseek() which checks if the file
descriptor is opened for reading first. If not, it does nothing.
Signed-off-by: Slava Pestov <slavapestov@google.com>
LKML-Reference: <
1290640396-24179-1-git-send-email-slavapestov@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Thu, 9 Dec 2010 06:02:14 +0000 (17:02 +1100)]
md: protect against NULL reference when waiting to start a raid10.
commit
589a594be1fb8815b3f18e517be696c48664f728 upstream.
When we fail to start a raid10 for some reason, we call
md_unregister_thread to kill the thread that was created.
Unfortunately md_thread() will then make one call into the handler
(raid10d) even though md_wakeup_thread has not been called. This is
not safe and as md_unregister_thread is called after mddev->private
has been set to NULL, it will definitely cause a NULL dereference.
So fix this at both ends:
- md_thread should only call the handler if THREAD_WAKEUP has been
set.
- raid10 should call md_unregister_thread before setting things
to NULL just like all the other raid modules do.
This is applicable to 2.6.35 and later.
Reported-by: "Citizen" <citizen_lee@thecus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
NeilBrown [Thu, 9 Dec 2010 05:36:28 +0000 (16:36 +1100)]
md: fix bug with re-adding of partially recovered device.
commit
1a855a0606653d2d82506281e2c686bacb4b2f45 upstream.
With v0.90 metadata, a hot-spare does not become a full member of the
array until recovery is complete. So if we re-add such a device to
the array, we know that all of it is as up-to-date as the event count
would suggest, and so it a bitmap-based recovery is possible.
However with v1.x metadata, the hot-spare immediately becomes a full
member of the array, but it record how much of the device has been
recovered. If the array is stopped and re-assembled recovery starts
from this point.
When such a device is hot-added to an array we currently lose the 'how
much is recovered' information and incorrectly included it as a full
in-sync member (after bitmap-based fixup).
This is wrong and unsafe and could corrupt data.
So be more careful about setting saved_raid_disk - which is what
guides the re-adding of devices back into an array.
The new code matches the code in slot_store which does a similar
thing, which is encouraging.
This is suitable for any -stable kernel.
Reported-by: "Dailey, Nate" <Nate.Dailey@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andreas Herrmann [Thu, 16 Dec 2010 20:29:37 +0000 (21:29 +0100)]
x86, amd: Fix panic on AMD CPU family 0x15
[The mainline kernel doesn't have this problem. Commit "(
23588c3) x86,
amd: Add support for CPUID topology extension of AMD CPUs" removed the
family check. But 2.6.32.y needs to be fixed.]
This CPU family check is not required -- existence of the NodeId MSR
is indicated by a CPUID feature flag which is already checked in
amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be
called for newer AMD CPUs.
In worst case this can lead to a panic in the scheduler code for AMD
family 0x15 multi-node AMD CPUs. I just have a picture of VGA console
output so I can't copy-and-paste it herein, but the call stack of such
a panic looked like:
do_divide_error
...
find_busiest_group
run_rebalance_domains
...
apic_timer_interrupt
...
cpu_idle
The mainline kernel doesn't have this problem. Commit "(
23588c3) x86,
amd: Add support for CPUID topology extension of AMD CPUs" removed the
family check. But 2.6.32.y needs to be fixed.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Kilroy [Sun, 5 Dec 2010 15:45:58 +0000 (15:45 +0000)]
orinoco: clear countermeasure setting on commit
commit
ba34fcee476d11e7c9df95932787a22a96ff6e68 upstream.
... and interface up.
In these situations, you are usually trying to connect to a new AP, so
keeping TKIP countermeasures active is confusing. This is already how
the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
tell userspace that countermeasures are active when they aren't.
Clear the setting so that the reporting matches what the driver has
done..
Signed-off by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Kilroy [Sun, 5 Dec 2010 15:43:55 +0000 (15:43 +0000)]
orinoco: fix TKIP countermeasure behaviour
commit
0a54917c3fc295cb61f3fb52373c173fd3b69f48 upstream.
Enable the port when disabling countermeasures, and disable it on
enabling countermeasures.
This bug causes the response of the system to certain attacks to be
ineffective.
It also prevents wpa_supplicant from getting scan results, as
wpa_supplicant disables countermeasures on startup - preventing the
hardware from scanning.
wpa_supplicant works with ap_mode=2 despite this bug because the commit
handler re-enables the port.
The log tends to look like:
State: DISCONNECTED -> SCANNING
Starting AP scan for wildcard SSID
Scan requested (ret=0) - scan timeout 5 seconds
EAPOL: disable timer tick
EAPOL: Supplicant port status: Unauthorized
Scan timeout - try to get results
Failed to get scan results
Failed to get scan results - try scanning again
Setting scan request: 1 sec 0 usec
Starting AP scan for wildcard SSID
Scan requested (ret=-1) - scan timeout 5 seconds
Failed to initiate AP scan.
Reported by: Giacomo Comes <comes@naic.edu>
Signed-off by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Paris [Tue, 23 Nov 2010 23:18:37 +0000 (18:18 -0500)]
inotify: stop kernel memory leak on file creation failure
commit
a2ae4cc9a16e211c8a128ba10d22a85431f093ab upstream.
If inotify_init is unable to allocate a new file for the new inotify
group we leak the new group. This patch drops the reference on the
group on file allocation failure.
Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rafael J. Wysocki [Thu, 16 Dec 2010 16:11:58 +0000 (17:11 +0100)]
PM / Runtime: Fix pm_runtime_suspended()
commit
f08f5a0add20834d3f3d876dfe08005a5df656db upstream.
There are some situations (e.g. in __pm_generic_call()), where
pm_runtime_suspended() is used to decide whether or not to execute
a device's (system) ->suspend() callback. The callback is not
executed if pm_runtime_suspended() returns true, but it does so
for devices that don't even support runtime PM, because the
power.disable_depth device field is ignored by it. This leads to
problems (i.e. devices are not suspened when they should), so rework
pm_runtime_suspended() so that it returns false if the device's
power.disable_depth field is different from zero.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Lars-Peter Clausen [Thu, 4 Nov 2010 22:25:56 +0000 (23:25 +0100)]
MIPS: jz4740: qi_lb60: Fix gpio for the 6th row of the keyboard matrix
commit
fe749aab1d21cbb4d87527a7df8799583c233496 upstream.
This patch fixes the gpio number for the 6th row of the keyboard matrix.
(And fixes a typo in my name...)
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-mips@linux-mips.org
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alexey Starikovskiy [Thu, 9 Dec 2010 22:07:54 +0000 (17:07 -0500)]
ACPI: EC: Add another dmi match entry for MSI hardware
commit
a5dc4f898c2a0f66e2cefada6c687db82ba2fcbc upstream.
http://bugzilla.kernel.org/show_bug.cgi?id=15418
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Peter Zijlstra [Tue, 30 Nov 2010 18:48:45 +0000 (19:48 +0100)]
sched: Cure more NO_HZ load average woes
commit
0f004f5a696a9434b7214d0d3cbd0525ee77d428 upstream.
There's a long-running regression that proved difficult to fix and
which is hitting certain people and is rather annoying in its effects.
Damien reported that after
74f5187ac8 (sched: Cure load average vs
NO_HZ woes) his load average is unnaturally high, he also noted that
even with that patch reverted the load avgerage numbers are not
correct.
The problem is that the previous patch only solved half the NO_HZ
problem, it addressed the part of going into NO_HZ mode, not of
comming out of NO_HZ mode. This patch implements that missing half.
When comming out of NO_HZ mode there are two important things to take
care of:
- Folding the pending idle delta into the global active count.
- Correctly aging the averages for the idle-duration.
So with this patch the NO_HZ interaction should be complete and
behaviour between CONFIG_NO_HZ=[yn] should be equivalent.
Furthermore, this patch slightly changes the load average computation
by adding a rounding term to the fixed point multiplication.
Reported-by: Damien Wyart <damien.wyart@free.fr>
Reported-by: Tim McGrath <tmhikaru@gmail.com>
Tested-by: Damien Wyart <damien.wyart@free.fr>
Tested-by: Orion Poplawski <orion@cora.nwra.com>
Tested-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Chase Douglas <chase.douglas@canonical.com>
LKML-Reference: <
1291129145.32004.874.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeremy Fitzhardinge [Wed, 8 Dec 2010 20:39:12 +0000 (12:39 -0800)]
xen: Provide a variant of __RING_SIZE() that is an integer constant expression
commit
667c78afaec0ac500908e191e8f236e9578d7b1f upstream.
Without this, gcc 4.5 won't compile xen-netfront and xen-blkfront, where
this is being used to specify array sizes.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Heiko Carstens [Fri, 26 Nov 2010 12:42:47 +0000 (13:42 +0100)]
printk: Fix wake_up_klogd() vs cpu hotplug
commit
49f4138346b3cec2706adff02658fe27ceb1e46f upstream.
wake_up_klogd() may get called from preemptible context but uses
__raw_get_cpu_var() to write to a per cpu variable. If it gets preempted
between getting the address and writing to it, the cpu in question could be
offline if the process gets scheduled back and hence writes to the per cpu data
of an offline cpu.
This buggy behaviour was introduced with
fa33507a "printk: robustify
printk, fix #2" which was supposed to fix a "using smp_processor_id() in
preemptible" warning.
Let's use this_cpu_write() instead which disables preemption and makes sure
that the outlined scenario cannot happen.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <
20101126124247.GC7023@osiris.boeblingen.de.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andy Lutomirski [Tue, 16 Nov 2010 23:40:52 +0000 (18:40 -0500)]
nouveau: Acknowledge HPD irq in handler, not bottom half
commit
ab838338a2a9e0cb8346eb0cab9977be13e8dce5 upstream.
The old code generated an interrupt storm bad enough to completely
take down my system.
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bob Moore [Sat, 23 Oct 2010 05:36:40 +0000 (01:36 -0400)]
ACPICA: Fix Scope() op in module level code
commit
8df3fc981dc12d9fdcaef4100a2193b605024d7a upstream.
Some Panasonic Toughbooks create nodes in module level code.
Module level code is the executable AML code outside of control method,
for example, below AML code creates a node \_SB.PCI0.GFX0.DD02.CUBL
If (\_OSI ("Windows 2006"))
{
Scope (\_SB.PCI0.GFX0.DD02)
{
Name (CUBL, Ones)
...
}
}
Scope() op does not actually create a new object, it refers to an
existing object(\_SB.PCI0.GFX0.DD02 in above example). However, for
Scope(), we want to indeed open a new scope, so the child nodes(CUBL in
above example) can be created correctly under it.
https://bugzilla.kernel.org/show_bug.cgi?id=19462
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrej Ota [Sun, 12 Dec 2010 23:06:16 +0000 (15:06 -0800)]
pppoe.c: Fix kernel panic caused by __pppoe_xmit
[ Upstream commit
2a27a03d3a891e87ca33d27a858b4db734a4cbab ]
__pppoe_xmit function return value was invalid resulting in
additional call to kfree_skb on already freed skb. This resulted in
memory corruption and consequent kernel panic after PPPoE peer
terminated the link.
This fixes commit
55c95e738da85373965cb03b4f975d0fd559865b.
Reported-by: Gorik Van Steenberge <gvs@zemos.net>
Reported-by: Daniel Kenzelmann <kernel.bugzilla@kenzelmann.dyndns.info>
Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Reported-by: Pawel Staszewski <pstaszewski@artcom.pl>
Diagnosed-by: Andrej Ota <andrej@ota.si>
Diagnosed-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Tested-by: Pawel Staszewski <pstaszewski@artcom.pl>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Signed-off-by: Andrej Ota <andrej@ota.si>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vasiliy Kulikov [Wed, 10 Nov 2010 20:09:10 +0000 (12:09 -0800)]
net: packet: fix information leak to userland
[ Upstream commit
67286640f638f5ad41a946b9a3dc75327950248f ]
packet_getname_spkt() doesn't initialize all members of sa_data field of
sockaddr struct if strlen(dev->name) < 13. This structure is then copied
to userland. It leads to leaking of contents of kernel stack memory.
We have to fully fill sa_data with strncpy() instead of strlcpy().
The same with packet_getname(): it doesn't initialize sll_pkttype field of
sockaddr_ll. Set it to zero.
Signed-off-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eric Dumazet [Sun, 5 Dec 2010 18:50:32 +0000 (18:50 +0000)]
net: fix skb_defer_rx_timestamp()
[ Upstream commit
a19faf0250e09b16cac169354126404bc8aa342b ]
After commit
c1f19b51d1d8 (net: support time stamping in phy devices.),
kernel might crash if CONFIG_NETWORK_PHY_TIMESTAMPING=y and
skb_defer_rx_timestamp() handles a packet without an ethernet header.
Fixes kernel bugzilla #24102
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=24102
Reported-and-tested-by: Andrew Watts <akwatts@ymail.com>
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>