aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-05-20ia64: add renameat2 syscallMiklos Szeredi3-1/+3
Signed-off-by: Miklos Szeredi <[email protected]> Acked-by: Tony Luck <[email protected]>
2014-05-20parisc: add renameat2 syscallMiklos Szeredi2-1/+3
Signed-off-by: Miklos Szeredi <[email protected]> Acked-by: Helge Deller <[email protected]>
2014-05-20m68k: add renameat2 syscallMiklos Szeredi3-1/+3
Signed-off-by: Miklos Szeredi <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]>
2014-05-20Merge tag 'sound-3.15-rc6' of ↵Linus Torvalds24-92/+190
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. ...
2014-05-20Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds26-423/+327
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"
2014-05-20drm/gf119-/disp: fix nasty bug which can clobber SOR0's clock setupBen Skeggs1-1/+1
Fixes a LVDS bleed issue on Lenovo W530 that can occur under a number of circumstances. Cc: <[email protected] > # v3.9+ Signed-off-by: Ben Skeggs <[email protected]>
2014-05-20drm/nvd9/therm: handle another kind of PWM fanMartin Peres1-0/+1
Signed-off-by: Martin Peres <[email protected]> Tested-by: SaveTheRobots <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2014-05-20Merge branch 'parisc-3.15-4' of ↵Linus Torvalds4-46/+65
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux 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
2014-05-20Merge tag 'arm64-fixes' of ↵Linus Torvalds2-3/+11
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull two arm64 fixes from Catalin Marinas: - arm64 migrate_irqs() fix following commit ffde1de64012 (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
2014-05-20Merge tag 'metag-for-v3.15-2' of ↵Linus Torvalds10-22/+33
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
2014-05-20Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds7-29/+141
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
2014-05-20Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds5-5/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 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
2014-05-20Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 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()
2014-05-20Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds2-0/+13
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 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
2014-05-20sysfs: make sure read buffer is zeroedTejun Heo1-1/+2
13c589d5b0ac ("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 <[email protected]> Reported-by: Ron <[email protected]> Fixes: 13c589d5b0ac ("sysfs: use seq_file when reading regular files") Cc: stable <[email protected]> # 3.13+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-05-20Merge tag 'drm-intel-fixes-2014-05-16' of ↵Dave Airlie7-29/+141
git://anongit.freedesktop.org/drm-intel into drm-fixes 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
2014-05-20cpufreq: cpu0: drop wrong devm usageLucas Stach1-5/+11
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 <[email protected]> Acked-by: Viresh Kumar <[email protected]> Cc: 3.9+ <[email protected]> # 3.9+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-05-20cpufreq: remove race while accessing cur_policyBibek Basu1-0/+6
While accessing cur_policy during executing events CPUFREQ_GOV_START, CPUFREQ_GOV_STOP, CPUFREQ_GOV_LIMITS, same mutex lock is not taken, dbs_data->mutex, which leads to race and data corruption while running continious suspend resume test. This is seen with ondemand governor with suspend resume test using rtcwake. Unable to handle kernel NULL pointer dereference at virtual address 00000028 pgd = ed610000 [00000028] *pgd=adf11831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: nvhost_vi CPU: 1 PID: 3243 Comm: rtcwake Not tainted 3.10.24-gf5cf9e5 #1 task: ee708040 ti: ed61c000 task.ti: ed61c000 PC is at cpufreq_governor_dbs+0x400/0x634 LR is at cpufreq_governor_dbs+0x3f8/0x634 pc : [<c05652b8>] lr : [<c05652b0>] psr: 600f0013 sp : ed61dcb0 ip : 000493e0 fp : c1cc14f0 r10: 00000000 r9 : 00000000 r8 : 00000000 r7 : eb725280 r6 : c1cc1560 r5 : eb575200 r4 : ebad7740 r3 : ee708040 r2 : ed61dca8 r1 : 001ebd24 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: ad61006a DAC: 00000015 [<c05652b8>] (cpufreq_governor_dbs+0x400/0x634) from [<c055f700>] (__cpufreq_governor+0x98/0x1b4) [<c055f700>] (__cpufreq_governor+0x98/0x1b4) from [<c0560770>] (__cpufreq_set_policy+0x250/0x320) [<c0560770>] (__cpufreq_set_policy+0x250/0x320) from [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) [<c0561dcc>] (cpufreq_update_policy+0xcc/0x168) from [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) [<c0561ed0>] (cpu_freq_notify+0x68/0xdc) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c) [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) [<c00aac6c>] (pm_qos_update_bounded_target+0xd8/0x310) from [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) [<c00ab3b0>] (__pm_qos_update_request+0x64/0x70) from [<c004b4b8>] (tegra_pm_notify+0x114/0x134) [<c004b4b8>] (tegra_pm_notify+0x114/0x134) from [<c008eff8>] (notifier_call_chain+0x4c/0x8c) [<c008eff8>] (notifier_call_chain+0x4c/0x8c) from [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) [<c008f3d4>] (__blocking_notifier_call_chain+0x50/0x68) from [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) [<c008f40c>] (blocking_notifier_call_chain+0x20/0x28) from [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) [<c00ac228>] (pm_notifier_call_chain+0x1c/0x34) from [<c00ad38c>] (enter_state+0xec/0x128) [<c00ad38c>] (enter_state+0xec/0x128) from [<c00ad400>] (pm_suspend+0x38/0xa4) [<c00ad400>] (pm_suspend+0x38/0xa4) from [<c00ac114>] (state_store+0x70/0xc0) [<c00ac114>] (state_store+0x70/0xc0) from [<c027b1e8>] (kobj_attr_store+0x14/0x20) [<c027b1e8>] (kobj_attr_store+0x14/0x20) from [<c019cd9c>] (sysfs_write_file+0x104/0x184) [<c019cd9c>] (sysfs_write_file+0x104/0x184) from [<c0143038>] (vfs_write+0xd0/0x19c) [<c0143038>] (vfs_write+0xd0/0x19c) from [<c0143414>] (SyS_write+0x4c/0x78) [<c0143414>] (SyS_write+0x4c/0x78) from [<c000f080>] (ret_fast_syscall+0x0/0x30) Code: e1a00006 eb084346 e59b0020 e5951024 (e5903028) ---[ end trace 0488523c8f6b0f9d ]--- Signed-off-by: Bibek Basu <[email protected]> Acked-by: Viresh Kumar <[email protected]> Cc: 3.11+ <[email protected]> # 3.11+ Signed-off-by: Rafael J. Wysocki <[email protected]>
2014-05-19ahci: imx: PLL clock needs 100us to settle downShawn Guo1-0/+2
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 <[email protected]> Tested-by: Fabio Estevam <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2014-05-19PCI: Wrong register used to check pending trafficGavin Shan1-2/+3
The incorrect register offset is passed to pci_wait_for_pending(), which is caused by commit 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction())"). Fixes: 157e876ffe ("PCI: Add pci_wait_for_pending() (refactor pci_wait_for_pending_transaction()) Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Williamson <[email protected]> CC: [email protected] # v3.14+
2014-05-19ARM: OMAP4: Fix the boot regression with CPU_IDLE enabledSantosh Shilimkar1-4/+21
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: [email protected] # v3.9+ Cc: Roger Quadros <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: Tony Lindgren <[email protected]> Cc: Daniel Lezcano <[email protected]> Reported-tested-by: Roger Quadros <[email protected]> Reported-tested-by: Kevin Hilman <[email protected]> Tested-by: Tony Lindgren <[email protected]> Signed-off-by: Santosh Shilimkar <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2014-05-20ARM: dts: Keep LDO4 always ON for exynos5250-arndale boardSachin Kamat1-0/+1
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 <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-20ARM: dts: Fix SPI interrupt numbers for exynos5420Sachin Kamat1-3/+3
Updated as per the user manual. Signed-off-by: Sachin Kamat <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-20ARM: dts: fix incorrect ak8975 compatible for exynos4412-trats2 boardBeomho Seo1-1/+1
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 <[email protected]> Signed-off-by: MyungJoo Ham <[email protected]> Reviewed-by: Tomasz Figa <[email protected]> Signed-off-by: Kukjin Kim <[email protected]>
2014-05-19perf: Fix a race between ring_buffer_detach() and ring_buffer_attach()Peter Zijlstra2-60/+51
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 <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Andi Kleen <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Mike Galbraith <[email protected]> Reported-by: Alexander Shishkin <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-05-19perf: Prevent false warning in perf_swevent_addJiri Olsa1-1/+12
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 <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: [email protected] Reported-by: Fengguang Wu <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-05-19perf: Limit perf_event_attr::sample_period to 63 bitsPeter Zijlstra1-0/+3
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 <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-05-19futex: Prevent attaching to kernel threadsThomas Gleixner1-0/+5
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 <[email protected]> Cc: Dave Jones <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Darren Hart <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Clark Williams <[email protected]> Cc: Paul McKenney <[email protected]> Cc: Lai Jiangshan <[email protected]> Cc: Roland McGrath <[email protected]> Cc: Carlos ODonell <[email protected]> Cc: Jakub Jelinek <[email protected]> Cc: Michael Kerrisk <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected]
2014-05-19futex: Add another early deadlock detection checkThomas Gleixner1-13/+34
Dave Jones trinity syscall fuzzer exposed an issue in the deadlock detection code of rtmutex: http://lkml.kernel.org/r/[email protected] 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 <[email protected]> Cc: Dave Jones <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Darren Hart <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Clark Williams <[email protected]> Cc: Paul McKenney <[email protected]> Cc: Lai Jiangshan <[email protected]> Cc: Roland McGrath <[email protected]> Cc: Carlos ODonell <[email protected]> Cc: Jakub Jelinek <[email protected]> Cc: Michael Kerrisk <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected]
2014-05-19ALSA: pcm_dmaengine: Add check during device suspendTushar Behera1-0/+6
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 <[email protected]> Acked-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-05-19can: c_can: remove obsolete STRICT_FRAME_ORDERING Kconfig optionOliver Hartkopp2-43/+0
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 <[email protected]> Tested-by: Alexander Stein <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2014-05-18MAINTAINERS: Pravin Shelar is Open vSwitch maintainer.Jesse Gross1-2/+2
Pravin will be maintaining Open vSwitch going forward. CC: Pravin Shelar <[email protected]> Signed-off-by: Jesse Gross <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-18bnx2x: Convert return 0 to return rcJoe Perches2-2/+2
These "return 0;" uses seem wrong as there are rc variables where error return values are set but unused. Signed-off-by: Joe Perches <[email protected]> Acked-by: Dmitry Kravkov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-17target: fix memory leak on XCOPYMikulas Patocka1-1/+1
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 <[email protected]> Cc: [email protected] # 3.12+ Signed-off-by: Nicholas Bellinger <[email protected]>
2014-05-17sparc64: Add membar to Niagara2 memcpy code.David S. Miller1-0/+1
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 <[email protected]>
2014-05-16Merge branch 'bond_stacked_vlans'David S. Miller6-70/+108
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 <[email protected]>
2014-05-16bonding: Fix alb mode to only use first level vlans.Vlad Yasevich1-1/+1
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-16bonding: Fix stacked device detection in arp monitoringVlad Yasevich5-69/+107
Prior to commit fbd929f2dce460456807a51e18d623db3db9f077 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: fbd929f2dce460456807a51e18d623db3db9f077 (bonding: support QinQ for bond arp interval) CC: Jay Vosburgh <[email protected]> CC: Veaceslav Falico <[email protected]> CC: Andy Gospodarek <[email protected]> CC: Ding Tianhong <[email protected]> CC: Patric McHardy <[email protected]> Signed-off-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-16random: fix BUG_ON caused by accounting simplificationTheodore Ts'o1-2/+5
Commit ee1de406ba6eb1 ("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" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Reported-by: Hannes Frederic Sowa <[email protected]> Cc: Greg Price <[email protected]>
2014-05-16Merge branch 'stacked_netdevice_locking'David S. Miller7-48/+90
Vlad Yasevich says: ==================== Fix lockdep issues with stacked devices Recent commit dc8eaaa006350d24030502a4521542e74b5cb39f 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 <[email protected]>
2014-05-16macvlan: Fix lockdep warnings with stacked macvlan devicesVlad Yasevich2-2/+11
Macvlan devices try to avoid stacking, but that's not always successfull or even desired. As an example, the following configuration is perefectly legal and valid: eth0 <--- macvlan0 <---- vlan0.10 <--- macvlan1 However, this configuration produces the following lockdep trace: [ 115.620418] ====================================================== [ 115.620477] [ INFO: possible circular locking dependency detected ] [ 115.620516] 3.15.0-rc1+ #24 Not tainted [ 115.620540] ------------------------------------------------------- [ 115.620577] ip/1704 is trying to acquire lock: [ 115.620604] (&vlan_netdev_addr_lock_key/1){+.....}, at: [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80 [ 115.620686] but task is already holding lock: [ 115.620723] (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40 [ 115.620795] which lock already depends on the new lock. [ 115.620853] the existing dependency chain (in reverse order) is: [ 115.620894] -> #1 (&macvlan_netdev_addr_lock_key){+.....}: [ 115.620935] [<ffffffff810d57f2>] lock_acquire+0xa2/0x130 [ 115.620974] [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50 [ 115.621019] [<ffffffffa07296c3>] vlan_dev_set_rx_mode+0x53/0x110 [8021q] [ 115.621066] [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0 [ 115.621105] [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40 [ 115.621143] [<ffffffff815da6be>] __dev_open+0xde/0x140 [ 115.621174] [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170 [ 115.621174] [<ffffffff815daaa9>] dev_change_flags+0x29/0x60 [ 115.621174] [<ffffffff815e7f11>] do_setlink+0x321/0x9a0 [ 115.621174] [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730 [ 115.621174] [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250 [ 115.621174] [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0 [ 115.621174] [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40 [ 115.621174] [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0 [ 115.621174] [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740 [ 115.621174] [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0 [ 115.621174] [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380 [ 115.621174] [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80 [ 115.621174] [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20 [ 115.621174] [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b [ 115.621174] -> #0 (&vlan_netdev_addr_lock_key/1){+.....}: [ 115.621174] [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60 [ 115.621174] [<ffffffff810d57f2>] lock_acquire+0xa2/0x130 [ 115.621174] [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50 [ 115.621174] [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan] [ 115.621174] [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0 [ 115.621174] [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40 [ 115.621174] [<ffffffff815da6be>] __dev_open+0xde/0x140 [ 115.621174] [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170 [ 115.621174] [<ffffffff815daaa9>] dev_change_flags+0x29/0x60 [ 115.621174] [<ffffffff815e7f11>] do_setlink+0x321/0x9a0 [ 115.621174] [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730 [ 115.621174] [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250 [ 115.621174] [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0 [ 115.621174] [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40 [ 115.621174] [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0 [ 115.621174] [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740 [ 115.621174] [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0 [ 115.621174] [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380 [ 115.621174] [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80 [ 115.621174] [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20 [ 115.621174] [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b [ 115.621174] other info that might help us debug this: [ 115.621174] Possible unsafe locking scenario: [ 115.621174] CPU0 CPU1 [ 115.621174] ---- ---- [ 115.621174] lock(&macvlan_netdev_addr_lock_key); [ 115.621174] lock(&vlan_netdev_addr_lock_key/1); [ 115.621174] lock(&macvlan_netdev_addr_lock_key); [ 115.621174] lock(&vlan_netdev_addr_lock_key/1); [ 115.621174] *** DEADLOCK *** [ 115.621174] 2 locks held by ip/1704: [ 115.621174] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff815e6dbb>] rtnetlink_rcv+0x1b/0x40 [ 115.621174] #1: (&macvlan_netdev_addr_lock_key){+.....}, at: [<ffffffff815da5be>] dev_set_rx_mode+0x1e/0x40 [ 115.621174] stack backtrace: [ 115.621174] CPU: 3 PID: 1704 Comm: ip Not tainted 3.15.0-rc1+ #24 [ 115.621174] Hardware name: Hewlett-Packard HP xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010 [ 115.621174] ffffffff82339ae0 ffff880465f79568 ffffffff816ee20c ffffffff82339ae0 [ 115.621174] ffff880465f795a8 ffffffff816e9e1b ffff880465f79600 ffff880465b019c8 [ 115.621174] 0000000000000001 0000000000000002 ffff880465b019c8 ffff880465b01230 [ 115.621174] Call Trace: [ 115.621174] [<ffffffff816ee20c>] dump_stack+0x4d/0x66 [ 115.621174] [<ffffffff816e9e1b>] print_circular_bug+0x200/0x20e [ 115.621174] [<ffffffff810d4d43>] __lock_acquire+0x1773/0x1a60 [ 115.621174] [<ffffffff810d3172>] ? trace_hardirqs_on_caller+0xb2/0x1d0 [ 115.621174] [<ffffffff810d57f2>] lock_acquire+0xa2/0x130 [ 115.621174] [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffff816f62e7>] _raw_spin_lock_nested+0x37/0x50 [ 115.621174] [<ffffffff815df49c>] ? dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffff815df49c>] dev_uc_sync+0x3c/0x80 [ 115.621174] [<ffffffffa0696d2a>] macvlan_set_mac_lists+0xca/0x110 [macvlan] [ 115.621174] [<ffffffff815da557>] __dev_set_rx_mode+0x57/0xa0 [ 115.621174] [<ffffffff815da5c6>] dev_set_rx_mode+0x26/0x40 [ 115.621174] [<ffffffff815da6be>] __dev_open+0xde/0x140 [ 115.621174] [<ffffffff815da9ad>] __dev_change_flags+0x9d/0x170 [ 115.621174] [<ffffffff815daaa9>] dev_change_flags+0x29/0x60 [ 115.621174] [<ffffffff811e1db1>] ? mem_cgroup_bad_page_check+0x21/0x30 [ 115.621174] [<ffffffff815e7f11>] do_setlink+0x321/0x9a0 [ 115.621174] [<ffffffff810d394c>] ? __lock_acquire+0x37c/0x1a60 [ 115.621174] [<ffffffff815ea59f>] rtnl_newlink+0x51f/0x730 [ 115.621174] [<ffffffff815ea169>] ? rtnl_newlink+0xe9/0x730 [ 115.621174] [<ffffffff815e6e75>] rtnetlink_rcv_msg+0x95/0x250 [ 115.621174] [<ffffffff810d329d>] ? trace_hardirqs_on+0xd/0x10 [ 115.621174] [<ffffffff815e6dbb>] ? rtnetlink_rcv+0x1b/0x40 [ 115.621174] [<ffffffff815e6de0>] ? rtnetlink_rcv+0x40/0x40 [ 115.621174] [<ffffffff81608b19>] netlink_rcv_skb+0xa9/0xc0 [ 115.621174] [<ffffffff815e6dca>] rtnetlink_rcv+0x2a/0x40 [ 115.621174] [<ffffffff81608150>] netlink_unicast+0xf0/0x1c0 [ 115.621174] [<ffffffff8160851f>] netlink_sendmsg+0x2ff/0x740 [ 115.621174] [<ffffffff815bc9db>] sock_sendmsg+0x8b/0xc0 [ 115.621174] [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0 [ 115.621174] [<ffffffff8119d4f8>] ? might_fault+0xa8/0xb0 [ 115.621174] [<ffffffff8119d4af>] ? might_fault+0x5f/0xb0 [ 115.621174] [<ffffffff815cb51e>] ? verify_iovec+0x5e/0xe0 [ 115.621174] [<ffffffff815bd4b9>] ___sys_sendmsg+0x369/0x380 [ 115.621174] [<ffffffff816faa0d>] ? __do_page_fault+0x11d/0x570 [ 115.621174] [<ffffffff810cfe9f>] ? up_read+0x1f/0x40 [ 115.621174] [<ffffffff816fab04>] ? __do_page_fault+0x214/0x570 [ 115.621174] [<ffffffff8120a10b>] ? mntput_no_expire+0x6b/0x1c0 [ 115.621174] [<ffffffff8120a0b7>] ? mntput_no_expire+0x17/0x1c0 [ 115.621174] [<ffffffff8120a284>] ? mntput+0x24/0x40 [ 115.621174] [<ffffffff815bdbb2>] __sys_sendmsg+0x42/0x80 [ 115.621174] [<ffffffff815bdc02>] SyS_sendmsg+0x12/0x20 [ 115.621174] [<ffffffff816ffd69>] system_call_fastpath+0x16/0x1b Fix this by correctly providing macvlan lockdep class. Signed-off-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-16vlan: Fix lockdep warning with stacked vlan devices.Vlad Yasevich4-45/+12
This reverts commit dc8eaaa006350d24030502a4521542e74b5cb39f. 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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-16net: Allow for more then a single subclass for netif_addr_lockVlad Yasevich1-1/+7
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-16net: Find the nesting level of a given device by type.Vlad Yasevich2-0/+60
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 <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-05-16clk: tegra: Fix wrong value written to PLLE_AUXTuomas Tynkkynen1-1/+1
The value written to PLLE_AUX was incorrect due to a wrong variable being used. Without this fix SATA does not work. Cc: [email protected] Signed-off-by: Tuomas Tynkkynen <[email protected]> Tested-by: Mikko Perttunen <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Tested-by: Thierry Reding <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Mike Turquette <[email protected]> [[email protected]: improved changelog]
2014-05-16staging: rtl8723au: Do not reset wdev->iftype in netdev_close()Jes Sorensen1-2/+0
wdev->ifdev should be set by .change_virtual_intf(). This solves the problem of WARN() messages on module unload. Signed-off-by: Jes Sorensen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-05-16ARM: OMAP2+: Fix DMA hang after off-idleTony Lindgren1-0/+10
Commit 6ddeb6d84459 (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 6ddeb6d84459 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: 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma) Cc: Russell King <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2014-05-16ARM: OMAP2+: nand: Fix NAND on OMAP2 and OMAP3 boardsRoger Quadros1-1/+1
Commit c66d039197e4 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: c66d039197e4 (mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes) Cc: [email protected] # v3.12+ Signed-off-by: Roger Quadros <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2014-05-16Merge branch 'acpi-video'Rafael J. Wysocki1-8/+0
* acpi-video: ACPI / video: Revert native brightness quirk for ThinkPad T530
2014-05-16Merge tag 'for-v3.15-rc/omap-fixes-b' of ↵Tony Lindgren2-2/+3
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/
Powered by cgit, Gruvboxed by Blaster4385.