Unfortunately this update became bigger than previous pull requests,
which is almost a pattern in rc5-6. But, the only obvious big changes
are for the new Intel DSP ASoC drivers, so the impact must be fairly
limited.
Other than that, usual small fixes in various fields: HD-audio, ASoC
core and ASoC fsl and codec drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTdPwHAAoJEGwxgFQ9KSmk2MoQAI91MJeGAS3nZczw+TnHHBg7
tk/0r85Kdwem2M9tywZVM78q7vECpB7UV8nZXAIHKcc1fpEjzHu3WJnR5zyqrEDO
4o+9gx9gdwUa7Tv+L8n0A7xSAdIPCrqEL5/776YuUUR/MqJsjemP5bbudzd4ffL7
asLEcJWf0HMHePEajyuay21OWtCRABLLGjgVd0QOFce2B8yBmUswHy0XPYV6+39A
j+G7/gNK1MMF+gmPMy5XV89C+5V1V9wZ68cJuBKJKODJ6SDnRZGaRt84W/lL15Ag
NtzFIT9Sd/qwiOwTtx6qNGmoyxrDfpNQ1Beqd1Mr9kJTowOziRqbZSyNYkKJKkHy
FvRuZkRyDPlmsYnBCxQqaKFhMcWu0n6urssU6y2rCWi0HrBsB4i/ttSfFRHwdASt
jGj/YU2bCc3B2SeZy+xlKW++KsPS829F4cFGD/kx7PsegGetmAp1S1jJJGXPIno4
jHnVKISWUGGxrPkL+6QxOBFPqtErx0/k/Scb8PwlugkAqQnN2w8Ds5vQ02cs/gOC
kPdo5c4mnWLLF7YEwdyd2+u2dlqGoIIAJM0i4qiNRPccAjxrfd6Ao78BoGzvktjg
nmzKsHJO/GF3BTf2o73Evr1jtdxmU+9gL8DKsYgFyBOrr511ieetswgIWbZBej+0
UDDaGufcAX9qDoLktzsC
=h7mJ
-----END PGP SIGNATURE-----
Merge tag 'sound-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Unfortunately this update became bigger than previous pull requests,
which is almost a pattern in rc5-6. But, the only obvious big changes
are for the new Intel DSP ASoC drivers, so the impact must be fairly
limited.
Other than that, usual small fixes in various fields: HD-audio, ASoC
core and ASoC fsl and codec drivers"
* tag 'sound-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
ALSA: sb_mixer: missing return statement
ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile
ASoC: Intel: Fix Baytrail SST DSP firmware loading
ALSA: hda - mask buggy stream DMA0 for Broadwell display controller
ALSA: hda - Add new GPU codec ID to snd-hda
ASoC: fsl_esai: Set PCRC and PRRC registers at the end of hw_params()
ASoC: fsl_esai: Only bypass sck_div for EXTAL source
ASoC: fsl_esai: Fix incorrect condition within ratio range check for FP
ASoC: dapm: Fix SUSPEND -> OFF bias sequence
ASoC: dapm: Skip CODEC<->CODEC links in connect_dai_link_widgets()
ASoC: pcm: Fix incorrect condition check for case SNDRV_PCM_TRIGGER_SUSPEND
ALSA: hda - add headset mic detect quirks for three Dell laptops
ASoC: Update Cirrus Logic CODEC maintainers.
ASoC: Intel: Fix block offset calculations.
ASoC: Intel: Fix check for pdata usage before dereference.
ASoC: Intel: Fix stream position pointer.
ASoC: Intel: Fix allow hw_params to be called more than once.
ASoC: Intel: Fix Audio DSP usage when IOMMU is enabled.
ASoC: Intel: Fix Haswell/Broadwell DSP page table creation.
ASoC: Intel: Fix allocated block list usage when adding blocks.
...
Pull MIPS fixes from Ralf Baechle:
"MIPS fixes for various loose ends:
- Fix workarounds for R4000 erratum.
- Patch up DEC, Siemens-Nixdorf and Loongson hardware support.
- Wire up renameat2 syscall.
- Delete unused file - it was causing false warnings from maintenance
scripts.
- Revert a patch because it's functionality is now implemented twice
which causes superfluous /proc/cpuinfo output.
- Fix a microMIPS regression"
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: mm: Fix broken microMIPS kernel regression.
MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64
MIPS: Wire up renameat2 syscall.
MIPS: inst.h: Rename BITFIELD_FIELD to __BITFIELD_FIELD.
MIPS: Remove file missed when removing rm9k support a while ago.
MIPS/loongson2_cpufreq: Fix CPU clock rate setting
MIPS: Loongson: No need to select GENERIC_HARDIRQS_NO__DO_IRQ
MIPS: csum_partial.S CPU_DADDI_WORKAROUNDS bug fix
MIPS: __strncpy_from_user_asm CPU_DADDI_WORKAROUNDS bug fix
MIPS: __delay CPU_DADDI_WORKAROUNDS bug fix
MIPS: DEC/SNI: O32 wrapper stack switching fixes
MIPS: DEC: Bus error handler <asm/cpu-type.h> fixes
MAINTAINERS: TURBOchannel: Update entry
Revert "MIPS: MT: proc: Add support for printing VPE and TC ids"
Fixes a LVDS bleed issue on Lenovo W530 that can occur under a
number of circumstances.
Cc: <stable@vger.kernel.org > # v3.9+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pull parisc fixes from Helge Deller:
"There are two patches in here:
The first patch greatly improves latency and corrects the memory
ordering in our light-weight atomic locking syscall.
The second patch ratelimits printing of userspace segfaults in the
same way as it's done on other platforms. This fixes a possible DOS
on parisc since it prevents the syslog to grow too fast. For example,
when the debian acl2 package was built on our debian buildd servers,
this package produced lots of gigabytes in syslog in very short time
and thus filled our harddisks, which then turned the server nearly
completely unaccessible and unresponsive"
* 'parisc-3.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Improve LWS-CAS performance
parisc: ratelimit userspace segfault printing
Support forced affinity setting)
- fix arm64 pud_huge() to return 0 when only 2 levels page tables are
used (__PAGETABLE_PMD_FOLDED defined and pmd_huge already covers block
entries at the first level), otherwise KVM gets confused
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQIcBAABAgAGBQJTdkdgAAoJEGvWsS0AyF7x1iYQALKLvpQm8wWndDyDx3AoFagp
tXdoNCUJhOeoc2VlipwbrHQ0M7ZfHzVS21TceDbC6COmjkItmthPnt0ImpA29831
wtm34+lNH/Bim1GLEhwR2EcEVLpBH8/gDdwy5lE7olupO63ViYUUTZtaacrg5SgD
zlVdo+kp+MzmDoz3FkUrlPkFstbm7GcWe2BYEpOu828Qd4uKHtjd13Ud9MgdJRJi
9TeBh68MjALK3KWhd0HOt0ESJjb5pY6whMv/8stg/cD/o6zrqUapxNNk9tqE0PIy
crOzOatmuvm8PJrkgJPV8Xnk9tToz+/j/djiFD4imaHAodQKk6eSPD0wwx+NTlPs
q7fPAlhYNgpvExXrbF0mqtb8q3er6MRnFp6OHWgwU6a+O8tt4Rkms/s9XuuAM/us
iX3t/oEjHXGe7uhIEQdrnWdVVHAJpz6HCbDQ9GgsZPZAS6D4NSIqSf35f4KjoYsH
FFoNrEqtoJz06wxaI9M9lAzUuQQO3vYUDdi3Xk+SHBjumztRcEh432niOoITZEL8
ickfQa2BHqqQwq9nK1i9SEbH7n1tTKaJAOAtK8c8Rnjzh0ckkODvZbhUsyUuF66Y
+jWgXh2NVTUN/tXMn8tQFYbxNRQR+z6J+kxOyG62knaAjjeUokdVAhRhn+lvcE/F
wFIU9cQOkLCWIAzsW/WS
=Ql27
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull two arm64 fixes from Catalin Marinas:
- arm64 migrate_irqs() fix following commit ffde1de640 (irqchip: Gic:
Support forced affinity setting)
- fix arm64 pud_huge() to return 0 when only 2 levels page tables are
used (__PAGETABLE_PMD_FOLDED defined and pmd_huge already covers
block entries at the first level), otherwise KVM gets confused
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: fix pud_huge() for 2-level pagetables
arm64: use cpu_online_mask when using forced irq_set_affinity
Mostly fixes for metag and parisc relating to upgrowing stacks.
* Fix missing compiler barriers in metag memory barriers.
* Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased beyond
safe value.
* Make maximum stack size configurable. This reduces the default user
stack size back to 80MB (especially on parisc after their removal of
_STK_LIM_MAX override). This only affects metag and parisc.
* Remove metag _STK_LIM_MAX override to match other arches and follow
parisc, now that it is safe to do so (due to the BUG_ON fix mentioned
above).
* Finally now that both metag and parisc _STK_LIM_MAX overrides have
been removed, it makes sense to remove _STK_LIM_MAX altogether.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTdAc3AAoJEGwLaZPeOHZ6L2QP/ihJag44CyWKKpeu/5FUkjP6
62wX4cYKCFR9pTkOZDViWs7c+xrmW6OtORfQKuXu1g68L3v2cwb0HmcvybQ75pIQ
CbaN+d5OnGPjHGYCSVqQBKlJ0qbcgQfoNUuCVOZx9kZgnCYQhJlh4HYRwHdUv9WY
1FA3wor/JTTAiKvPBv+/t4NzTpTafpSIhYLahjxZbtuU1WjEfmj8QgWQpzTEJSeZ
AyNE/nDlcYcdq4lDxMz2pcQfmJ2MpE56wvXJ7IdXadLaLp4yzc+WTAvFzNJ1XnAN
2IcyNBpgF/vMXCbErA9QQegYwKd9jpF0w3oQmNLkgr27Kv27iL2sLIEWVn3FAXCu
p+I0ypMlkD/gSdofCUaWTiGGOQiKMqAWJMfjky8RjA7Qz5TdLCldpjjuZEMKl8hM
SLjkmgZHMG2/rJ8MosOL+ARAXl88v25gfM6rNIPTtMzH72qevrHgjFPj6pWHejhE
0E43yDS+zt215HrFCXYBhVbFY1NM7JeBS8NFd9Y/8LKTWc8QSi2h8Q1ZaobKJi4O
0zlKxRRR4QmmtF7S5wL/qOQ0U95HBvYSx+Ssp3C0eh/PEkZYWm0jiXtaKBCYtnDx
33wRutv+R9sSkKaiiURBh9/VPWFLQ1ak5z+ejqrv32+oBzt/zmxb7LgwsxdAbAms
9r/8XaY3V+JBPw7UxfQN
=aveq
-----END PGP SIGNATURE-----
Merge tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag
Pull Metag architecture and related fixes from James Hogan:
"Mostly fixes for metag and parisc relating to upgrowing stacks.
- Fix missing compiler barriers in metag memory barriers.
- Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased
beyond safe value.
- Make maximum stack size configurable. This reduces the default
user stack size back to 80MB (especially on parisc after their
removal of _STK_LIM_MAX override). This only affects metag and
parisc.
- Remove metag _STK_LIM_MAX override to match other arches and follow
parisc, now that it is safe to do so (due to the BUG_ON fix
mentioned above).
- Finally now that both metag and parisc _STK_LIM_MAX overrides have
been removed, it makes sense to remove _STK_LIM_MAX altogether"
* tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
asm-generic: remove _STK_LIM_MAX
metag: Remove _STK_LIM_MAX override
parisc,metag: Do not hardcode maximum userspace stack size
metag: Reduce maximum stack size to 256MB
metag: fix memory barriers
Pull drm/intel fixes from Dave Airlie:
"Just some intel fixes.
I have some radeon ones but I need to get some patches dropped from
the pull req"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Increase WM memory latency values on SNB
drm/i915: restore backlight precision when converting from ACPI
drm/i915: Use the first mode if there is no preferred mode in the EDID
drm/i915/dp: force eDP lane count to max available lanes on BDW
drm/i915/vlv: reset VLV media force wake request register
drm/i915/SDVO: For sysfs link put directory and target in correct order
drm/i915: use lane count and link rate from VBT as minimums for eDP
drm/i915: clean up VBT eDP link param decoding
drm/i915: consider the source max DP lane count too
Pull x86 fixes from Peter Anvin.
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86-64, modify_ldt: Make support for 16-bit segments a runtime option
x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
x86, rdrand: When nordrand is specified, disable RDSEED as well
Pull timer fix from Thomas Gleixner:
"A single bug fix for a long standing issue:
- Updating the expiry value of a relative timer _after_ letting the
idle logic select a target cpu for the timer based on its stale
expiry value is outright stupid. Thanks to Viresh for spotting the
brainfart"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
hrtimer: Set expiry time before switch_hrtimer_base()
Pull irq fixes from Thomas Gleixner:
"Two small updates from the irq departement:
- Provide missing inline stub for a SMP only function
- Add sub-maintainer for the drivers/irqchip/ part of the irq
subsystem. YAY!"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
MAINTAINERS: Add co-maintainer for drivers/irqchip
genirq: Provide irq_force_affinity fallback for non-SMP
13c589d5b0 ("sysfs: use seq_file when reading regular files")
switched sysfs from custom read implementation to seq_file to enable
later transition to kernfs. After the change, the buffer passed to
->show() is acquired through seq_get_buf(); unfortunately, this
introduces a subtle behavior change. Before the commit, the buffer
passed to ->show() was always zero as it was allocated using
get_zeroed_page(). Because seq_file doesn't clear buffers on
allocation and neither does seq_get_buf(), after the commit, depending
on the behavior of ->show(), we may end up exposing uninitialized data
to userland thus possibly altering userland visible behavior and
leaking information.
Fix it by explicitly clearing the buffer.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Ron <ron@debian.org>
Fixes: 13c589d5b0 ("sysfs: use seq_file when reading regular files")
Cc: stable <stable@vger.kernel.org> # 3.13+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Intel fixes for regressions, black screens and hangs, for 3.15.
* tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Increase WM memory latency values on SNB
drm/i915: restore backlight precision when converting from ACPI
drm/i915: Use the first mode if there is no preferred mode in the EDID
drm/i915/dp: force eDP lane count to max available lanes on BDW
drm/i915/vlv: reset VLV media force wake request register
drm/i915/SDVO: For sysfs link put directory and target in correct order
drm/i915: use lane count and link rate from VBT as minimums for eDP
drm/i915: clean up VBT eDP link param decoding
drm/i915: consider the source max DP lane count too
This driver is using devres managed calls incorrectly, giving the cpu0
device as first parameter instead of the cpufreq platform device.
This results in resources not being freed if the cpufreq platform device
is unbound, for example if probing has to be deferred for a missing
regulator.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.9+ <stable@vger.kernel.org> # 3.9+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The commit e783c51 (ahci: imx: software workaround for phy reset issue
in resume) calls imx_sata_phy_reset() to reset phy immediately after
SATA MPLL is enabled. It seems working fine mostly, but fails in some
case as below.
...
ahci-imx 2200000.sata: failed to reset phy: -110
ahci-imx: probe of 2200000.sata failed with error -110
After talking to the designer, we learnt that when enabling i.MX6Q SATA
MPLL, we need to wait 100us for it to settle down for safety. Add this
required delay to fix above failure.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.
Fixes: cb7094e8 (cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag)
Fixes: ff999b8a (cpuidle: OMAP4: remove timer broadcast initialization)
Cc: stable@vger.kernel.org # v3.9+
Cc: Roger Quadros <rogerq@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-tested-by: Roger Quadros <rogerq@ti.com>
Reported-tested-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
LDO4 regulator was getting disabled preventing the system from
going into low power states. Keep it always on to fix it.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch fixed incorrect compatible for ak8975 magnetic sensor.
ak8975 magnetic sensor use compatible "ak8975" or "asahi-kasei,ak8975"
In this patch, use "asahi-kasei,ak8975" according to dt bindings document.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Alexander noticed that we use RCU iteration on rb->event_list but do
not use list_{add,del}_rcu() to add,remove entries to that list, nor
do we observe proper grace periods when re-using the entries.
Merge ring_buffer_detach() into ring_buffer_attach() such that
attaching to the NULL buffer is detaching.
Furthermore, ensure that between any 'detach' and 'attach' of the same
event we observe the required grace period, but only when strictly
required. In effect this means that only ioctl(.request =
PERF_EVENT_IOC_SET_OUTPUT) will wait for a grace period, while the
normal initial attach and final detach will not be delayed.
This patch should, I think, do the right thing under all
circumstances, the 'normal' cases all should never see the extra grace
period, but the two cases:
1) PERF_EVENT_IOC_SET_OUTPUT on an event which already has a
ring_buffer set, will now observe the required grace period between
removing itself from the old and attaching itself to the new buffer.
This case is 'simple' in that both buffers are present in
perf_event_set_output() one could think an unconditional
synchronize_rcu() would be sufficient; however...
2) an event that has a buffer attached, the buffer is destroyed
(munmap) and then the event is attached to a new/different buffer
using PERF_EVENT_IOC_SET_OUTPUT.
This case is more complex because the buffer destruction does:
ring_buffer_attach(.rb = NULL)
followed by the ioctl() doing:
ring_buffer_attach(.rb = foo);
and we still need to observe the grace period between these two
calls due to us reusing the event->rb_entry list_head.
In order to make 2 happen we use Paul's latest cond_synchronize_rcu()
call.
Cc: Paul Mackerras <paulus@samba.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140507123526.GD13658@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The perf cpu offline callback takes down all cpu context
events and releases swhash->swevent_hlist.
This could race with task context software event being just
scheduled on this cpu via perf_swevent_add while cpu hotplug
code already cleaned up event's data.
The race happens in the gap between the cpu notifier code
and the cpu being actually taken down. Note that only cpu
ctx events are terminated in the perf cpu hotplug code.
It's easily reproduced with:
$ perf record -e faults perf bench sched pipe
while putting one of the cpus offline:
# echo 0 > /sys/devices/system/cpu/cpu1/online
Console emits following warning:
WARNING: CPU: 1 PID: 2845 at kernel/events/core.c:5672 perf_swevent_add+0x18d/0x1a0()
Modules linked in:
CPU: 1 PID: 2845 Comm: sched-pipe Tainted: G W 3.14.0+ #256
Hardware name: Intel Corporation Montevina platform/To be filled by O.E.M., BIOS AMVACRB1.86C.0066.B00.0805070703 05/07/2008
0000000000000009 ffff880077233ab8 ffffffff81665a23 0000000000200005
0000000000000000 ffff880077233af8 ffffffff8104732c 0000000000000046
ffff88007467c800 0000000000000002 ffff88007a9cf2a0 0000000000000001
Call Trace:
[<ffffffff81665a23>] dump_stack+0x4f/0x7c
[<ffffffff8104732c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff8104737a>] warn_slowpath_null+0x1a/0x20
[<ffffffff8110fb3d>] perf_swevent_add+0x18d/0x1a0
[<ffffffff811162ae>] event_sched_in.isra.75+0x9e/0x1f0
[<ffffffff8111646a>] group_sched_in+0x6a/0x1f0
[<ffffffff81083dd5>] ? sched_clock_local+0x25/0xa0
[<ffffffff811167e6>] ctx_sched_in+0x1f6/0x450
[<ffffffff8111757b>] perf_event_sched_in+0x6b/0xa0
[<ffffffff81117a4b>] perf_event_context_sched_in+0x7b/0xc0
[<ffffffff81117ece>] __perf_event_task_sched_in+0x43e/0x460
[<ffffffff81096f1e>] ? put_lock_stats.isra.18+0xe/0x30
[<ffffffff8107b3c8>] finish_task_switch+0xb8/0x100
[<ffffffff8166a7de>] __schedule+0x30e/0xad0
[<ffffffff81172dd2>] ? pipe_read+0x3e2/0x560
[<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
[<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
[<ffffffff8166b464>] preempt_schedule_irq+0x44/0x70
[<ffffffff816707f0>] retint_kernel+0x20/0x30
[<ffffffff8109e60a>] ? lockdep_sys_exit+0x1a/0x90
[<ffffffff812a4234>] lockdep_sys_exit_thunk+0x35/0x67
[<ffffffff81679321>] ? sysret_check+0x5/0x56
Fixing this by tracking the cpu hotplug state and displaying
the WARN only if current cpu is initialized properly.
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: stable@vger.kernel.org
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1396861448-10097-1-git-send-email-jolsa@redhat.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Vince reported that using a large sample_period (one with bit 63 set)
results in wreckage since while the sample_period is fundamentally
unsigned (negative periods don't make sense) the way we implement
things very much rely on signed logic.
So limit sample_period to 63 bits to avoid tripping over this.
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/n/tip-p25fhunibl4y3qi0zuqmyf4b@git.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.
Found while analysing the fallout of Dave Jones syscall fuzzer.
We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.194824402@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:
http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com
That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
- it can detect that issue early
- it avoids a different and more complex fixup for backing out
If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.
The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <darren@dvhart.com>
Cc: Davidlohr Bueso <davidlohr@hp.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Clark Williams <williams@redhat.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Carlos ODonell <carlos@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Currently snd_dmaengine_pcm_trigger() calls dmaengine_pause()
unconditinally during device suspend. In case where DMA controller
doesn't support PAUSE/RESUME functionality, this call is not able
to stop the DMA controller. In this scenario, audio playback doesn't
resume after device resume.
Calling dmaengine_pause/dmaengine_terminate_all conditionally fixes
the issue.
It has been tested with audio playback on Samsung platform having
PL330 DMA controller which doesn't support PAUSE/RESUME.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In 2b9aecdce2 ("can: c_can: Disable rx split as workaround") a new Kconfig
option was introduced as a workaround. The tests performed by Alexander Stein
confirmed this option to be obsolete with all the other cleanups and fixes
that had been discussed that time:
http://marc.info/?l=linux-can&m=139746476821294&w=2
Both (author and tester) agreed to remove this Kconfig option again:
http://marc.info/?l=linux-can&m=139883820714229&w=2
As some more cleanups took place since then a simple revert is not possible.
This patch removes the entire option as it would behave when disabled.
Further beautification’s can be done later.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Pravin will be maintaining Open vSwitch going forward.
CC: Pravin Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
These "return 0;" uses seem wrong as there are
rc variables where error return values are set
but unused.
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Dmitry Kravkov <Dmitry.Kravkov@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On each processed XCOPY command, two "kmalloc-512" memory objects are
leaked. These represent two allocations of struct xcopy_pt_cmd in
target_core_xcopy.c.
The reason for the memory leak is that the cmd_kref field is not
initialized (thus, it is zero because the allocations were done with
kzalloc). When we decrement zero kref in target_put_sess_cmd, the result
is not zero, thus target_release_cmd_kref is not called.
This patch fixes the bug by moving kref initialization from
target_get_sess_cmd to transport_init_se_cmd (this function is called from
target_core_xcopy.c, so it will correctly initialize cmd_kref). It can be
easily verified that all code that calls target_get_sess_cmd also calls
transport_init_se_cmd earlier, thus moving kref_init shouldn't introduce
any new problems.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org # 3.12+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
This is the prevent previous stores from overlapping the block stores
done by the memcpy loop.
Based upon a glibc patch by Jose E. Marchesi
Signed-off-by: David S. Miller <davem@davemloft.net>
Vlad Yasevich says:
====================
Fixed stacked vlan usage on top of bonds
Bonding device driver now support q-in-q on top for bonds. There are
a few issues here though.
First, when arp monitoring is used, bonding driver will not correctly
tag traffic if the source of the arp device was configured on top of
q-in-q. It may also incorrectly pick the wrong vlan id if the ordering
of that upper devices isn't as expected (there is no guarntee on ordering).
Second, the alb/tlb may use what would be considered 'inner' vlans in
its learning announcements, as it simply announces all vlans configured
on top of the bond without regard for encapsulation/stacking.
This series fixes the above 2 issues. This series also depends on the
functionality introduced in
http://patchwork.ozlabs.org/patch/349766/
Since v1:
- Changed how patch1 verifies the device path. We no longer use the
_all_upper version of the function. We find the path and if it was
found, then collect the vlan information.
- Use the constant to devine maximum vlan nest level support on top
of bonding. This can be changed if 2 is too low.
- Inlude patch2 into the series.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
ALB/TLB learning packets use all vlans configured on top
of the bond. This ends up being incorrect if we have a stack
of vlans on top of the bond. ALB/TLB should only use
first level/outer most vlans in its announcements.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Prior to commit fbd929f2dc
bonding: support QinQ for bond arp interval
the arp monitoring code allowed for proper detection of devices
stacked on top of vlans. Since the above commit, the
code can still detect a device stacked on top of single
vlan, but not a device stacked on top of Q-in-Q configuration.
The search will only set the inner vlan tag if the route
device is the vlan device. However, this is not always the
case, as it is possible to extend the stacked configuration.
With this patch it is possible to provision devices on
top Q-in-Q vlan configuration that should be used as
a source of ARP monitoring information.
For example:
ip link add link bond0 vlan10 type vlan proto 802.1q id 10
ip link add link vlan10 vlan100 type vlan proto 802.1q id 100
ip link add link vlan100 type macvlan
Note: This patch limites the number of stacked VLANs to 2,
just like before. The original, however had another issue
in that if we had more then 2 levels of VLANs, we would end
up generating incorrectly tagged traffic. This is no longer
possible.
Fixes: fbd929f2dc (bonding: support QinQ for bond arp interval)
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@redhat.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Ding Tianhong <dingtianhong@huawei.com>
CC: Patric McHardy <kaber@trash.net>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit ee1de406ba ("random: simplify accounting logic") simplified
things too much, in that it allows the following to trigger an
overflow that results in a BUG_ON crash:
dd if=/dev/urandom of=/dev/zero bs=67108707 count=1
Thanks to Peter Zihlstra for discovering the crash, and Hannes
Frederic for analyizing the root cause.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Greg Price <price@mit.edu>
Vlad Yasevich says:
====================
Fix lockdep issues with stacked devices
Recent commit dc8eaaa006
vlan: Fix lockdep warning when vlan dev handle notification
attempted to solve lockdep issues with vlans where multiple
vlans were stacked. However, the code does not work correctly
when the vlan stack is interspersed with other devices in between
the vlans. Additionally, similar lockdep issues show up with other
devices.
This series provides a generic way to solve these issue for any
devices that can be stacked. It also addresses the concern for
vlan and macvlan devices. I am not sure whether it makes sense
to do so for other types like team, vxlan, and bond.
Thanks
-vlad
Since v2:
- Remove rcu variants from patch1, since that function is called
only under rtnl.
- Fix whitespace problems reported by checkpatch
Since v1:
- Fixed up a goofed-up rebase.
* is_vlan_dev() should be bool and that change belongs in patch3.
* patch4 should not have any vlan changes in it.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit dc8eaaa006.
vlan: Fix lockdep warning when vlan dev handle notification
Instead we use the new new API to find the lock subclass of
our vlan device. This way we can support configurations where
vlans are interspersed with other devices:
bond -> vlan -> macvlan -> vlan
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently netif_addr_lock_nested assumes that there can be only
a single nesting level between 2 devices. However, if we
have multiple devices of the same type stacked, this fails.
For example:
eth0 <-- vlan0.10 <-- vlan0.10.20
A more complicated configuration may stack more then one type of
device in different order.
Ex:
eth0 <-- vlan0.10 <-- macvlan0 <-- vlan1.10.20 <-- macvlan1
This patch adds an ndo_* function that allows each stackable
device to report its nesting level. If the device doesn't
provide this function default subclass of 1 is used.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Multiple devices in the kernel can be stacked/nested and they
need to know their nesting level for the purposes of lockdep.
This patch provides a generic function that determines a nesting
level of a particular device by its type (ex: vlan, macvlan, etc).
We only care about nesting of the same type of devices.
For example:
eth0 <- vlan0.10 <- macvlan0 <- vlan1.20
The nesting level of vlan1.20 would be 1, since there is another vlan
in the stack under it.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The value written to PLLE_AUX was incorrect due to a wrong variable
being used. Without this fix SATA does not work.
Cc: stable@vger.kernel.org
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Tested-by: Mikko Perttunen <mperttunen@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
[mturquette@linaro.org: improved changelog]
wdev->ifdev should be set by .change_virtual_intf(). This solves the
problem of WARN() messages on module unload.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 6ddeb6d844 (dmaengine: omap-dma: move IRQ handling to omap-dma)
added support for handling interrupts in the omap dmaengine driver
instead of the legacy driver. Because of different handling for
interrupts this however caused omap3 to hang eventually after hitting
off-idle.
Any of the virtual 32 DMA channels can be assigned to any of the
four DMA interrupts. So commit 6ddeb6d844 made the omap dmaengine
driver to use the second DMA interrupt while keeping the legacy code
still using the first DMA interrupt.
This means we need to save and restore both IRQENABLE_L1 in addition
to IRQENABLE_L0. As there is a chance that the DSP might be using
IRQENABLE_L2 or IRQENABLE_L3 lines, let's not touch those until
this has been confirmed. Let's just add a comment to the code for
now.
Fixes: 6ddeb6d844 (dmaengine: omap-dma: move IRQ handling to omap-dma)
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit c66d039197 broke NAND for non-DT boot on all OMAP2 and OMAP3
boards using board_nand_init(). Following error is seen at boot
[ 0.154998] (null): Unsupported NAND ECC scheme selected
For OMAP2 and OMAP3 platforms, the ecc_opt parameter in platform data
must be set to OMAP_ECC_HAM1_CODE_HW to work properly.
Tested on omap3-beagle c4.
Fixes: c66d039197 (mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes)
Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
"choppy" audio playback on OMAP5. The other applies an OMAP3630 fix
for clock rate setting for camera to other OMAP3 chips.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/prcm-fixes-b-v3.15-rc/20140514112639/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTc7lbAAoJEMePsQ0LvSpLe/IP+wVAsIwl4GNiNdydGYLNlie5
cqhVnfP3ZzRGgBtnEmE6OVWg6bMBKOnrutVIj2PqK/rHmA+QU4oy6bkd+k3nlYWy
rP+Fs6/rtlUVoo5DyDvDb0+7/E9OLprAsBGj0Yich+4MPZPx6MulvdvnT9DBN5LM
lpMmyjOnqztLRrKBrWec3ECla9FMLgi5yQeO0mX662Ry+8Ny5uQZbgmQv9l7ChRS
/r8tSCWsTh1vOjDSynOT2DLcQ3kAeDAva/mh3tXjIVD9u0wwyflNbh6kZLMQ9qLv
TCgqXnmPw47in8rDn8V3JfJJrzRMUYk2ba2c9UnNXXFBdJv34OOG/m0mJalmPFEf
5Hxyb73O14Eo4FfLoW8GpkHooYZZCWJ6HZ26poiT1IqZUSrbMsiNRM90A/8gRRYh
zsUM6yuSnV/Y+4clbfQWM5EtUVT7Y4Vnisa6b3mOdVdQdfwnCDOCI/aDjvkTsp8f
SeUlDak8sAAtqYin6dwGsGUENfmYlb7qN8vf51qIWSWWXcvUk2lvSei/m6JiIM3X
xlWyU8RYNnzdGtQG9k79YCe91bE1RxtSefRsjeTj63a0UjUxTrYhYKCTMAI2ZlYR
DnTWa/uvof3MLkkqumQf7cSQEZzCYjOqtoFwjNgmGAEVSKyxeho/N22B21NG8t16
l8lreOPEiigH3GOQ0jlV
=zDIG
-----END PGP SIGNATURE-----
Merge tag 'for-v3.15-rc/omap-fixes-b' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.15/fixes-v3
Two small OMAP fixes for v3.15-rc. One fixes "slow motion" or
"choppy" audio playback on OMAP5. The other applies an OMAP3630 fix
for clock rate setting for camera to other OMAP3 chips.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/prcm-fixes-b-v3.15-rc/20140514112639/
Starting from linux-3.13, GRO attempts to build full size skbs.
Problem is the commit assumed one particular field in skb->cb[]
was clean, but it is not the case on some stacked devices.
Timo reported a crash in case traffic is decrypted before
reaching a GRE device.
Fix this by initializing NAPI_GRO_CB(skb)->last at the right place,
this also removes one conditional.
Thanks a lot to Timo for providing full reports and bisecting this.
Fixes: 8a29111c7c ("net: gro: allow to build full sized skb")
Bisected-by: Timo Teras <timo.teras@iki.fi>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
The connected check fails to check for ip_gre nbma mode tunnels
properly. ip_gre creates temporary tnl_params with daddr specified
to pass-in the actual target on per-packet basis from neighbor
layer. Detect these tunnels by inspecting the actual tunnel
configuration.
Minimal test case:
ip route add 192.168.1.1/32 via 10.0.0.1
ip route add 192.168.1.2/32 via 10.0.0.2
ip tunnel add nbma0 mode gre key 1 tos c0
ip addr add 172.17.0.0/16 dev nbma0
ip link set nbma0 up
ip neigh add 172.17.0.1 lladdr 192.168.1.1 dev nbma0
ip neigh add 172.17.0.2 lladdr 192.168.1.2 dev nbma0
ping 172.17.0.1
ping 172.17.0.2
The second ping should be going to 192.168.1.2 and head 10.0.0.2;
but cached gre tunnel level route is used and it's actually going
to 192.168.1.1 via 10.0.0.1.
The lladdr's need to go to separate dst for the bug to trigger.
Test case uses separate route entries, but this can also happen
when the route entry is same: if there is a nexthop exception or
the GRE tunnel is IPsec'ed in which case the dst points to xfrm
bundle unique to the gre lladdr.
Fixes: 7d442fab0a ("ipv4: Cache dst in tunnels")
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Cc: Tom Herbert <therbert@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
