aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2018-04-27kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in useJunaid Shahid1-10/+4
Currently, KVM flushes the TLB after a change to the APIC access page address or the APIC mode when EPT mode is enabled. However, even in shadow paging mode, a TLB flush is needed if VPIDs are being used, as specified in the Intel SDM Section 29.4.5. So replace vmx_flush_tlb_ept_only() with vmx_flush_tlb(), which will flush if either EPT or VPIDs are in use. Signed-off-by: Junaid Shahid <junaids@google.com> Reviewed-by: Jim Mattson <jmattson@google.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2018-04-27i2c: sprd: Fix the i2c count issueBaolin Wang1-4/+2
We found the I2C controller count register is unreliable sometimes, that will cause I2C to lose data. Thus we can read the data count from 'i2c_dev->count' instead of the I2C controller count register. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-04-27i2c: sprd: Prevent i2c accesses after suspend is calledBaolin Wang1-0/+16
Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-04-27i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()Alexander Popov1-1/+1
i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which returns ZERO_SIZE_PTR if i2c_msg.len is zero. Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case of I2C_M_RD | I2C_M_RECV_LEN transfer. That causes a kernel oops in case of zero len. Let's check the len against zero before dereferencing buf pointer. This issue was triggered by syzkaller. Signed-off-by: Alexander Popov <alex.popov@linux.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [wsa: use '< 1' instead of '!' for easier readability] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-04-27arm64: avoid instrumenting atomic_ll_sc.oMark Rutland1-0/+4
Our out-of-line atomics are built with a special calling convention, preventing pointless stack spilling, and allowing us to patch call sites with ARMv8.1 atomic instructions. Instrumentation inserted by the compiler may result in calls to functions not following this special calling convention, resulting in registers being unexpectedly clobbered, and various problems resulting from this. For example, if a kernel is built with KCOV and ARM64_LSE_ATOMICS, the compiler inserts calls to __sanitizer_cov_trace_pc in the prologues of the atomic functions. This has been observed to result in spurious cmpxchg failures, leading to a hang early on in the boot process. This patch avoids such issues by preventing instrumentation of our out-of-line atomics. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-04-27powerpc/kvm/booke: Fix altivec related build breakLaurentiu Tudor1-0/+7
Add missing "altivec unavailable" interrupt injection helper thus fixing the linker error below: arch/powerpc/kvm/emulate_loadstore.o: In function `kvmppc_check_altivec_disabled': arch/powerpc/kvm/emulate_loadstore.c: undefined reference to `.kvmppc_core_queue_vec_unavail' Fixes: 09f984961c137c4b ("KVM: PPC: Book3S: Add MMIO emulation for VMX instructions") Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-04-27powerpc: Fix deadlock with multiple calls to smp_send_stopNicholas Piggin1-16/+39
smp_send_stop can lock up the IPI path for any subsequent calls, because the receiving CPUs spin in their handler function. This started becoming a problem with the addition of an smp_send_stop call in the reboot path, because panics can reboot after doing their own smp_send_stop. The NMI IPI variant was fixed with ac61c11566 ("powerpc: Fix smp_send_stop NMI IPI handling"), which leaves the smp_call_function variant. This is fixed by having smp_send_stop only ever do the smp_call_function once. This is a bit less robust than the NMI IPI fix, because any other call to smp_call_function after smp_send_stop could deadlock, but that has always been the case, and it was not been a problem before. Fixes: f2748bdfe1573 ("powerpc/powernv: Always stop secondaries before reboot/shutdown") Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-04-27cpufreq: powernv: Fix hardlockup due to synchronous smp_call in timer interruptShilpasri G Bhat1-3/+11
gpstate_timer_handler() uses synchronous smp_call to set the pstate on the requested core. This causes the below hard lockup: smp_call_function_single+0x110/0x180 (unreliable) smp_call_function_any+0x180/0x250 gpstate_timer_handler+0x1e8/0x580 call_timer_fn+0x50/0x1c0 expire_timers+0x138/0x1f0 run_timer_softirq+0x1e8/0x270 __do_softirq+0x158/0x3e4 irq_exit+0xe8/0x120 timer_interrupt+0x9c/0xe0 decrementer_common+0x114/0x120 -- interrupt: 901 at doorbell_global_ipi+0x34/0x50 LR = arch_send_call_function_ipi_mask+0x120/0x130 arch_send_call_function_ipi_mask+0x4c/0x130 smp_call_function_many+0x340/0x450 pmdp_invalidate+0x98/0xe0 change_huge_pmd+0xe0/0x270 change_protection_range+0xb88/0xe40 mprotect_fixup+0x140/0x340 SyS_mprotect+0x1b4/0x350 system_call+0x58/0x6c One way to avoid this is removing the smp-call. We can ensure that the timer always runs on one of the policy-cpus. If the timer gets migrated to a cpu outside the policy then re-queue it back on the policy->cpus. This way we can get rid of the smp-call which was being used to set the pstate on the policy->cpus. Fixes: 7bc54b652f13 ("timers, cpufreq/powernv: Initialize the gpstate timer as pinned") Cc: stable@vger.kernel.org # v4.8+ Reported-by: Nicholas Piggin <npiggin@gmail.com> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Acked-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-04-26mtd: rawnand: marvell: fix the chip-select DT parsing logicMiquel Raynal1-17/+8
The block responsible of parsing the DT for the number of chip-select lines uses an 'if/else if/else if' block. The content of the second and third 'else if' conditions are: 1/ the actual condition to enter the sub-block and 2/ the operation to do in this sub-block. [...] else if (condition1_to_enter && action1() == failed) raise_error(); else if (condition2_to_enter && action2() == failed) raise_error(); [...] In case of failure, the sub-block is entered and an error raised. Otherwise, in case of success, the code would continue erroneously in the next 'else if' statement because it did not failed (and did not enter the first 'else if' sub-block). The first 'else if' refers to legacy bindings while the second 'else if' refers to new bindings. The second 'else if', which is entered erroneously, checks for the 'reg' property, which, for old bindings, does not mean anything because it would not be the number of CS available, but the regular register map of almost any DT node. This being said, the content of the 'reg' property being the register map offset and length, it has '2' values, so the number of CS in this situation is assumed to be '2'. When running nand_scan_ident() with 2 CS, the core will check for an array of chips. It will first issue a RESET and then a READ_ID. Of course this will trigger two timeouts because there is no chip in front of the second CS: [ 1.367460] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000080) [ 1.474292] marvell-nfc f2720000.nand: Timeout on CMDD (NDSR: 0x00000280) Indeed, this is harmless and the core will then assume there is only one valid CS. Fix the logic in the whole block by entering each sub-block just on the 'is legacy' condition, doing the action inside the sub-block. This way, when the action succeeds, the whole block is left. Furthermore, for both the old bindings and the new bindings the same logic was applied to retrieve the number of CS lines: using of_get_property() to get a size in bytes, converted in the actual number of lines by dividing it per sizeof(u32) (4 bytes). This is fine for the 'reg' property which is a list of the CS IDs but not for the 'num-cs' property which is directly the value of the number of CS. Anyway, no existing DT uses another value than 'num-cs = <1>' and no other value has ever been supported by the old driver (pxa3xx_nand.c). Remove this condition and apply a number of 1 CS anyway, as already described in the bindings. Finally, the 'reg' property of a 'nand' node (with the new bindings) gives the IDs of each CS line in use. marvell_nand.c driver first look at the number of CS lines that are present in this property. Better use of_property_count_elems_of_size() than dividing by 4 the size of the number of bytes returned by of_get_property(). Fixes: 02f26ecf8c772 ("mtd: nand: add reworked Marvell NAND controller driver") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
2018-04-26KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_mmio_read_apr()Mark Rutland1-0/+5
It's possible for userspace to control n. Sanitize n when using it as an array index. Note that while it appears that n must be bound to the interval [0,3] due to the way it is extracted from addr, we cannot guarantee that compiler transformations (and/or future refactoring) will ensure this is the case, and given this is a slow path it's better to always perform the masking. Found by smatch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: kvmarm@lists.cs.columbia.edu Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-04-26KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_get_irq()Mark Rutland1-4/+10
It's possible for userspace to control intid. Sanitize intid when using it as an array index. At the same time, sort the includes when adding <linux/nospec.h>. Found by smatch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Christoffer Dall <christoffer.dall@arm.com> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Cc: kvmarm@lists.cs.columbia.edu Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-04-26arm64: fix possible spectre-v1 in ptrace_hbp_get_event()Mark Rutland1-4/+10
It's possible for userspace to control idx. Sanitize idx when using it as an array index. Found by smatch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-04-26libceph: validate con->state at the top of try_write()Ilya Dryomov1-0/+7
ceph_con_workfn() validates con->state before calling try_read() and then try_write(). However, try_read() temporarily releases con->mutex, notably in process_message() and ceph_con_in_msg_alloc(), opening the window for ceph_con_close() to sneak in, close the connection and release con->sock. When try_write() is called on the assumption that con->state is still valid (i.e. not STANDBY or CLOSED), a NULL sock gets passed to the networking stack: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: selinux_socket_sendmsg+0x5/0x20 Make sure con->state is valid at the top of try_write() and add an explicit BUG_ON for this, similar to try_read(). Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/23706 Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Jason Dillaman <dillaman@redhat.com>
2018-04-26ARM: defconfig: Update Gemini defconfigLinus Walleij1-2/+25
This updates the Gemini defconfig with a config that will bring up most of the recently merged and updated devices to some functional level: - We enable high resolution timers (the right thing to do) - Enable CMA for the framebuffer, and the new TVE200 framebuffer driver and the Ilitek ILI9322 driver for graphics on the D-Link DIR-685. HIGHMEM support comes in as part of this. - Enable networking and the new Cortina Gemini ethernet driver. - Enable MDIO over GPIO and the Realtek PHY devices used on several of these systems. - Enable I2C over GPIO and SPI over GPIO which is used on several of these devices. - Enable the Thermal framework, GPIO fan control and LM75 sensor adding cooling on the D-Link DNS-313 with no userspace involved even if only the kernel is working, rock solid thermal for this platform. - Enable JEDEC flash probing to support the Eon flash chip in D-Link DNS-313. - Enable LED disk triggers for the NAS type devices. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-04-26ARM: s3c24xx: jive: Fix some GPIO namesLinus Walleij1-2/+2
One of the bitbanged SPI hosts had wrongly named GPIO lines due to sloppiness by yours truly. Cc: arm@kernel.org Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-04-26HISI LPC: Add Kconfig MFD_CORE dependencyJohn Garry1-0/+1
For ACPI support of the HiSilicon LPC driver we depend on MFD_CORE config. Currently the HiSi LPC Kconfig entry does not define this dependency, so add it. The reason for depending on MFD_CORE in the driver is that we model the LPC host as an MFD, in that a platform device will be created for each device on the bus. We do this as we need to modify the resources of these derived platform devices, something which we should not do to the original devices created in the ACPI scan. Details in e0aa1563f894 ("HISI LPC: Add ACPI support"). Fixes: e0aa1563f894 ("HISI LPC: Add ACPI support") Reported-and-tested-by: Tan Xiaojun <tanxiaojun@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-04-26ARM: dts: Fix NAS4220B pin configLinus Walleij1-14/+14
The DTS file for the NAS4220B had the pin config for the ethernet interface set to the pins in the SL3512 SoC while this system is using SL3516. Fix it by referencing the right SL3516 pins instead of the SL3512 pins. Cc: stable@vger.kernel.org Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com> Reported-by: Andreas Fiedler <andreas.fiedler@gmx.net> Reported-by: Roman Yeryomin <roman@advem.lv> Tested-by: Roman Yeryomin <roman@advem.lv> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-04-26MAINTAINERS: Remove myself as maintainerNiklas Cassel1-2/+0
I am leaving Axis, so this address will bounce in the not too distant future. Fortunately, I will still be working with the community. Signed-off-by: Niklas Cassel <niklas.cassel@axis.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-04-26ALSA: dice: fix error path to destroy initialized stream dataTakashi Sakamoto1-1/+1
In error path of snd_dice_stream_init_duplex(), stream data for incoming packet can be left to be initialized. This commit fixes it. Fixes: 436b5abe2224 ('ALSA: dice: handle whole available isochronous streams') Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-04-26ARM: amba: Fix race condition with driver_overrideGeert Uytterhoeven1-2/+9
The driver_override implementation is susceptible to a race condition when different threads are reading vs storing a different driver override. Add locking to avoid this race condition. Cfr. commits 6265539776a0810b ("driver core: platform: fix race condition with driver_override") and 9561475db680f714 ("PCI: Fix race condition with driver_override"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-26ARM: amba: Make driver_override output consistent with other busesGeert Uytterhoeven1-3/+0
For AMBA devices with unconfigured driver override, the "driver_override" sysfs virtual file is empty, while it contains "(null)" for platform and PCI devices. Make AMBA consistent with other buses by dropping the test for a NULL pointer. Note that contrary to popular belief, sprintf() handles NULL pointers fine; they are printed as "(null)". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable <stable@vger.kernel.org> Reviewed-by: Todd Kjos <tkjos@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-26Revert "ARM: amba: Fix race condition with driver_override"Greg Kroah-Hartman1-9/+2
This reverts commit 6b614a87f3f477571e319281e84dba11e0ea0a76. My backport was incorrect, as Geert pointed out :( Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-25drm/edid: Reset more of the display infoVille Syrjälä1-8/+3
We're currently failing to reset everything in display_info.hdmi which will potentially cause us to use stale information when swapping monitors. Eg. if the user replaces a HDMI 2.0 monitor with a HDMI 1.x monitor we will continue to think that the monitor supports scrambling. That will lead to a black screen since the HDMI 1.x monitor won't understand the scrambled signal. Fix the problem by clearing display_info.hdmi fully. And while at eliminate some duplicated code by calling drm_reset_display_info() in drm_add_display_info(). Cc: stable@vger.kernel.org Cc: Antony Chen <antonychen@qnap.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105655 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180424130250.7028-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Antony Chen <antonychen@qnap.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-04-25drm/virtio: fix vq wait_event conditionGerd Hoffmann1-2/+2
Wait until we have enough space in the virt queue to actually queue up our request. Avoids the guest spinning in case we have a non-zero amount of free entries but not enough for the request. Cc: stable@vger.kernel.org Reported-by: Alain Magloire <amagloire@blackberry.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20180403095904.11152-1-kraxel@redhat.com Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-04-25qxl: keep separate release_bo pointerGerd Hoffmann3-10/+9
qxl expects that list_first_entry(release->bos) returns the first element qxl added to the list. ttm_eu_reserve_buffers() may reorder the list though. Add a release_bo field to struct qxl_release and use that instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180418054257.15388-3-kraxel@redhat.com Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-04-25qxl: fix qxl_release_{map,unmap}Gerd Hoffmann2-5/+5
s/PAGE_SIZE/PAGE_MASK/ Luckily release_offset is never larger than PAGE_SIZE, so the bug has no bad side effects and managed to stay unnoticed for years that way ... Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20180418054257.15388-2-kraxel@redhat.com Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-04-25Revert "drm/sun4i: add lvds mode_valid function"Ondrej Jirman1-55/+0
The reverted commit broke LVDS output on TBS A711 Tablet. That tablet has simple-panel node that has fixed pixel clock-frequency that A83T SoC used in the tablet can't generate exactly. Requested rate is 52000000 and rounded_rate is calculated as 51857142. It's close enough for it to work in practice, but with strict check in the reverted commit, the mode is rejected needlessly in this case. DT allows to specify a range of values for simple-panel/clock-frequency, but driver doesn't respect that ATM. Given that TBS A711 is the single user of sun4i-lvds driver, let's revert that commit for now, until a better solution for the problem is found. Also see: https://patchwork.kernel.org/patch/9446385/ for relevant discussion (or search for "[RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check"). Fixes: e4e4b7ad50cf ("drm/sun4i: add lvds mode_valid function") Reported-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180421045155.15332-1-megous@megous.com Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-04-25virtio_console: reset on out of memoryMichael S. Tsirkin1-7/+10
When out of memory and we can't add ctrl vq buffers, probe fails. Unfortunately the error handling is out of spec: it calls del_vqs without bothering to reset the device first. To fix, call the full cleanup function in this case. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-25virtio_console: move removal codeMichael S. Tsirkin1-36/+36
Will make it reusable for error handling. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-25virtio_console: drop custom control queue cleanupMichael S. Tsirkin1-17/+0
We now cleanup all VQs on device removal - no need to handle the control VQ specially. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-25virtio_console: free buffers after resetMichael S. Tsirkin1-25/+24
Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to “unexpose” buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers until device unplug. Of course this means we might get an interrupt for a vq without an attached port now. Handle that by discarding the consumed buffer. Reported-by: Tiwei Bie <tiwei.bie@intel.com> Fixes: b3258ff1d6 ("virtio: Decrement avail idx on buffer detach") Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-25virtio: add ability to iterate over vqsMichael S. Tsirkin1-0/+3
For cleanup it's helpful to be able to simply scan all vqs and discard all data. Add an iterator to do that. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-25virtio_console: don't tie bufs to a vqMichael S. Tsirkin1-7/+7
an allocated buffer doesn't need to be tied to a vq - only vq->vdev is ever used. Pass the function the just what it needs - the vdev. Cc: stable@vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-04-25firmware: some documentation fixesAndres Rodriguez3-6/+6
Including: - Fixup outdated kernel-doc paths - Slightly too short title underline - Some typos Signed-off-by: Andres Rodriguez <andresx7@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-25cifs: smbd: Avoid allocating iov on the stackLong Li1-24/+12
It's not necessary to allocate another iov when going through the buffers in smbd_send() through RDMA send. Remove it to reduce stack size. Thanks to Matt for spotting a printk typo in the earlier version of this. CC: Matt Redfearn <matt.redfearn@mips.com> Signed-off-by: Long Li <longli@microsoft.com> Acked-by: Ronnie Sahlberg <lsahlber@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Steve French <smfrench@gmail.com>
2018-04-25cifs: smbd: Don't use RDMA read/write when signing is usedLong Li3-6/+19
SMB server will not sign data transferred through RDMA read/write. When signing is used, it's a good idea to have all the data signed. In this case, use RDMA send/recv for all data transfers. This will degrade performance as this is not generally configured in RDMA environemnt. So warn the user on signing and RDMA send/recv. Signed-off-by: Long Li <longli@microsoft.com> Acked-by: Ronnie Sahlberg <lsahlber@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Steve French <smfrench@gmail.com>
2018-04-25SMB311: Fix reconnectSteve French1-2/+2
The preauth hash was not being recalculated properly on reconnect of SMB3.11 dialect mounts (which caused access denied repeatedly on auto-reconnect). Fixes: 8bd68c6e47ab ("CIFS: implement v3.11 preauth integrity") Signed-off-by: Steve French <smfrench@gmail.com> CC: Stable <stable@vger.kernel.org> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
2018-04-25ARM: amba: Don't read past the end of sysfs "driver_override" bufferGeert Uytterhoeven1-1/+2
When printing the driver_override parameter when it is 4095 and 4094 bytes long, the printing code would access invalid memory because we need count + 1 bytes for printing. Cfr. commits 4efe874aace57dba ("PCI: Don't read past the end of sysfs "driver_override" buffer") and bf563b01c2895a4b ("driver core: platform: Don't read past the end of "driver_override" buffer"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-25ARM: amba: Fix race condition with driver_overrideGeert Uytterhoeven1-2/+9
The driver_override implementation is susceptible to a race condition when different threads are reading vs storing a different driver override. Add locking to avoid this race condition. Cfr. commits 6265539776a0810b ("driver core: platform: fix race condition with driver_override") and 9561475db680f714 ("PCI: Fix race condition with driver_override"). Fixes: 3cf385713460eb2b ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-25Revert "blk-mq: remove code for dealing with remapping queue"Ming Lei1-3/+31
This reverts commit 37c7c6c76d431dd7ef9c29d95f6052bd425f004c. Turns out some drivers(most are FC drivers) may not use managed IRQ affinity, and has their customized .map_queues meantime, so still keep this code for avoiding regression. Reported-by: Laurence Oberman <loberman@redhat.com> Tested-by: Laurence Oberman <loberman@redhat.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Tested-by: Stefan Haberland <sth@linux.vnet.ibm.com> Cc: Ewan Milne <emilne@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-04-25selftests:firmware: fixes a call to a wrong function nameJeffrin Jose T1-1/+1
This is a patch to the tools/testing/selftests/firmware/fw_run_tests.sh file which fixes a bug which calls to a wrong function name,which in turn blocks the execution of certain tests. Signed-off-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-04-25drm/amd/display: Check dc_sink every time in MST hotplugJerry (Fangzhi) Zuo1-7/+9
Extended fix to: "Don't read EDID in atomic_check" Fix issue of missing dc_sink in .mode_valid in hot plug routine. Need to check dc_sink everytime in .get_modes hook after checking edid, since edid is not getting removed in hot unplug but dc_sink doesn't. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-04-25drm/amd/display: Update MST edid property every timeJerry (Fangzhi) Zuo1-3/+3
Extended fix to: "Don't read EDID in atomic_check" Fix display property not observed in GUI display after hot plug. Call drm_mode_connector_update_edid_property every time in .get_modes hook, due to the fact that edid property is getting removed from usermode ioctl DRM_IOCTL_MODE_GETCONNECTOR each time in hot unplug. Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-04-25drm/amd/display: Don't read EDID in atomic_checkHarry Wentland1-22/+10
We shouldn't attempt to read EDID in atomic_check. We really shouldn't even be modifying the connector object, or any other non-state object, but this is a start at least. Moving EDID cleanup to dm_dp_mst_connector_destroy from dm_dp_destroy_mst_connector to ensure the EDID is still available for headless mode. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-04-25drm/amd/display: Disallow enabling CRTC without primary plane with FBHarry Wentland1-1/+9
The below commit "drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2" introduces a slight behavioral change to rmfb. Instead of disabling a crtc when the primary plane is disabled, it now preserves it. Since DC is currently not equipped to handle this we need to fail such a commit, otherwise we might see a corrupted screen. This is based on Shirish's previous approach but avoids adding all planes to the new atomic state which leads to a full update in DC for any commit, and is not what we intend. Theoretically DM should be able to deal with states with fully populated planes, even for simple updates, such as cursor updates. This should still be addressed in the future. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Tested-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-04-25drm/amd/display: Fix deadlock when flushing irqMikita Lipski1-2/+3
Lock irq table when reading a work in queue, unlock to flush the work, lock again till all tasks are cleared Signed-off-by: Mikita Lipski <mikita.lipski@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-04-25ALSA: hda - Skip jack and others for non-existing PCM streamsTakashi Iwai1-1/+8
When CONFIG_SND_DYNAMIC_MINORS isn't set, there are only limited number of devices available, and HD-audio, especially with HDMI/DP codec, will fail to create more than two devices. The driver warns about the lack of such devices and skips the PCM device creations, but the HDMI driver still tries to create the corresponding JACK, SPDIF and ELD controls even for the non-existing PCM substreams. This results in confusion on user-space, and even may break the operation. Similarly, Intel HDMI/DP codec builds the ELD notification from i915 graphics driver, and this may be broken if a notification is sent for the non-existing PCM stream. This patch adds the check of the existence of the assigned PCM substream in the both scenarios above, and skips the further operation if the PCM substream is not assigned. Fixes: 9152085defb6 ("ALSA: hda - add DP MST audio support") Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2018-04-25tracing: Fix missing tab for hwlat_detector print formatPeter Xu1-1/+1
It's been missing for a while but no one is touching that up. Fix it. Link: http://lkml.kernel.org/r/20180315060639.9578-1-peterx@redhat.com CC: Ingo Molnar <mingo@kernel.org> Cc:stable@vger.kernel.org Fixes: 7b2c86250122d ("tracing: Add NMI tracing in hwlat detector") Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>