aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-06-23kexec: save PG_head_mask in VMCOREINFOPetr Tesarik2-0/+4
To allow filtering of huge pages, makedumpfile must be able to identify them in the dump. This can be done by checking the appropriate page flag, so communicate its value to makedumpfile through the VMCOREINFO interface. There's only one small catch. Depending on how many page flags are available on a given architecture, this bit can be called PG_head or PG_compound. I sent a similar patch back in 2012, but Eric Biederman did not like using an #ifdef. So, this time I'm adding a common symbol (PG_head_mask) instead. See https://lkml.org/lkml/2012/11/28/91 for the previous version. Signed-off-by: Petr Tesarik <[email protected]> Acked-by: Vivek Goyal <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Shaohua Li <[email protected]> Cc: Alexey Kardashevskiy <[email protected]> Cc: Sasha Levin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-06-23CPU hotplug, smp: flush any pending IPI callbacks before CPU offlineSrivatsa S. Bhat1-8/+49
There is a race between the CPU offline code (within stop-machine) and the smp-call-function code, which can lead to getting IPIs on the outgoing CPU, *after* it has gone offline. Specifically, this can happen when using smp_call_function_single_async() to send the IPI, since this API allows sending asynchronous IPIs from IRQ disabled contexts. The exact race condition is described below. During CPU offline, in stop-machine, we don't enforce any rule in the _DISABLE_IRQ stage, regarding the order in which the outgoing CPU and the other CPUs disable their local interrupts. Due to this, we can encounter a situation in which an IPI is sent by one of the other CPUs to the outgoing CPU (while it is *still* online), but the outgoing CPU ends up noticing it only *after* it has gone offline. CPU 1 CPU 2 (Online CPU) (CPU going offline) Enter _PREPARE stage Enter _PREPARE stage Enter _DISABLE_IRQ stage = Got a device interrupt, and | Didn't notice the IPI the interrupt handler sent an | since interrupts were IPI to CPU 2 using | disabled on this CPU. smp_call_function_single_async() | = Enter _DISABLE_IRQ stage Enter _RUN stage Enter _RUN stage = Busy loop with interrupts | Invoke take_cpu_down() disabled. | and take CPU 2 offline = Enter _EXIT stage Enter _EXIT stage Re-enable interrupts Re-enable interrupts The pending IPI is noted immediately, but alas, the CPU is offline at this point. This of course, makes the smp-call-function IPI handler code running on CPU 2 unhappy and it complains about "receiving an IPI on an offline CPU". One real example of the scenario on CPU 1 is the block layer's complete-request call-path: __blk_complete_request() [interrupt-handler] raise_blk_irq() smp_call_function_single_async() However, if we look closely, the block layer does check that the target CPU is online before firing the IPI. So in this case, it is actually the unfortunate ordering/timing of events in the stop-machine phase that leads to receiving IPIs after the target CPU has gone offline. In reality, getting a late IPI on an offline CPU is not too bad by itself (this can happen even due to hardware latencies in IPI send-receive). It is a bug only if the target CPU really went offline without executing all the callbacks queued on its list. (Note that a CPU is free to execute its pending smp-call-function callbacks in a batch, without waiting for the corresponding IPIs to arrive for each one of those callbacks). So, fixing this issue can be broken up into two parts: 1. Ensure that a CPU goes offline only after executing all the callbacks queued on it. 2. Modify the warning condition in the smp-call-function IPI handler code such that it warns only if an offline CPU got an IPI *and* that CPU had gone offline with callbacks still pending in its queue. Achieving part 1 is straight-forward - just flush (execute) all the queued callbacks on the outgoing CPU in the CPU_DYING stage[1], including those callbacks for which the source CPU's IPIs might not have been received on the outgoing CPU yet. Once we do this, an IPI that arrives late on the CPU going offline (either due to the race mentioned above, or due to hardware latencies) will be completely harmless, since the outgoing CPU would have executed all the queued callbacks before going offline. Overall, this fix (parts 1 and 2 put together) additionally guarantees that we will see a warning only when the *IPI-sender code* is buggy - that is, if it queues the callback _after_ the target CPU has gone offline. [1]. The CPU_DYING part needs a little more explanation: by the time we execute the CPU_DYING notifier callbacks, the CPU would have already been marked offline. But we want to flush out the pending callbacks at this stage, ignoring the fact that the CPU is offline. So restructure the IPI handler code so that we can by-pass the "is-cpu-offline?" check in this particular case. (Of course, the right solution here is to fix CPU hotplug to mark the CPU offline _after_ invoking the CPU_DYING notifiers, but this requires a lot of audit to ensure that this change doesn't break any existing code; hence lets go with the solution proposed above until that is done). [[email protected]: coding-style fixes] Signed-off-by: Srivatsa S. Bhat <[email protected]> Suggested-by: Frederic Weisbecker <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Gautham R Shenoy <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Rik van Riel <[email protected]> Cc: Rusty Russell <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Thomas Gleixner <[email protected]> Tested-by: Sachin Kamat <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-06-23mm: nommu: per-thread vma cache fixSteven Miao1-1/+1
mm could be removed from current task struct, using previous vma->vm_mm It will crash on blackfin after updated to Linux 3.15. The commit "mm: per-thread vma caching" caused the crash. mm could be removed from current task struct before mmput()-> exit_mmap()-> delete_vma_from_mm() the detailed fault information: NULL pointer access Kernel OOPS in progress Deferred Exception context CURRENT PROCESS: COMM=modprobe PID=278 CPU=0 invalid mm return address: [0x000531de]; contents of: 0x000531b0: c727 acea 0c42 181d 0000 0000 0000 a0a8 0x000531c0: b090 acaa 0c42 1806 0000 0000 0000 a0e8 0x000531d0: b0d0 e801 0000 05b3 0010 e522 0046 [a090] 0x000531e0: 6408 b090 0c00 17cc 3042 e3ff f37b 2fc8 CPU: 0 PID: 278 Comm: modprobe Not tainted 3.15.0-ADI-2014R1-pre-00345-gea9f446 #25 task: 0572b720 ti: 0569e000 task.ti: 0569e000 Compiled for cpu family 0x27fe (Rev 0), but running on:0x0000 (Rev 0) ADSP-BF609-0.0 500(MHz CCLK) 125(MHz SCLK) (mpu off) Linux version 3.15.0-ADI-2014R1-pre-00345-gea9f446 (steven@steven-OptiPlex-390) (gcc version 4.3.5 (ADI-trunk/svn-5962) ) #25 Tue Jun 10 17:47:46 CST 2014 SEQUENCER STATUS: Not tainted SEQSTAT: 00000027 IPEND: 8008 IMASK: ffff SYSCFG: 2806 EXCAUSE : 0x27 physical IVG3 asserted : <0xffa00744> { _trap + 0x0 } physical IVG15 asserted : <0xffa00d68> { _evt_system_call + 0x0 } logical irq 6 mapped : <0xffa003bc> { _bfin_coretmr_interrupt + 0x0 } logical irq 7 mapped : <0x00008828> { _bfin_fault_routine + 0x0 } logical irq 11 mapped : <0x00007724> { _l2_ecc_err + 0x0 } logical irq 13 mapped : <0x00008828> { _bfin_fault_routine + 0x0 } logical irq 39 mapped : <0x00150788> { _bfin_twi_interrupt_entry + 0x0 } logical irq 40 mapped : <0x00150788> { _bfin_twi_interrupt_entry + 0x0 } RETE: <0x00000000> /* Maybe null pointer? */ RETN: <0x0569fe50> /* kernel dynamic memory (maybe user-space) */ RETX: <0x00000480> /* Maybe fixed code section */ RETS: <0x00053384> { _exit_mmap + 0x28 } PC : <0x000531de> { _delete_vma_from_mm + 0x92 } DCPLB_FAULT_ADDR: <0x00000008> /* Maybe null pointer? */ ICPLB_FAULT_ADDR: <0x000531de> { _delete_vma_from_mm + 0x92 } PROCESSOR STATE: R0 : 00000004 R1 : 0569e000 R2 : 00bf3db4 R3 : 00000000 R4 : 057f9800 R5 : 00000001 R6 : 0569ddd0 R7 : 0572b720 P0 : 0572b854 P1 : 00000004 P2 : 00000000 P3 : 0569dda0 P4 : 0572b720 P5 : 0566c368 FP : 0569fe5c SP : 0569fd74 LB0: 057f523f LT0: 057f523e LC0: 00000000 LB1: 0005317c LT1: 00053172 LC1: 00000002 B0 : 00000000 L0 : 00000000 M0 : 0566f5bc I0 : 00000000 B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : ffffffff B2 : 00000001 L2 : 00000000 M2 : 00000000 I2 : 00000000 B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 057f8000 A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000 USP : 056ffcf8 ASTAT: 02003024 Hardware Trace: 0 Target : <0x00003fb8> { _trap_c + 0x0 } Source : <0xffa006d8> { _exception_to_level5 + 0xa0 } JUMP.L 1 Target : <0xffa00638> { _exception_to_level5 + 0x0 } Source : <0xffa004f2> { _bfin_return_from_exception + 0x6 } RTX 2 Target : <0xffa004ec> { _bfin_return_from_exception + 0x0 } Source : <0xffa00590> { _ex_trap_c + 0x70 } JUMP.S 3 Target : <0xffa00520> { _ex_trap_c + 0x0 } Source : <0xffa0076e> { _trap + 0x2a } JUMP (P4) 4 Target : <0xffa00744> { _trap + 0x0 } FAULT : <0x000531de> { _delete_vma_from_mm + 0x92 } P0 = W[P2 + 2] Source : <0x000531da> { _delete_vma_from_mm + 0x8e } P2 = [P4 + 0x18] 5 Target : <0x000531da> { _delete_vma_from_mm + 0x8e } Source : <0x00053176> { _delete_vma_from_mm + 0x2a } IF CC JUMP pcrel 6 Target : <0x0005314c> { _delete_vma_from_mm + 0x0 } Source : <0x00053380> { _exit_mmap + 0x24 } JUMP.L 7 Target : <0x00053378> { _exit_mmap + 0x1c } Source : <0x00053394> { _exit_mmap + 0x38 } IF !CC JUMP pcrel (BP) 8 Target : <0x00053390> { _exit_mmap + 0x34 } Source : <0xffa020e0> { __cond_resched + 0x20 } RTS 9 Target : <0xffa020c0> { __cond_resched + 0x0 } Source : <0x0005338c> { _exit_mmap + 0x30 } JUMP.L 10 Target : <0x0005338c> { _exit_mmap + 0x30 } Source : <0x0005333a> { _delete_vma + 0xb2 } RTS 11 Target : <0x00053334> { _delete_vma + 0xac } Source : <0x0005507a> { _kmem_cache_free + 0xba } RTS 12 Target : <0x00055068> { _kmem_cache_free + 0xa8 } Source : <0x0005505e> { _kmem_cache_free + 0x9e } IF !CC JUMP pcrel (BP) 13 Target : <0x00055052> { _kmem_cache_free + 0x92 } Source : <0x0005501a> { _kmem_cache_free + 0x5a } IF CC JUMP pcrel 14 Target : <0x00054ff4> { _kmem_cache_free + 0x34 } Source : <0x00054fce> { _kmem_cache_free + 0xe } IF CC JUMP pcrel (BP) 15 Target : <0x00054fc0> { _kmem_cache_free + 0x0 } Source : <0x00053330> { _delete_vma + 0xa8 } JUMP.L Kernel Stack Stack info: SP: [0x0569ff24] <0x0569ff24> /* kernel dynamic memory (maybe user-space) */ Memory from 0x0569ff20 to 056a0000 0569ff20: 00000001 [04e8da5a] 00008000 00000000 00000000 056a0000 04e8da5a 04e8da5a 0569ff40: 04eb9eea ffa00dce 02003025 04ea09c5 057f523f 04ea09c4 057f523e 00000000 0569ff60: 00000000 00000000 00000000 00000000 00000000 00000000 00000001 00000000 0569ff80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0569ffa0: 0566f5bc 057f8000 057f8000 00000001 04ec0170 056ffcf8 056ffd04 057f9800 0569ffc0: 04d1d498 057f9800 057f8fe4 057f8ef0 00000001 057f928c 00000001 00000001 0569ffe0: 057f9800 00000000 00000008 00000007 00000001 00000001 00000001 <00002806> Return addresses in stack: address : <0x00002806> { _show_cpuinfo + 0x2d2 } Modules linked in: Kernel panic - not syncing: Kernel exception [ end Kernel panic - not syncing: Kernel exception Signed-off-by: Steven Miao <[email protected]> Acked-by: Davidlohr Bueso <[email protected]> Reviewed-by: Rik van Riel <[email protected]> Acked-by: David Rientjes <[email protected]> Cc: <[email protected]> [3.15.x] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2014-06-23x86_32, signal: Fix vdso rt_sigreturnAndy Lutomirski1-1/+1
This commit: commit 6f121e548f83674ab4920a4e60afb58d4f61b829 Author: Andy Lutomirski <[email protected]> Date: Mon May 5 12:19:34 2014 -0700 x86, vdso: Reimplement vdso.so preparation in build-time C Contained this obvious typo: - restorer = VDSO32_SYMBOL(current->mm->context.vdso, rt_sigreturn); + restorer = current->mm->context.vdso + + selected_vdso32->sym___kernel_sigreturn; Note the missing 'rt_' in the new code. Fix it. Signed-off-by: Andy Lutomirski <[email protected]> Link: http://lkml.kernel.org/r/1eb40ad923acde2e18357ef2832867432e70ac42.1403361010.git.luto@amacapital.net Signed-off-by: H. Peter Anvin <[email protected]>
2014-06-23x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)Andy Lutomirski1-2/+8
The bad syscall nr paths are their own incomprehensible route through the entry control flow. Rearrange them to work just like syscalls that return -ENOSYS. This fixes an OOPS in the audit code when fast-path auditing is enabled and sysenter gets a bad syscall nr (CVE-2014-4508). This has probably been broken since Linux 2.6.27: af0575bba0 i386 syscall audit fast-path Cc: [email protected] Cc: Roland McGrath <[email protected]> Reported-by: Toralf Förster <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Link: http://lkml.kernel.org/r/e09c499eade6fc321266dd6b54da7beb28d6991c.1403558229.git.luto@amacapital.net Signed-off-by: H. Peter Anvin <[email protected]>
2014-06-23ARM: dts: kirkwood: fix phy-connection-type for GuruplugSebastian Hesselbarth1-2/+2
Commit eeb845459a72e792a959278b858f9c417e9995bd ("ARM: dts: kirkwood: set Guruplug phy-connection-type to rgmii-id") added phy-connection-type properties to ethernet PHY nodes. Actually, the property has to be set for the ethernet port node instead. Fix it by moving the corresponding properties to the correct nodes. Signed-off-by: Sebastian Hesselbarth <[email protected]> Link: https://lkml.kernel.org/r/1403555115-13111-1-git-send-email-sebastian.hesselbarth@gmail.com Fixes: eeb845459a72: ('ARM: dts: kirkwood: set Guruplug phy-connection-type to rgmii-id') Cc: <[email protected]> # v3.16+ Signed-off-by: Jason Cooper <[email protected]>
2014-06-23be2net: fix qnq mode detection on VFsSuresh Reddy3-6/+4
The driver (on PF or VF) needs to detect if the function is in qnq mode for a HW hack in be_rx_compl_get() to work. The driver queries this information using the GET_PROFILE_CONFIG cmd (since the commit below can caused this regression.) But this cmd is not available on VFs and so the VFs fail to detect qnq mode. This causes vlan traffic to not work. The fix is to use the the adapter->function_mode value queried via QUERY_FIRMWARE_CONFIG cmd on both PFs and VFs to detect the qnq mode. Also QNQ_MODE was incorrectly named FLEX10_MODE; correcting that too as the fix reads much better with the name change. Fixes: f93f160b5 ("refactor multi-channel config code for Skyhawk-R chip") Signed-off-by: Suresh Reddy <[email protected]> Signed-off-by: Sathya Perla <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-23lz4: ensure length does not wrapGreg Kroah-Hartman1-0/+2
Given some pathologically compressed data, lz4 could possibly decide to wrap a few internal variables, causing unknown things to happen. Catch this before the wrapping happens and abort the decompression. Reported-by: "Don A. Bailey" <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-06-23lzo: properly check for overrunsGreg Kroah-Hartman1-21/+41
The lzo decompressor can, if given some really crazy data, possibly overrun some variable types. Modify the checking logic to properly detect overruns before they happen. Reported-by: "Don A. Bailey" <[email protected]> Tested-by: "Don A. Bailey" <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-06-23drm/i915: default to having backlight if VBT not availableJani Nikula1-3/+3
Apparently there are Apple laptops with magic smoke for a VBIOS, which we fail to find and use. Default to having and setting up backlight in this case. This fixes a regression introduced by commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <[email protected]> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77831 Reported-and-tested-by: Matteo Cypriani <[email protected]> Cc: [email protected] # 3.15+ Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-06-23Merge tag 'imx-fixes-3.16' of ↵Arnd Bergmann14-48/+73
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes Pull "i.MX fixes for 3.16" from Shawn Guo: - Use GPIO for card CD/WP on imx51-babbage and eukrea-mbimxsd51, because controller base CD/WP is not working in esdhc driver due to runtime PM support - A couple of random ventana gw5xxx board fixes - Add IMX_IPUV3_CORE back to defconfig, which gets lost when moving IPUv3 driver out of staging tree - Fix enet/fec clock selection on imx6sl - Fix display node on imx53-m53evk board - A couple of Cubox-i updates from Russell, which were omitted from the merge window due to dependency * tag 'imx-fixes-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: imx51-eukrea-mbimxsd51-baseboard: unbreak esdhc. ARM: dts: imx51-babbage: Fix esdhc setup ARM: dts: mx5: Move the display out of soc {} node ARM: dts: mx5: Fix IPU port node placement ARM: imx_v6_v7_defconfig: Enable CONFIG_IMX_IPUV3_CORE ARM: dts: hummingboard/cubox-i: move usb otg configuration to platform level ARM: dts: cubox-i: add support for PWM-driven front panel LED ARM: dts: imx6: ventana: correct gw52xx sgtl5000 clock source ARM: dts: imx6qdl-gw5xxx: Fix Linear Technology vendor prefix ARM: dts: imx6: ventana: fix include typo ARM: dts: imx6sl: correct the fec ipg clock source ARM: imx6sl: add missing enet clock for imx6sl
2014-06-23ALSA: hda - hdmi: call overridden init on resumePierre Ossman1-1/+1
We need to call the proper init function in case it has been overridden, as it might restore things that the generic routing doesn't know anything about. E.g. AMD cards have special verbs that need resetting. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77901 Fixes: 5a61358433b1 ('ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support') Signed-off-by: Pierre Ossman <[email protected]> Cc: <[email protected]> [v3.13+] Signed-off-by: Takashi Iwai <[email protected]>
2014-06-23ALSA: hda - Fix usage of "model" module parameterDavid Henningsson1-0/+1
A recent refactoring broke the possibility to manually specify model name as a module parameter. This patch restores the desired functionality. Fixes: c21c8cf77f47 ('ALSA: hda - Add fixup_forced flag') Reported-by: Kent Baxley <[email protected]> Signed-off-by: David Henningsson <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-06-23ALSA: compress: fix the struct alignment to 4 bytesVinod Koul2-14/+14
In 64bit systems the compiler can default align to 8bytes causing mis-match with 32bit usermode. Avoid this is future by ensuring all the structures shared with usermode are packed and aligned to 4 bytes irrespective of arch used [coding style fixes by tiwai] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2014-06-23rbd: handle parent_overlap on writes correctlyIlya Dryomov1-1/+9
The following check in rbd_img_obj_request_submit() rbd_dev->parent_overlap <= obj_request->img_offset allows the fall through to the non-layered write case even if both parent_overlap and obj_request->img_offset belong to the same RADOS object. This leads to data corruption, because the area to the left of parent_overlap ends up unconditionally zero-filled instead of being populated with parent data. Suppose we want to write 1M to offset 6M of image bar, which is a clone of foo@snap; object_size is 4M, parent_overlap is 5M: rbd_data.<id>.0000000000000001 ---------------------|----------------------|------------ | should be copyup'ed | should be zeroed out | write ... ---------------------|----------------------|------------ 4M 5M 6M parent_overlap obj_request->img_offset 4..5M should be copyup'ed from foo, yet it is zero-filled, just like 5..6M is. Given that the only striping mode kernel client currently supports is chunking (i.e. stripe_unit == object_size, stripe_count == 1), round parent_overlap up to the next object boundary for the purposes of the overlap check. Cc: [email protected] # 3.10+ Signed-off-by: Ilya Dryomov <[email protected]> Reviewed-by: Josh Durgin <[email protected]>
2014-06-23drm/i915: cache hw power well enabled stateImre Deak4-27/+22
Jesse noticed that the punit communication needed to query the VLV power well status can cause substantial delays. Since we can query the state frequently, for example during I2C transfers, maintain a cached version of the HW state to get rid of this delay. This fixes at least one reported regression where boot time increased by ~4 seconds due to frequent power well state queries on VLV during eDP EDID read. This regression has been introduced in commit bb4932c4f17b68f34645ffbcf845e4c29d17290b Author: Imre Deak <[email protected]> Date: Mon Apr 14 20:24:33 2014 +0300 drm/i915: vlv: check port power domain instead of only D0 for eDP VDD on Reported-by: Jesse Barnes <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-06-23vhost-scsi: don't open-code kvfreeMichael S. Tsirkin1-10/+2
Now that we have kvfree, use it in vhost-scsi instead of the open-coded version. Cc: Nicholas Bellinger <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2014-06-23vhost-net: don't open-code kvfreeRomain Francoise1-10/+2
Commit 23cc5a991c ("vhost-net: extend device allocation to vmalloc") added another open-coded version of kvfree (which is available since v3.15-rc5), nuke it. Signed-off-by: Romain Francoise <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]>
2014-06-23ARC: fix build warning in devtreeVineet Gupta1-1/+1
Signed-off-by: Vineet Gupta <[email protected]>
2014-06-22of: mdio: fixup of_phy_register_fixed_link parsing of new bindingsRichard Retanubun1-3/+5
Fixes commit 3be2a49e5c08 ("of: provide a binding for fixed link PHYs") Fix the parsing of the new fixed link dts bindings for duplex, pause, and asym_pause by using the correct device node pointer. Signed-off-by: Richard Retanubun <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-22at86rf230: fix irq setupPhoebe Buckheister1-1/+4
Commit 8eba0eefae24953962067 ("at86rf230: remove irq_type in request_irq") removed the trigger configuration when requesting an irq, and instead relied on the interrupt trigger to be properly configured already. This does not seem to be an assumption that can be safely made, since boards disable all interrupt triggers on boot. On these boards, force the irq to trigger on rising edge, which is also the default for the chip. Signed-off-by: Phoebe Buckheister <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-22net: phy: at803x: fix coccinelle warningsFengguang Wu1-1/+1
drivers/net/phy/at803x.c:196:26-32: ERROR: application of sizeof to pointer sizeof when applied to a pointer typed expression gives the size of the pointer Generated by: scripts/coccinelle/misc/noderef.cocci Signed-off-by: Fengguang Wu <[email protected]> Acked-by: Daniel Mack <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-22net/mlx4_core: Fix the error flow when probing with invalid VF configurationOr Gerlitz1-1/+2
Single ported VF are currently not supported on configurations where one or both ports are IB. When we hit this case, the relevant flow in the driver didn't return error and jumped to the wrong label. Fix that. Fixes: dd41cc3 ('net/mlx4: Adapt num_vfs/probed_vf params for single port VF') Reported-by: Shirley Ma <[email protected]> Signed-off-by: Or Gerlitz <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-22tulip: Poll link status more frequently for Comet chipsOndrej Zary1-1/+1
It now takes up to 60 seconds to detect cable (un)plug on ADMtek Comet chips. That's too slow and might cause people to think that it doesn't work at all. Poll link status every 2 seconds instead of 60 for ADMtek Comet chips. That should be fast enough while not stressing the system too much. Tested with ADMtek AN983B. Signed-off-by: Ondrej Zary <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-22Revert "block: add __init to elv_register"Jens Axboe2-2/+2
This reverts commit b5097e956a4d2919ee248d6481e4204c5568ed5c. The original commit is buggy, we do use the registration functions at runtime, for instance when loading IO schedulers through sysfs. Reported-by: Damien Wyart <[email protected]>
2014-06-22Revert "block: add __init to blkcg_policy_register"Jens Axboe2-3/+3
This reverts commit a2d445d440003f2d70ee4cd4970ea82ace616fee. The original commit is buggy, we do use the registration functions at runtime for modular builds.
2014-06-22blkcg: fix use-after-free in __blkg_release_rcu() by making blkcg_gq refcnt ↵Tejun Heo2-15/+9
an atomic_t Hello, So, this patch should do. Joe, Vivek, can one of you guys please verify that the oops goes away with this patch? Jens, the original thread can be read at http://thread.gmane.org/gmane.linux.kernel/1720729 The fix converts blkg->refcnt from int to atomic_t. It does some overhead but it should be minute compared to everything else which is going on and the involved cacheline bouncing, so I think it's highly unlikely to cause any noticeable difference. Also, the refcnt in question should be converted to a perpcu_ref for blk-mq anyway, so the atomic_t is likely to go away pretty soon anyway. Thanks. ------- 8< ------- __blkg_release_rcu() may be invoked after the associated request_queue is released with a RCU grace period inbetween. As such, the function and callbacks invoked from it must not dereference the associated request_queue. This is clearly indicated in the comment above the function. Unfortunately, while trying to fix a different issue, 2a4fd070ee85 ("blkcg: move bulk of blkcg_gq release operations to the RCU callback") ignored this and added [un]locking of @blkg->q->queue_lock to __blkg_release_rcu(). This of course can cause oops as the request_queue may be long gone by the time this code gets executed. general protection fault: 0000 [#1] SMP CPU: 21 PID: 30 Comm: rcuos/21 Not tainted 3.15.0 #1 Hardware name: Stratus ftServer 6400/G7LAZ, BIOS BIOS Version 6.3:57 12/25/2013 task: ffff880854021de0 ti: ffff88085403c000 task.ti: ffff88085403c000 RIP: 0010:[<ffffffff8162e9e5>] [<ffffffff8162e9e5>] _raw_spin_lock_irq+0x15/0x60 RSP: 0018:ffff88085403fdf0 EFLAGS: 00010086 RAX: 0000000000020000 RBX: 0000000000000010 RCX: 0000000000000000 RDX: 000060ef80008248 RSI: 0000000000000286 RDI: 6b6b6b6b6b6b6b6b RBP: ffff88085403fdf0 R08: 0000000000000286 R09: 0000000000009f39 R10: 0000000000020001 R11: 0000000000020001 R12: ffff88103c17a130 R13: ffff88103c17a080 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88107fca0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000006e5ab8 CR3: 000000000193d000 CR4: 00000000000407e0 Stack: ffff88085403fe18 ffffffff812cbfc2 ffff88103c17a130 0000000000000000 ffff88103c17a130 ffff88085403fec0 ffffffff810d1d28 ffff880854021de0 ffff880854021de0 ffff88107fcaec58 ffff88085403fe80 ffff88107fcaec30 Call Trace: [<ffffffff812cbfc2>] __blkg_release_rcu+0x72/0x150 [<ffffffff810d1d28>] rcu_nocb_kthread+0x1e8/0x300 [<ffffffff81091d81>] kthread+0xe1/0x100 [<ffffffff8163813c>] ret_from_fork+0x7c/0xb0 Code: ff 47 04 48 8b 7d 08 be 00 02 00 00 e8 55 48 a4 ff 5d c3 0f 1f 00 66 66 66 66 90 55 48 89 e5 +fa 66 66 90 66 66 90 b8 00 00 02 00 <f0> 0f c1 07 89 c2 c1 ea 10 66 39 c2 75 02 5d c3 83 e2 fe 0f +b7 RIP [<ffffffff8162e9e5>] _raw_spin_lock_irq+0x15/0x60 RSP <ffff88085403fdf0> The request_queue locking was added because blkcg_gq->refcnt is an int protected with the queue lock and __blkg_release_rcu() needs to put the parent. Let's fix it by making blkcg_gq->refcnt an atomic_t and dropping queue locking in the function. Given the general heavy weight of the current request_queue and blkcg operations, this is unlikely to cause any noticeable overhead. Moreover, blkcg_gq->refcnt is likely to be converted to percpu_ref in the near future, so whatever (most likely negligible) overhead it may add is temporary. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Joe Lawrence <[email protected]> Acked-by: Vivek Goyal <[email protected]> Link: http://lkml.kernel.org/g/[email protected] Cc: [email protected] Signed-off-by: Jens Axboe <[email protected]>
2014-06-22Merge tag 'samsung-fixes-1' of ↵Arnd Bergmann5-25/+20
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes Merge Samsung fixes for 3.16 from Kukjin Kim: - use WFI macro in platform_do_lowpower because exynos cpuhotplug includes a hardcoded WFI instruction and it causes compile error in Thumb-2 mode. - fix GIC reg sizes for exynos4 SoCs - remove reset timer counter value during boot and resume for mct to fix a big jump in printk timestamps - fix pm code to check cortex-A9 for another exynos SoCs - don't rely on firmware's secondary_cpu_start for mcpm * tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung: ARM: EXYNOS: Don't rely on firmware's secondary_cpu_start for mcpm ARM: EXYNOS: fix pm code to check for cortex A9 rather than the SoC clocksource: exynos_mct: Don't reset the counter during boot and resume ARM: dts: fix reg sizes of GIC for exynos4 ARM: EXYNOS: Use wfi macro in platform_do_lowpower Signed-off-by: Arnd Bergmann <[email protected]>
2014-06-22drm/msm: fix IOMMU cleanup for -EPROBE_DEFERStephane Viau5-7/+44
If probe fails after IOMMU is attached, we need to detach in order to clean up properly. Before this change, IOMMU faults would occur if the probe failed (-EPROBE_DEFER). Signed-off-by: Stephane Viau <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2014-06-22drm/msm: use PAGE_ALIGNED instead of IS_ALIGNED(PAGE_SIZE)Fabian Frederick1-1/+1
use mm.h definition Cc: David Airlie <[email protected]> Cc: Rob Clark <[email protected]> Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2014-06-22drm/msm/hdmi: set hdp clock rate before prepare_enableStephane Viau3-0/+11
The clock driver usually complains when a clock is being prepared before setting its rate. It is the case here for "core_clk" which needs to be set at 19.2 MHz before we attempt a prepare_enable(). Signed-off-by: Stephane Viau <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2014-06-22drm/msm: storage class should be before const qualifierPeter Griffin1-1/+1
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Peter Griffin <[email protected]> Cc: David Airlie <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Rob Clark <[email protected]>
2014-06-22drm/msm: Replace type of paddr to uint32_t.Matwey V. Kornilov1-1/+1
This patch helps to avoid the following build issue: drivers/gpu/drm/msm/msm_fbdev.c:108:2: error: passing argument 3 of 'msm_gem_get_iova_locked' from incompatible pointer type [-Werror] msm_gem_get_iova_locked(fbdev->bo, 0, &paddr); ^ In file included from drivers/gpu/drm/msm/msm_fbdev.c:18:0: drivers/gpu/drm/msm/msm_drv.h:153:5: note: expected 'uint32_t *' but argument is of type 'dma_addr_t *' int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id, ^ Signed-off-by: Matwey V. Kornilov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2014-06-22regulator: bcm590xx: fix vbus nameGraham Williams1-0/+5
The vbus regulator was not getting its name set. This results in the sysfs entry being empty. The lack of a bcm590xx_regs[] table entry also upsets Coverity runs. Add the table entry so the name gets set properly. Signed-off-by: Graham Williams <[email protected]> Acked-by: Matt Porter <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2014-06-22spi: qup: Remove chip select functionAndy Gross2-27/+12
This patch removes the chip select function. Chip select should instead be supported using GPIOs, defining the DT entry "cs-gpios", and letting the SPI core assert/deassert the chip select as it sees fit. The chip select control inside the controller is buggy. It is supposed to automatically assert the chip select based on the activity in the controller, but it is buggy and doesn't work at all. So instead we elect to use GPIOs. Signed-off-by: Andy Gross <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2014-06-21Linux 3.16-rc2Linus Torvalds1-1/+1
2014-06-21Merge branch 'i2c/for-next' of ↵Linus Torvalds6-0/+1216
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c new drivers from Wolfram Sang: "Here is a pull request from i2c hoping for the "new driver" rule. Originally, I wanted to send this request during the merge window, but code checkers with very recent additions complained, so a few fixups were needed. So, some more time went by and I merged rc1 to get a stable base" So the "new driver" rule is really about drivers that people absolutely need for the kernel to work on new hardware, which is not so much the case for i2c. So I considered not pulling this, but eventually relented. Just for FYI: the whole (and only) point of "new drivers" is not that new drivers cannot regress things (they can, and they have - by triggering badly tested code on machines that never triggered that code before), but because they can bring to life machines that otherwise wouldn't be useful at all without the drivers. So the new driver rule is for essential things that actual consumers would care about, ie devices like networking or disk drivers that matter to normal people (not server people - they run old kernels anyway, so mainlining new drivers is irrelevant for them). * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: sun6-p2wi: fix call to snprintf i2c: rk3x: add NULL entry to the end of_device_id array i2c: sun6i-p2wi: use proper return value in probe i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support i2c: sunxi: add P2WI DT bindings documentation i2c: rk3x: add driver for Rockchip RK3xxx SoC I2C adapter
2014-06-21Merge tag 'locks-v3.16-2' of git://git.samba.org/jlayton/linuxLinus Torvalds2-1/+7
Pull file locking fixes from Jeff Layton: "File locking related bugfixes Nothing too earth-shattering here. A fix for a potential regression due to a patch in pile #1, and the addition of a memory barrier to prevent a race condition between break_deleg and generic_add_lease" * tag 'locks-v3.16-2' of git://git.samba.org/jlayton/linux: locks: set fl_owner for leases back to current->files locks: add missing memory barrier in break_deleg
2014-06-21Merge branch 'rc-fixes' of ↵Linus Torvalds4-11/+12
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild fixes from Michal Marek: "There are three fixes for regressions caused by the relative paths series: deb-pkg, tar-pkg and *docs did not work with O=. Plus, there is a fix for the linux-headers deb package and a fixed typo. These are not regression fixes but are safe enough" * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: kbuild: fix a typo in a kbuild document builddeb: fix missing headers in linux-headers package Documentation: Fix DocBook build with relative $(srctree) kbuild: Fix tar-pkg with relative $(objtree) deb-pkg: Fix for relative paths
2014-06-21net: huawei_cdc_ncm: increase command buffer sizeBjørn Mork1-3/+4
Messages from the modem exceeding 256 bytes cause communication failure. The WDM protocol is strictly "read on demand", meaning that we only poll for unread data after receiving a notification from the modem. Since we have no way to know how much data the modem has to send, we must make sure that the buffer we provide is "big enough". Message truncation does not work. Truncated messages are left unread until the modem has another message to send. Which often won't happen until the userspace application has given up waiting for the final part of the last message, and therefore sends another command. With a proper CDC WDM function there is a descriptor telling us which buffer size the modem uses. But with this vendor specific implementation there is no known way to calculate the exact "big enough" number. It is an unknown property of the modem firmware. Experience has shown that 256 is too small. The discussion of this failure ended up concluding that 512 might be too small as well. So 1024 seems like a reasonable value for now. Fixes: 41c47d8cfd68 ("net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver") Cc: Enrico Mioso <[email protected]> Reported-by: Dan Williams <[email protected]> Signed-off-by: Bjørn Mork <[email protected]> Acked-By: Enrico Mioso <[email protected]> Tested-by: Dan Williams <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-21Merge branch 'for-linus' of ↵Linus Torvalds11-172/+359
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs Pull btrfs fixes from Chris Mason: "This fixes some lockups in btrfs reported with rc1. It probably has some performance impact because it is backing off our spinning locks more often and switching to a blocking lock. I'll be able to nail that down next week, but for now I want to get the lockups taken care of. Otherwise some more stack reduction and assorted fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: fix wrong error handle when the device is missing or is not writeable Btrfs: fix deadlock when mounting a degraded fs Btrfs: use bio_endio_nodec instead of open code Btrfs: fix NULL pointer crash when running balance and scrub concurrently btrfs: Skip scrubbing removed chunks to avoid -ENOENT. Btrfs: fix broken free space cache after the system crashed Btrfs: make free space cache write out functions more readable Btrfs: remove unused wait queue in struct extent_buffer Btrfs: fix deadlocks with trylock on tree nodes
2014-06-21Merge branch 'for-3.16' of git://linux-nfs.org/~bfields/linuxLinus Torvalds2-0/+79
Pull nfsd bugfixes from Bruce Fields: "Fixes for a new regression from the xdr encoding rewrite, and a delegation problem we've had for a while (made somewhat more annoying by the vfs delegation support added in 3.13)" * 'for-3.16' of git://linux-nfs.org/~bfields/linux: NFSD: fix bug for readdir of pseudofs NFSD: Don't hand out delegations for 30 seconds after recalling them.
2014-06-21drivers: net: cpsw: fix dual EMAC stall when connected to same switchMugunthan V N1-1/+6
In commit 629c9a8fd0bbdfc6d702526b327470166ec39c6b (drivers: net: cpsw: Add default vlan for dual emac case also), api cpsw_add_default_vlan() also changes the port vlan which is required to seperate the ports which results in the following behavior In Dual EMAC mode, when both the Etnernet connected is connected to same switch, it creates a loop in the switch and when a broadcast packet is received it is forwarded to the other port which stalls the whole switch and needs a reset/power cycle to the switch to recover. So intead of using the api, add only the default VLAN entry in dual EMAC case. Cc: Yegor Yefremov <[email protected]> Cc: Felipe Balbi <[email protected]> Signed-off-by: Mugunthan V N <[email protected]> Tested-by: Yegor Yefremov <[email protected]> Tested-by: Felipe Balbi <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-21Merge branch 'xen-netfront'David S. Miller1-34/+75
David Vrabel says: ==================== xen-netfront: fix resume regressions in 3.16-rc1 The introduction of multi-queue support to xen-netfront in 3.16-rc1, broke resume/migration. ==================== Signed-off-by: David S. Miller <[email protected]>
2014-06-21xen-netfront: recreate queues correctly when reconnectingDavid Vrabel1-32/+72
When reconnecting to the backend (after a resume/migration, for example), a different number of queues may be required (since the guest may have moved to a different host with different capabilities). During the reconnection the old queues are torn down and new ones created. Introduce xennet_create_queues() and xennet_destroy_queues() that fixes three bugs during the reconnection. - The old info->queues was leaked. - The old queue's napi instances were not deleted. - The new queue's napi instances were left disabled (which meant no packets could be received). The xennet_destroy_queues() calls is deferred until the reconnection instead of the disconnection (in xennet_disconnect_backend()) because napi_disable() might sleep. Signed-off-by: David Vrabel <[email protected]> Reviewed-by: Wei Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-21xen-netfront: fix oops when disconnected from backendDavid Vrabel1-2/+3
xennet_disconnect_backend() was not correctly iterating over all the queues. Signed-off-by: David Vrabel <[email protected]> Reviewed-by: Wei Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-21Merge branch 'at803x'David S. Miller3-44/+163
Daniel Mack says: ==================== Handle stuck TX queue bug in AT8030 PHY These three small patches circument a hardware bug in AT8030 PHYs that leads to stuck TX FIFO queues when the link goes away while there are pending patches in der outbound queue. This bug has been confirmed by the vendor, and their only proposed fix is to apply a hardware reset every time the link goes down. v1 -> v2: * Rename phy device callback from adjust_state to link_change_notify ==================== Signed-off-by: David S. Miller <[email protected]>
2014-06-21net: phy: at803x: Add support for hardware resetDaniel Mack1-41/+144
The AT8030 will enter a FIFO error mode if a packet is transmitted while the cable is unplugged. This hardware issue is acknowledged by the vendor, and the only proposed solution is to conduct a hardware reset via the external pin each time the link goes down. There is apparantly no way to fix up the state via the register set. This patch adds support for reading a 'reset-gpios' property from the DT node of the PHY. If present, this gpio is used to apply a hardware reset each time a 'link down' condition is detected. All relevant registers are read out before, and written back after the reset cycle. Doing this every time the link goes down might seem like overkill, but there is unfortunately no way of figuring out whether the PHY is in such a lock-up state. Hence, this is the only way of reliably fixing up things. Signed-off-by: Daniel Mack <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-21net: phy: at803x: use #defines for supported PHY idsDaniel Mack1-6/+10
This removes magic values from two tables and also allows us to match against specific PHY models at runtime. Signed-off-by: Daniel Mack <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2014-06-21net: phylib: add link_change_notify callback to phy deviceDaniel Mack2-0/+12
Add a notify callback to inform phy drivers when the core is about to do its link adjustment. No change for drivers that do not implement this callback. Signed-off-by: Daniel Mack <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.