summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-10-16Linux 4.4.25v4.4.25Greg Kroah-Hartman
2016-10-16tpm_crb: fix crb_req_canceled behaviorJarkko Sakkinen
commit 72fd50e14e46dc0edf360631bdece87c2f066a97 upstream. The req_canceled() callback is used by tpm_transmit() periodically to check whether the request has been canceled while it is receiving a response from the TPM. The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel callback, which has two consequences: * Cancel might not happen. * req_canceled() always returns zero. A better place to clear the register is when starting to send a new command. The behavior of TPM_CRB_CTRL_CANCEL is described in the section 5.5.3.6 of the PTP specification. Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16tpm: fix a race condition in tpm2_unseal_trusted()Jarkko Sakkinen
commit d4816edfe706497a8525480c1685ceb9871bc118 upstream. Unseal and load operations should be done as an atomic operation. This commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() can do the locking by itself. Fixes: 0fe5480303a1 ("keys, trusted: seal/unseal with TPM 2.0 chips") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ima: use file_dentry()Miklos Szeredi
commit e71b9dff0634edb127f449e076e883ef24a8c76c upstream. Ima tries to call ->setxattr() on overlayfs dentry after having locked underlying inode, which results in a deadlock. Reported-by: Krisztian Litkey <kli@iki.fi> Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by: Miklos Szeredi <mszeredi@redhat.com> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ARM: cpuidle: Fix error return codeChristophe Jaillet
commit af48d7bc3756a0cd882d65bff14ab39746ba57fe upstream. We know that 'ret = 0' because it has been tested a few lines above. So, if 'kzalloc' fails, 0 will be returned instead of an error code. Return -ENOMEM instead. Fixes: a0d46a3dfdc3 ("ARM: cpuidle: Register per cpuidle device") Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ARM: dts: MSM8064 remove flags from SPMI/MPP IRQsLinus Walleij
commit ca88696e8b73a9fa2b1de445747e9235c3a7bd50 upstream. The Qualcomm PMIC GPIO and MPP lines are problematic: the are fetched from the main MFD driver with platform_get_irq() which means that at this point they will all be assigned the flags set up for the interrupts in the device tree. That is problematic since these are flagged as rising edge and an this point the interrupt descriptor is assigned a rising edge, while the only thing the GPIO/MPP drivers really do is issue irq_get_irqchip_state() on the line to read it out and to provide a .to_irq() helper for *other* IRQ consumers. If another device tree node tries to flag the same IRQ for use as something else than rising edge, the kernel irqdomain core will protest like this: type mismatch, failed to map hwirq-NN for <FOO>! Which is what happens when the device tree defines two contradictory flags for the same interrupt line. To work around this and alleviate the problem, assign 0 as flag for the interrupts taken by the PM GPIO and MPP drivers. This will lead to the flag being unset, and a second consumer requesting rising, falling, both or level interrupts will be respected. This is what the qcom-pm*.dtsi files already do. Switched to using the symbolic name IRQ_TYPE_NONE so that we get this more readable. Fixes: bce360469676 ("ARM: dts: apq8064: add pm8921 mpp support") Fixes: 874443fe9e33 ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Björn Andersson <bjorn.andersson@linaro.org> Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Andy Gross <andy.gross@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ARM: dts: mvebu: armada-390: add missing compatibility string and bracketGrzegorz Jaszczyk
commit 061492cfad9f11dbc32df741a7164f307b69b6e6 upstream. The armada-390.dtsi was broken since the first patch which adds Device Tree files for Armada 39x SoC was introduced. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes 538da83 ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2016-10-16x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack accessJosh Poimboeuf
commit 72b4f6a5e903b071f2a7c4eb1418cbe4eefdc344 upstream. On x86_32, when an interrupt happens from kernel space, SS and SP aren't pushed and the existing stack is used. So pt_regs is effectively two words shorter, and the previous stack pointer is normally the memory after the shortened pt_regs, aka '&regs->sp'. But in the rare case where the interrupt hits right after the stack pointer has been changed to point to an empty stack, like for example when call_on_stack() is used, the address immediately after the shortened pt_regs is no longer on the stack. In that case, instead of '&regs->sp', the previous stack pointer should be retrieved from the beginning of the current stack page. kernel_stack_pointer() wants to do that, but it forgets to dereference the pointer. So instead of returning a pointer to the previous stack, it returns a pointer to the beginning of the current stack. Note that it's probably outside of kernel_stack_pointer()'s scope to be switching stacks at all. The x86_64 version of this function doesn't do it, and it would be better for the caller to do it if necessary. But that's a patch for another day. This just fixes the original intent. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Byungchul Park <byungchul.park@lge.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nilay Vaish <nilayvaish@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 0788aa6a23cb ("x86: Prepare removal of previous_esp from i386 thread_info structure") Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16x86/irq: Prevent force migration of irqs which are not in the vector domainMika Westerberg
commit db91aa793ff984ac048e199ea1c54202543952fe upstream. When a CPU is about to be offlined we call fixup_irqs() that resets IRQ affinities related to the CPU in question. The same thing is also done when the system is suspended to S-states like S3 (mem). For each IRQ we try to complete any on-going move regardless whether the IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch its chip_data, assume it is of type struct apic_chip_data and manipulate it by clearing old_domain mask etc. For irq_chips that are not part of the x86_vector_domain, like those created by various GPIO drivers, will find their chip_data being changed unexpectly. Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets corrupted after resume: # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in hi # rtcwake -s10 -mmem <10 seconds passes> # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in ? Note '?' in the output. It means the struct gpio_chip ->get function is NULL whereas before suspend it was there. Fix this by first checking that the IRQ belongs to x86_vector_domain before we try to use the chip_data as struct apic_chip_data. Reported-and-tested-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: http://lkml.kernel.org/r/20161003101708.34795-1-mika.westerberg@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulationDan Williams
commit 917db484dc6a69969d317b3e57add4208a8d9d42 upstream. In commit: ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type") Christoph references the original patch I wrote implementing pmem support. The intent of the 'max_pfn' changes in that commit were to enable persistent memory ranges to be covered by the struct page memmap by default. However, that approach was abandoned when Christoph ported the patches [1], and that functionality has since been replaced by devm_memremap_pages(). In the meantime, this max_pfn manipulation is confusing kdump [2] that assumes that everything covered by the max_pfn is "System RAM". This results in kdump hanging or crashing. [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098 So fix it. Reported-by: Zhang Yi <yizhan@redhat.com> Reported-by: Jeff Moyer <jmoyer@redhat.com> Tested-by: Zhang Yi <yizhan@redhat.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Jeff Moyer <jmoyer@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Boaz Harrosh <boaz@plexistor.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-nvdimm@lists.01.org Fixes: ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type") Link: http://lkml.kernel.org/r/147448744538.34910.11287693517367139607.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16KVM: PPC: BookE: Fix a sanity checkDan Carpenter
commit ac0e89bb4744d3882ccd275f2416d9ce22f4e1e7 upstream. We use logical negate where bitwise negate was intended. It means that we never return -EINVAL here. Fixes: ce11e48b7fdd ('KVM: PPC: E500: Add userspace debug stub support') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Alexander Graf <agraf@suse.de> Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16KVM: MIPS: Drop other CPU ASIDs on guest MMU changesJames Hogan
commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream. When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate TLB entries on the local CPU. This doesn't work correctly on an SMP host when the guest is migrated to a different physical CPU, as it could pick up stale TLB mappings from the last time the vCPU ran on that physical CPU. Therefore invalidate both user and kernel host ASIDs on other CPUs, which will cause new ASIDs to be generated when it next runs on those CPUs. We're careful only to do this if the TLB entry was already valid, and only for the kernel ASID where the virtual address it mapped is outside of the guest user address range. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 registerThomas Huth
commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream. The MMCR2 register is available twice, one time with number 785 (privileged access), and one time with number 769 (unprivileged, but it can be disabled completely). In former times, the Linux kernel was using the unprivileged register 769 only, but since commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number for MMCR2"), it uses the privileged register 785 instead. The KVM-PR code then of course also switched to use the SPR 785, but this is causing older guest kernels to crash, since these kernels still access 769 instead. So to support older kernels with KVM-PR again, we have to support register 769 in KVM-PR, too. Fixes: 8dd75ccb571f3c92c48014b3dabd3d51a115ab41 Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16mfd: wm8350-i2c: Make sure the i2c regmap functions are compiledUwe Kleine-König
commit 88003fb10f1fc606e1704611c62ceae95fd1d7da upstream. This fixes a compile failure: drivers/built-in.o: In function `wm8350_i2c_probe': core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c' Makefile:953: recipe for target 'vmlinux' failed Fixes: 52b461b86a9f ("mfd: Add regmap cache support for wm8350") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16mfd: 88pm80x: Double shifting bug in suspend/resumeDan Carpenter
commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream. set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16mfd: atmel-hlcdc: Do not sleep in atomic contextBoris Brezillon
commit 2c2469bc03d569c49119db2cccb5cb3f0c6a5b33 upstream. readl_poll_timeout() calls usleep_range(), but regmap_atmel_hlcdc_reg_write() is called in atomic context (regmap spinlock held). Replace the readl_poll_timeout() call by readl_poll_timeout_atomic(). Fixes: ea31c0cf9b07 ("mfd: atmel-hlcdc: Implement config synchronization") Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16mfd: rtsx_usb: Avoid setting ucr->current_sg.statusLu Baolu
commit 8dcc5ff8fcaf778bb57ab4448fedca9e381d088f upstream. Member "status" of struct usb_sg_request is managed by usb core. A spin lock is used to serialize the change of it. The driver could check the value of req->status, but should avoid changing it without the hold of the spinlock. Otherwise, it could cause race or error in usb core. This patch could be backported to stable kernels with version later than v3.14. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Roger Tseng <rogerable@realtek.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ALSA: usb-line6: use the same declaration as definition in header for MIDI ↵Takashi Sakamoto
manufacturer ID commit 8da08ca03b73593d5299893bf29fc08569c3fb5f upstream. Currently, usb-line6 module exports an array of MIDI manufacturer ID and usb-pod module uses it. However, the declaration is not the definition in common header. The difference is explicit length of array. Although compiler calculates it and everything goes well, it's better to use the same representation between definition and declaration. This commit fills the length of array for usb-line6 module. As a small good sub-effect, this commit suppress below warnings from static analysis by sparse v0.5.0. sound/usb/line6/driver.c:274:43: error: cannot size expression sound/usb/line6/driver.c:275:16: error: cannot size expression sound/usb/line6/driver.c:276:16: error: cannot size expression sound/usb/line6/driver.c:277:16: error: cannot size expression Fixes: 705ececd1c60 ("Staging: add line6 usb driver") Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variantsAnssi Hannula
commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream. The DragonFly quirk added in 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly") applies a custom dB map on the volume control when its range is reported as 0..50 (0 .. 0.2dB). However, there exists at least one other variant (hw v1.0c, as opposed to the tested v1.2) which reports a different non-sensical volume range (0..53) and the custom map is therefore not applied for that device. This results in all of the volume change appearing close to 100% on mixer UIs that utilize the dB TLV information. Add a fallback case where no dB TLV is reported at all if the control range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also restrict the quirk to only apply to the volume control as there is also a mute control which would match the check otherwise. Fixes: 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly") Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi> Reported-by: David W <regulars@d-dub.org.uk> Tested-by: David W <regulars@d-dub.org.uk> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16ALSA: ali5451: Fix out-of-bound position reportingTakashi Iwai
commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream. The pointer callbacks of ali5451 driver may return the value at the boundary occasionally, and it results in the kernel warning like snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024 It seems that folding the position offset is enough for fixing the warning and no ill-effect has been seen by that. Reported-by: Enrico Mioso <mrkiko.rs@gmail.com> Tested-by: Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16timekeeping: Fix __ktime_get_fast_ns() regressionJohn Stultz
commit 58bfea9532552d422bde7afa207e1a0f08dffa7d upstream. In commit 27727df240c7 ("Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code the timekeeping_get_ns() function, but I forgot to include the unit conversion from cycles to nanoseconds, breaking the function's output, which impacts users like perf. This results in bogus perf timestamps like: swapper 0 [000] 253.427536: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426573: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426687: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426800: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.426905: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427022: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427127: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427239: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427346: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 254.427463: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 255.426572: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) Instead of more reasonable expected timestamps like: swapper 0 [000] 39.953768: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.064839: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.175956: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.287103: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.398217: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.509324: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.620437: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.731546: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.842654: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 40.953772: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) swapper 0 [000] 41.064881: 111111111 cpu-clock: ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms]) Add the proper use of timekeeping_delta_to_ns() to convert the cycle delta to nanoseconds as needed. Thanks to Brendan and Alexei for finding this quickly after the v4.8 release. Unfortunately the problematic commit has landed in some -stable trees so they'll need this fix as well. Many apologies for this mistake. I'll be looking to add a perf-clock sanity test to the kselftest timers tests soon. Fixes: 27727df240c7 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING" Reported-by: Brendan Gregg <bgregg@netflix.com> Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Tested-and-reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-16time: Add cycles to nanoseconds translationChristopher S. Hall
commit 6bd58f09e1d8cc6c50a824c00bf0d617919986a1 upstream. The timekeeping code does not currently provide a way to translate externally provided clocksource cycles to system time. The cycle count is always provided by the result clocksource read() method internal to the timekeeping code. The added function timekeeping_cycles_to_ns() calculated a nanosecond value from a cycle count that can be added to tk_read_base.base value yielding the current system time. This allows clocksource cycle values external to the timekeeping code to provide a cycle count that can be transformed to system time. Cc: Prarit Bhargava <prarit@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: kevin.b.stanton@intel.com Cc: kevin.j.clarke@intel.com Cc: hpa@zytor.com Cc: jeffrey.t.kirsher@intel.com Cc: netdev@vger.kernel.org Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Christopher S. Hall <christopher.s.hall@intel.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07Linux 4.4.24v4.4.24Greg Kroah-Hartman
2016-10-07ALSA: hda - Add the top speaker pin config for HP Spectre x360Takashi Iwai
commit 0eec880966e77bdbee0112989a2be67d92e39929 upstream. HP Spectre x360 with CX20724 codec has two speaker outputs while the BIOS sets up only the bottom one (NID 0x17) and disables the top one (NID 0x1d). This patch adds a fixup simply defining the proper pincfg for NID 0x1d so that the top speaker works as is. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=169071 Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07ALSA: hda - Fix headset mic detection problem for several Dell laptopsHui Wang
commit 3f640970a41429f0a076c01270bbd014c9eae61c upstream. One of the laptops has the codec ALC256 on it, applying the ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem, the rest of laptops have the codec ALC295 on them, they are similar to machines with ALC225, applying the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem. Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07ACPICA: acpi_get_sleep_type_data: Reduce warningsPrarit Bhargava
commit a59b679ab85635737947310323f2f2bcfa0664a7 upstream. ACPICA commit 7bb77313091e52a846df4c9c2bea90be31bfb9d8 Eliminate warnings for "not found" _Sx errors, since these are optional. Original NOT_FOUND status is still returned. Original changes by Prarit Bhargava. ACPICA BZ 1208. Link: https://github.com/acpica/acpica/commit/7bb77313 Link: https://bugs.acpica.org/show_bug.cgi?id=1208 Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: "Charles (Chas) Williams" <ciwillia@brocade.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07ALSA: hda - Adding one more ALC255 pin definition for headset problemHui Wang
commit 392c9da24a994f238c5d7ea611c6245be4617014 upstream. We have two new Dell laptop models, they have the same ALC255 pin definition, but not in the pin quirk table yet, as a result, the headset microphone can't work. After adding the definition in the table, the headset microphone works well. Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07Revert "usbtmc: convert to devm_kzalloc"Greg Kroah-Hartman
commit ab21b63e8aedfc73565dd9cdd51eb338341177cb upstream. This reverts commit e6c7efdcb76f11b04e3d3f71c8d764ab75c9423b. Turns out it was totally wrong. The memory is supposed to be bound to the kref, as the original code was doing correctly, not the device/driver binding as the devm_kzalloc() would cause. This fixes an oops when read would be called after the device was unbound from the driver. Reported-by: Ladislav Michl <ladis@linux-mips.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07USB: serial: cp210x: Add ID for a Juniper consoleKyle Jones
commit decc5360f23e9efe0252094f47f57f254dcbb3a9 upstream. Signed-off-by: Kyle Jones <kyle@kf5jwc.us> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07Staging: fbtft: Fix bug in fbtft-coreKsenija Stanojevic
commit fc1e2c8ea85e109acf09e74789e9b852f6eed251 upstream. Commit 367e8560e8d7a62d96e9b1d644028a3816e04206 introduced a bug in fbtft-core where fps is always 0, this is because variable update_time is not assigned correctly. Signed-off-by: Ksenija Stanojevic <ksenija.stanojevic@gmail.com> Fixes: 367e8560e8d7 ("Staging: fbtbt: Replace timespec with ktime_t") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07usb: misc: legousbtower: Fix NULL pointer deferenceGreg Kroah-Hartman
commit 2fae9e5a7babada041e2e161699ade2447a01989 upstream. This patch fixes a NULL pointer dereference caused by a race codition in the probe function of the legousbtower driver. It re-structures the probe function to only register the interface after successfully reading the board's firmware ID. The probe function does not deregister the usb interface after an error receiving the devices firmware ID. The device file registered (/dev/usb/legousbtower%d) may be read/written globally before the probe function returns. When tower_delete is called in the probe function (after an r/w has been initiated), core dev structures are deleted while the file operation functions are still running. If the 0 address is mappable on the machine, this vulnerability can be used to create a Local Priviege Escalation exploit via a write-what-where condition by remapping dev->interrupt_out_buffer in tower_write. A forged USB device and local program execution would be required for LPE. The USB device would have to delay the control message in tower_probe and accept the control urb in tower_open whilst guest code initiated a write to the device file as tower_delete is called from the error in tower_probe. This bug has existed since 2003. Patch tested by emulated device. Reported-by: James Patrick-Evans <james@jmp-e.com> Tested-by: James Patrick-Evans <james@jmp-e.com> Signed-off-by: James Patrick-Evans <james@jmp-e.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07USB: serial: cp210x: fix hardware flow-control disableKonstantin Shkolnyy
commit a377f9e906af4df9071ba8ddba60188cb4013d93 upstream. A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS is transmit active signal" and CRTSCTS=1 => "RTS is used for receive flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS is used for receive flow control" This only happened after first having enabled CRTSCTS. Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Fixes: 39a66b8d22a3 ("[PATCH] USB: CP2101 Add support for flow control") [johan: reword commit message ] Signed-off-by: Johan Hovold <johan@kernel.org> [johan: backport to 4.4 ] Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07dm log writes: fix bug with too large biosMikulas Patocka
commit 7efb367320f56fc4d549875b6f3a6940018ef2e5 upstream. bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector entries. However, the incoming bio may have more vector entries if it was allocated by other means. For example, bcache submits bios with more than BIO_MAX_PAGES entries. This results in bio_alloc() failure. To avoid the failure, change the code so that it allocates bio with at most BIO_MAX_PAGES entries. If the incoming bio has more entries, bio_add_page() will fail and a new bio will be allocated - the code that handles bio_add_page() failure already exists in the dm-log-writes target. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07clk: xgene: Add missing parenthesis when clearing divider valueLoc Ho
commit 0f4c7a138dfefb0ebdbaf56e3ba2acd2958a6605 upstream. In the initial fix for non-zero divider shift value, the parenthesis was missing after the negate operation. This patch adds the required parenthesis. Otherwise, lower bits may be cleared unintentionally. Signed-off-by: Loc Ho <lho@apm.com> Acked-by: Toan Le <toanle@apm.com> Fixes: 1382ea631ddd ("clk: xgene: Fix divider with non-zero shift value") Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07aio: mark AIO pseudo-fs noexecJann Horn
commit 22f6b4d34fcf039c63a94e7670e0da24f8575a5a upstream. This ensures that do_mmap() won't implicitly make AIO memory mappings executable if the READ_IMPLIES_EXEC personality flag is set. Such behavior is problematic because the security_mmap_file LSM hook doesn't catch this case, potentially permitting an attacker to bypass a W^X policy enforced by SELinux. I have tested the patch on my machine. To test the behavior, compile and run this: #define _GNU_SOURCE #include <unistd.h> #include <sys/personality.h> #include <linux/aio_abi.h> #include <err.h> #include <stdlib.h> #include <stdio.h> #include <sys/syscall.h> int main(void) { personality(READ_IMPLIES_EXEC); aio_context_t ctx = 0; if (syscall(__NR_io_setup, 1, &ctx)) err(1, "io_setup"); char cmd[1000]; sprintf(cmd, "cat /proc/%d/maps | grep -F '/[aio]'", (int)getpid()); system(cmd); return 0; } In the output, "rw-s" is good, "rwxs" is bad. Signed-off-by: Jann Horn <jann@thejh.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07batman-adv: remove unused callback from batadv_algo_ops structMarek Lindner
commit d9f179877e50ae2681fe7b0b83e0d9f63b6165ad upstream. Reported-by: Lars Bußmann <ffsoest@kill-you.net> Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch> [sven@narfation.org: rewritten commit message to make clear that it is an bugfix to an user reported crash] Signed-off-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07IB/mlx4: Use correct subnet-prefix in QP1 mads under SR-IOVJack Morgenstein
commit 8ec07bf8a8b57d6c58927a16a0a22c0115cf2855 upstream. When sending QP1 MAD packets which use a GRH, the source GID (which consists of the 64-bit subnet prefix, and the 64 bit port GUID) must be included in the packet GRH. For SR-IOV, a GID cache is used, since the source GID needs to be the slave's source GID, and not the Hypervisor's GID. This cache also included a subnet_prefix. Unfortunately, the subnet_prefix field in the cache was never initialized (to the default subnet prefix 0xfe80::0). As a result, this field remained all zeroes. Therefore, when SR-IOV was active, all QP1 packets which included a GRH had a source GID subnet prefix of all-zeroes. However, the subnet-prefix should initially be 0xfe80::0 (the default subnet prefix). In addition, if OpenSM modifies a port's subnet prefix, the new subnet prefix must be used in the GRH when sending QP1 packets. To fix this we now initialize the subnet prefix in the SR-IOV GID cache to the default subnet prefix. We update the cached value if/when OpenSM modifies the port's subnet prefix. We take this cached value when sending QP1 packets when SR-IOV is active. Note that the value is stored as an atomic64. This eliminates any need for locking when the subnet prefix is being updated. Note also that we depend on the FW generating the "port management change" event for tracking subnet-prefix changes performed by OpenSM. If running early FW (before 2.9.4630), subnet prefix changes will not be tracked (but the default subnet prefix still will be stored in the cache; therefore users who do not modify the subnet prefix will not have a problem). IF there is a need for such tracking also for early FW, we will add that capability in a subsequent patch. Fixes: 1ffeb2eb8be9 ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07IB/mlx4: Fix code indentation in QP1 MAD flowJack Morgenstein
commit baa0be7026e2f7d1d40bfd45909044169e9e3c68 upstream. The indentation in the QP1 GRH flow in procedure build_mlx_header is really confusing. Fix it, in preparation for a commit which touches this code. Fixes: 1ffeb2eb8be9 ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07IB/mlx4: Fix incorrect MC join state bit-masking on SR-IOVAlex Vesker
commit e5ac40cd66c2f3cd11bc5edc658f012661b16347 upstream. Because of an incorrect bit-masking done on the join state bits, when handling a join request we failed to detect a difference between the group join state and the request join state when joining as send only full member (0x8). This caused the MC join request not to be sent. This issue is relevant only when SRIOV is enabled and SM supports send only full member. This fix separates scope bits and join states bits a nibble each. Fixes: b9c5d6a64358 ('IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV') Signed-off-by: Alex Vesker <valex@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07IB/ipoib: Don't allow MC joins during light MC flushAlex Vesker
commit 344bacca8cd811809fc33a249f2738ab757d327f upstream. This fix solves a race between light flush and on the fly joins. Light flush doesn't set the device to down and unset IPOIB_OPER_UP flag, this means that if while flushing we have a MC join in progress and the QP was attached to BC MGID we can have a mismatches when re-attaching a QP to the BC MGID. The light flush would set the broadcast group to NULL causing an on the fly join to rejoin and reattach to the BC MCG as well as adding the BC MGID to the multicast list. The flush process would later on remove the BC MGID and detach it from the QP. On the next flush the BC MGID is present in the multicast list but not found when trying to detach it because of the previous double attach and single detach. [18332.714265] ------------[ cut here ]------------ [18332.717775] WARNING: CPU: 6 PID: 3767 at drivers/infiniband/core/verbs.c:280 ib_dealloc_pd+0xff/0x120 [ib_core] ... [18332.775198] Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011 [18332.779411] 0000000000000000 ffff8800b50dfbb0 ffffffff813fed47 0000000000000000 [18332.784960] 0000000000000000 ffff8800b50dfbf0 ffffffff8109add1 0000011832f58300 [18332.790547] ffff880226a596c0 ffff880032482000 ffff880032482830 ffff880226a59280 [18332.796199] Call Trace: [18332.798015] [<ffffffff813fed47>] dump_stack+0x63/0x8c [18332.801831] [<ffffffff8109add1>] __warn+0xd1/0xf0 [18332.805403] [<ffffffff8109aebd>] warn_slowpath_null+0x1d/0x20 [18332.809706] [<ffffffffa025d90f>] ib_dealloc_pd+0xff/0x120 [ib_core] [18332.814384] [<ffffffffa04f3d7c>] ipoib_transport_dev_cleanup+0xfc/0x1d0 [ib_ipoib] [18332.820031] [<ffffffffa04ed648>] ipoib_ib_dev_cleanup+0x98/0x110 [ib_ipoib] [18332.825220] [<ffffffffa04e62c8>] ipoib_dev_cleanup+0x2d8/0x550 [ib_ipoib] [18332.830290] [<ffffffffa04e656f>] ipoib_uninit+0x2f/0x40 [ib_ipoib] [18332.834911] [<ffffffff81772a8a>] rollback_registered_many+0x1aa/0x2c0 [18332.839741] [<ffffffff81772bd1>] rollback_registered+0x31/0x40 [18332.844091] [<ffffffff81773b18>] unregister_netdevice_queue+0x48/0x80 [18332.848880] [<ffffffffa04f489b>] ipoib_vlan_delete+0x1fb/0x290 [ib_ipoib] [18332.853848] [<ffffffffa04df1cd>] delete_child+0x7d/0xf0 [ib_ipoib] [18332.858474] [<ffffffff81520c08>] dev_attr_store+0x18/0x30 [18332.862510] [<ffffffff8127fe4a>] sysfs_kf_write+0x3a/0x50 [18332.866349] [<ffffffff8127f4e0>] kernfs_fop_write+0x120/0x170 [18332.870471] [<ffffffff81207198>] __vfs_write+0x28/0xe0 [18332.874152] [<ffffffff810e09bf>] ? percpu_down_read+0x1f/0x50 [18332.878274] [<ffffffff81208062>] vfs_write+0xa2/0x1a0 [18332.881896] [<ffffffff812093a6>] SyS_write+0x46/0xa0 [18332.885632] [<ffffffff810039b7>] do_syscall_64+0x57/0xb0 [18332.889709] [<ffffffff81883321>] entry_SYSCALL64_slow_path+0x25/0x25 [18332.894727] ---[ end trace 09ebbe31f831ef17 ]--- Fixes: ee1e2c82c245 ("IPoIB: Refresh paths instead of flushing them on SM change events") Signed-off-by: Alex Vesker <valex@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07IB/core: Fix use after free in send_leave functionErez Shitrit
commit 68c6bcdd8bd00394c234b915ab9b97c74104130c upstream. The function send_leave sets the member: group->query_id (group->query_id = ret) after calling the sa_query, but leave_handler can be executed before the setting and it might delete the group object, and will get a memory corruption. Additionally, this patch gets rid of group->query_id variable which is not used. Fixes: faec2f7b96b5 ('IB/sa: Track multicast join/leave requests') Signed-off-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07IB/ipoib: Fix memory corruption in ipoib cm mode connect flowErez Shitrit
commit 546481c2816ea3c061ee9d5658eb48070f69212e upstream. When a new CM connection is being requested, ipoib driver copies data from the path pointer in the CM/tx object, the path object might be invalid at the point and memory corruption will happened later when now the CM driver will try using that data. The next scenario demonstrates it: neigh_add_path --> ipoib_cm_create_tx --> queue_work (pointer to path is in the cm/tx struct) #while the work is still in the queue, #the port goes down and causes the ipoib_flush_paths: ipoib_flush_paths --> path_free --> kfree(path) #at this point the work scheduled starts. ipoib_cm_tx_start --> copy from the (invalid)path pointer: (memcpy(&pathrec, &p->path->pathrec, sizeof pathrec);) -> memory corruption. To fix that the driver now starts the CM/tx connection only if that specific path exists in the general paths database. This check is protected with the relevant locks, and uses the gid from the neigh member in the CM/tx object which is valid according to the ref count that was taken by the CM/tx. Fixes: 839fcaba35 ('IPoIB: Connected mode experimental support') Signed-off-by: Erez Shitrit <erezsh@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE writeRadim Krčmář
commit dccbfcf52cebb8963246eba5b177b77f26b34da0 upstream. If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the write with vmcs02 as the current VMCS. This will incorrectly apply modifications intended for vmcs01 to vmcs02 and L2 can use it to gain access to L0's x2APIC registers by disabling virtualized x2APIC while using msr bitmap that assumes enabled. Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the current VMCS. An alternative solution would temporarily make vmcs01 the current VMCS, but it requires more care. Fixes: 8d14695f9542 ("x86, apicv: add virtual x2apic support") Reported-by: Jim Mattson <jmattson@google.com> Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07dmaengine: at_xdmac: fix to pass correct device identity to free_irq()Wei Yongjun
commit 6a8b0c6b18f62a277ffb2139d0c0253fe35d7feb upstream. free_irq() expects the same device identity that was passed to corresponding request_irq(), otherwise the IRQ is not freed. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com> Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscdMichal Hocko
commit 735f2770a770156100f534646158cb58cb8b2939 upstream. Commit fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID to clear the nscd_certainly_running flag in the shared databases, so that the clients are notified when nscd is restarted. Now, when nscd uses a non-persistent database, clients that have it mapped keep thinking the database is being updated by nscd, when in fact nscd has created a new (anonymous) one (for non-persistent databases it uses an unlinked file as backend). The original proposal for the CLONE_CHILD_CLEARTID change claimed (https://lkml.org/lkml/2006/10/25/233): : The NPTL library uses the CLONE_CHILD_CLEARTID flag on clone() syscalls : on behalf of pthread_create() library calls. This feature is used to : request that the kernel clear the thread-id in user space (at an address : provided in the syscall) when the thread disassociates itself from the : address space, which is done in mm_release(). : : Unfortunately, when a multi-threaded process incurs a core dump (such as : from a SIGSEGV), the core-dumping thread sends SIGKILL signals to all of : the other threads, which then proceed to clear their user-space tids : before synchronizing in exit_mm() with the start of core dumping. This : misrepresents the state of process's address space at the time of the : SIGSEGV and makes it more difficult for someone to debug NPTL and glibc : problems (misleading him/her to conclude that the threads had gone away : before the fault). : : The fix below is to simply avoid the CLONE_CHILD_CLEARTID action if a : core dump has been initiated. The resulting patch from Roland (https://lkml.org/lkml/2006/10/26/269) seems to have a larger scope than the original patch asked for. It seems that limitting the scope of the check to core dumping should work for SIGSEGV issue describe above. [Changelog partly based on Andreas' description] Fixes: fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") Link: http://lkml.kernel.org/r/1471968749-26173-1-git-send-email-mhocko@kernel.org Signed-off-by: Michal Hocko <mhocko@suse.com> Tested-by: William Preston <wpreston@suse.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Andreas Schwab <schwab@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07ASoC: omap-mcpdm: Fix irq resource handlingPeter Ujfalusi
commit a8719670687c46ed2e904c0d05fa4cd7e4950cd1 upstream. Fixes: ddd17531ad908 ("ASoC: omap-mcpdm: Clean up with devm_* function") Managed irq request will not doing any good in ASoC probe level as it is not going to free up the irq when the driver is unbound from the sound card. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07sysctl: handle error writing UINT_MAX to u32 fieldsSubash Abhinov Kasiviswanathan
commit e7d316a02f683864a12389f8808570e37fb90aa3 upstream. We have scripts which write to certain fields on 3.18 kernels but this seems to be failing on 4.4 kernels. An entry which we write to here is xfrm_aevent_rseqth which is u32. echo 4294967295 > /proc/sys/net/core/xfrm_aevent_rseqth Commit 230633d109e3 ("kernel/sysctl.c: detect overflows when converting to int") prevented writing to sysctl entries when integer overflow occurs. However, this does not apply to unsigned integers. Heinrich suggested that we introduce a new option to handle 64 bit limits and set min as 0 and max as UINT_MAX. This might not work as it leads to issues similar to __do_proc_doulongvec_minmax. Alternatively, we would need to change the datatype of the entry to 64 bit. static int __do_proc_doulongvec_minmax(void *data, struct ctl_table { i = (unsigned long *) data; //This cast is causing to read beyond the size of data (u32) vleft = table->maxlen / sizeof(unsigned long); //vleft is 0 because maxlen is sizeof(u32) which is lesser than sizeof(unsigned long) on x86_64. Introduce a new proc handler proc_douintvec. Individual proc entries will need to be updated to use the new handler. [akpm@linux-foundation.org: coding-style fixes] Fixes: 230633d109e3 ("kernel/sysctl.c:detect overflows when converting to int") Link: http://lkml.kernel.org/r/1471479806-5252-1-git-send-email-subashab@codeaurora.org Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Kees Cook <keescook@chromium.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07powerpc/prom: Fix sub-processor option passed to ibm, ↵Michael Ellerman
client-architecture-support commit 66443efa83dc73775100b7442962ce2cb0d4472e upstream. When booting from an OpenFirmware which supports it, we use the "ibm,client-architecture-support" firmware call to communicate our capabilities to firmware. The format of the structure we pass to firmware is specified in PAPR (Power Architecture Platform Requirements), or the public version LoPAPR (Linux on Power Architecture Platform Reference). Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte field at bytes 17-20 for the "Platform Facilities Enable". This is followed by a 1 byte field at byte 21 for "Sub-Processor Represenation Level". Comparing to the code, there we have the Platform Facilities options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is incorrectly placed at byte 18. Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes to hopefully make it clearer in future. As far as I'm aware nothing actually consumes this value at this time, so the effect of this bug is nil in practice. It does mean we've been incorrectly setting bit 15 of the "Platform Facilities Enable" option for the past ~3 1/2 years, so we should avoid allocating that bit to anything else in future. Fixes: df77c7992029 ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()Florian Fainelli
commit f823a2aa8f4674c095a5413b9e3ba12d82df06f2 upstream. wlc_phy_txpower_get_current() does a logical OR of power->flags, which presumes that power.flags was initiliazed earlier by the caller, unfortunately, this is not the case, so make sure we zero out the struct tx_power before calling into wlc_phy_txpower_get_current(). Reported-by: coverity (CID 146011) Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-07brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfillFlorian Fainelli
commit 5c5fa1f464ac954982df1d96b9f9a5103d21aedd upstream. In case dma_mapping_error() returns an error in dma_rxfill, we would be leaking a packet that we allocated with brcmu_pkt_buf_get_skb(). Reported-by: coverity (CID 1081819) Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-05-24 10:41:42 +0000