summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-02-17drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_commandGerd Hoffmann1-1/+2
This avoids integer overflows on 32bit machines when calculating reloc_info size, as reported by Alan Cox. Cc: stable@vger.kernel.org Cc: gnomes@lxorguk.ukuu.org.uk Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17Merge branch 'exynos-drm-fixes' of ↵Dave Airlie12-63/+77
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes Summary: - fix compilation warnings on ARM64bit. - fix mic driver initialization. . MIC is a part of KMS so it converts it to use component framework like other KMS drivers did. - fix wrong driver state and disable clock order on DECON driver. - fix incorrect use of dma_mmap_attrs function. * 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos/decon: fix disable clocks order drm/exynos: fix incorrect cpu address for dma_mmap_attrs() drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable drm/exynos: dsi: restore support for drm bridge drm/exynos: mic: make all functions static drm/exynos: mic: convert to component framework drm/exynos: mic: use devm_clk interface drm/exynos: fix types for compilation on 64bit architectures drm/exynos: ipp: fix incorrect format specifiers in debug messages drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS
2016-02-17Revert "drm/dp/mst: change MST detection scheme"Dave Airlie1-19/+18
This reverts commit cfcfa086d43ced33e1099b9befb12f17fca102e1. This causes the tiling properties to break in some unexpected ways, Revert it for now. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17Merge branch 'for-chris-4.5' of ↵Chris Mason1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux into for-linus-4.5
2016-02-17writeback: initialize inode members that track writeback historyTahsin Erdogan1-0/+6
inode struct members that track cgroup writeback information should be reinitialized when inode gets allocated from kmem_cache. Otherwise, their values remain and get used by the new inode. Signed-off-by: Tahsin Erdogan <tahsin@google.com> Acked-by: Tejun Heo <tj@kernel.org> Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching") Signed-off-by: Jens Axboe <axboe@fb.com>
2016-02-16drm/vc4: Use runtime PM to power cycle the device when the GPU hangs.Eric Anholt3-18/+26
This gets us functional GPU reset again, like we had until a refactor at merge time. Tested with a little patch to stuff in a broken binner job every 100 frames. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Enable runtime PM.Eric Anholt3-0/+47
This may actually get us a feature that the closed driver didn't have: turning off the GPU in between rendering jobs, while the V3D device is still opened by the client. There may be some tuning to be applied here to use autosuspend so that we don't bounce the device's power so much, but in steady-state GPU-bound rendering we keep the power on (since we keep multiple jobs outstanding) and even if we power cycle on every job we can still manage at least 680 fps. More importantly, though, runtime PM will allow us to power off the device to do a GPU reset. v2: Switch #ifdef to CONFIG_PM not CONFIG_PM_SLEEP (caught by kbuild test robot) Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Fix spurious GPU resets due to BO reuse.Eric Anholt2-6/+19
We were tracking the "where are the head pointers pointing" globally, so if another job reused the same BOs and execution was at the same point as last time we checked, we'd stop and trigger a reset even though the GPU had made progress. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Drop error message on seqno wait timeouts.Eric Anholt1-3/+0
These ioctls end up getting exposed to fairly directly to GL users, and having normal user operations print DRM errors is obviously wrong. The message was originally to give us some idea of what happened when a hang occurred, but we have a DRM_INFO from reset for that. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Fix -ERESTARTSYS error return from BO waits.Eric Anholt1-4/+2
This caused the wait ioctls to claim that waiting had completed when we actually got interrupted by a signal before it was done. Fixes broken rendering throttling that produced serious lag in X window dragging. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Return an ERR_PTR from BO creation instead of NULL.Eric Anholt5-15/+15
Fixes igt vc4_create_bo/create-bo-0 by returning -EINVAL from the ioctl instead of -ENOMEM. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Fix the clear color for the first tile rendered.Eric Anholt1-9/+9
Apparently in hardware (as opposed to simulation), the clear colors need to be uploaded before the render config, otherwise they won't take effect. Fixes igt's vc4_wait_bo/used-bo-* subtests. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16drm/vc4: Validate that WAIT_BO padding is cleared.Eric Anholt1-0/+3
This is ABI future-proofing if we ever want to extend the pad to mean something. Signed-off-by: Eric Anholt <eric@anholt.net>
2016-02-16Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds3-4/+3
Pull cifs fixes from Steve French: "A small set of cifs fixes. I am still reviewing some more, recently submitted SMB3 fixes, but these three are small and safe and ready now" * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: cifs: fix erroneous return value cifs: fix potential overflow in cifs_compose_mount_options cifs: remove redundant check for null string pointer
2016-02-16Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds3-10/+13
Pull ARM KVM fixes from Paolo Bonzini: - Fix for an unpleasant crash when the VM is created without a timer - Allow HYP mode to access the full PA space, and not only 40bit * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: arm64: KVM: Configure TCR_EL2.PS at runtime KVM: arm/arm64: Fix reference to uninitialised VGIC
2016-02-16writeback: keep superblock pinned during cgroup writeback association switchesTejun Heo1-4/+11
If cgroup writeback is in use, an inode is associated with a cgroup for writeback. If the inode's main dirtier changes to another cgroup, the association gets updated asynchronously. Nothing was pinning the superblock while such switches are in progress and superblock could go away while async switching is pending or in progress leading to crashes like the following. kernel BUG at fs/jbd2/transaction.c:319! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51 Hardware name: Google Google, BIOS Google 01/01/2011 Workqueue: events inode_switch_wbs_work_fn task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000 RIP: 0010:[<ffffffff803e6922>] [<ffffffff803e6922>] start_this_handle+0x382/0x3e0 RSP: 0018:ffff880209267c30 EFLAGS: 00010202 ... Call Trace: [<ffffffff803e6be4>] jbd2__journal_start+0xf4/0x190 [<ffffffff803cfc7e>] __ext4_journal_start_sb+0x4e/0x70 [<ffffffff803b31ec>] ext4_evict_inode+0x12c/0x3d0 [<ffffffff8035338b>] evict+0xbb/0x190 [<ffffffff80354190>] iput+0x130/0x190 [<ffffffff80360223>] inode_switch_wbs_work_fn+0x343/0x4c0 [<ffffffff80279819>] process_one_work+0x129/0x300 [<ffffffff80279b16>] worker_thread+0x126/0x480 [<ffffffff8027ed14>] kthread+0xc4/0xe0 [<ffffffff809771df>] ret_from_fork+0x3f/0x70 Fix it by bumping s_active while cgroup association switching is in flight. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-and-tested-by: Tahsin Erdogan <tahsin@google.com> Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching") Cc: stable@vger.kernel.org #v4.5+ Signed-off-by: Jens Axboe <axboe@fb.com>
2016-02-16Merge tag 'kvm-arm-for-4.5-rc4' of ↵Paolo Bonzini3-10/+13
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master KVM/ARM fixes for 4.5-rc4 - Fix for an unpleasant crash when the VM is created without a timer - Allow HYP mode to access the full PA space, and not only 40bit
2016-02-16Merge tag 'for-linus-20160216' of git://git.infradead.org/intel-iommuLinus Torvalds4-8/+36
Pull IOMMU SVM fixes from David Woodhouse: "Minor register size and interrupt acknowledgement fixes which only showed up in testing on newer hardware, but mostly a fix to the MM refcount handling to prevent a recursive refcount issue when mmap() is used on the file descriptor associated with a bound PASID" * tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu: iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
2016-02-16Merge tag 'efi-urgent' of ↵Ingo Molnar2-7/+8
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent Pull EFI bug fixes from Matt Fleming: * Fix bugs in our code that converts ucs2 strings to utf8 where we unintentionally drop bits from the original string (Jason Andryuk) * Add the efi-pstore variables to the variable whitelist so that users can continue to delete them via efivarfs without needing to manipulate the immutable flag (Matt Fleming) Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-02-16Merge tag 'spi-fix-v4.5-rc4' of ↵Linus Torvalds6-7/+14
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A small clutch of driver specific fixes. The OMAP one is a bit worrying since it seems to be triggered by some changes in the runtime PM core code and I suspect there's other drivers across that are going to be using the same pattern outside of OMAP but nothing seems to be coming up in the testing people are doing" * tag 'spi-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit spi: bcm2835aux: fix bitmask defines spi: atmel: fix gpio chip-select in case of non-DT platform spi/fsl-espi: Correct the maximum transaction length spi: imx: fix spi resource leak with dma transfer spi: fix counting in spi-loopback-test code
2016-02-16Merge branch 'for-linus' of ↵Linus Torvalds15-1/+111
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k Pull m68k fixes from Geert Uytterhoeven: "Summary: - Wire up new copy_file_range syscall - Update defconfigs" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k/defconfig: Update defconfigs for v4.5-rc1 m68k: Wire up copy_file_range
2016-02-16drm/radeon: use post-decrement in error handlingRasmus Villemoes1-1/+1
We need to use post-decrement to get the pci_map_page undone also for i==0, and to avoid some very unpleasant behaviour if pci_map_page failed already at i==0. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-02-16drm/amdgpu: use post-decrement in error handlingRasmus Villemoes1-1/+1
We need to use post-decrement to get the pci_map_page undone also for i==0, and to avoid some very unpleasant behaviour if pci_map_page failed already at i==0. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-02-16ALSA: seq: Fix double port list deletionTakashi Iwai1-5/+8
The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to double mutex locks] split the management of two linked lists (source and destination) into two individual calls for avoiding the AB/BA deadlock. However, this may leave the possible double deletion of one of two lists when the counterpart is being deleted concurrently. It ends up with a list corruption, as revealed by syzkaller fuzzer. This patch fixes it by checking the list emptiness and skipping the deletion and the following process. BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks) Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-16lib/ucs2_string: Correct ucs2 -> utf8 conversionJason Andryuk1-7/+7
The comparisons should be >= since 0x800 and 0x80 require an additional bit to store. For the 3 byte case, the existing shift would drop off 2 more bits than intended. For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in byte 2. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@coreos.com> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
2016-02-16efi: Add pstore variables to the deletion whitelistMatt Fleming1-0/+1
Laszlo explains why this is a good idea, 'This is because the pstore filesystem can be backed by UEFI variables, and (for example) a crash might dump the last kilobytes of the dmesg into a number of pstore entries, each entry backed by a separate UEFI variable in the above GUID namespace, and with a variable name according to the above pattern. Please see "drivers/firmware/efi/efi-pstore.c". While this patch series will not prevent the user from deleting those UEFI variables via the pstore filesystem (i.e., deleting a pstore fs entry will continue to delete the backing UEFI variable), I think it would be nice to preserve the possibility for the sysadmin to delete Linux-created UEFI variables that carry portions of the crash log, *without* having to mount the pstore filesystem.' There's also no chance of causing machines to become bricked by deleting these variables, which is the whole purpose of excluding things from the whitelist. Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so that we don't have to update the string in the future if new variable name formats are created for crash dump variables. Reported-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Peter Jones <pjones@redhat.com> Tested-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
2016-02-16Merge tag 'efi-urgent' of ↵Ingo Molnar12-83/+383
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent Pull EFI fixes from Matt Fleming: * Prevent accidental deletion of EFI variables through efivarfs that may brick machines. We use a whitelist of known-safe variables to allow things like installing distributions to work out of the box, and instead restrict vendor-specific variable deletion by making non-whitelist variables immutable (Peter Jones) Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-02-16arm64/efi: Make strnlen() available to the EFI namespaceThierry Reding2-1/+2
Changes introduced in the upstream version of libfdt pulled in by commit 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use the strnlen() function, which isn't currently available to the EFI name- space. Add it to the EFI namespace to avoid a linker error. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Rob Herring <robh@kernel.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-16ext4: fix memleak in ext4_readdir()Kirill Tkhai1-2/+5
When ext4_bread() fails, fname_crypto_str remains allocated after return. Fix that. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> CC: Dmitry Monakhov <dmonakhov@virtuozzo.com>
2016-02-16Btrfs: fix direct IO requests not reporting IO error to user spaceFilipe Manana1-0/+2
If a bio for a direct IO request fails, we were not setting the error in the parent bio (the main DIO bio), making us not return the error to user space in btrfs_direct_IO(), that is, it made __blockdev_direct_IO() return the number of bytes issued for IO and not the error a bio created and submitted by btrfs_submit_direct() got from the block layer. This essentially happens because when we call: dio_end_io(dio_bio, bio->bi_error); It does not set dio_bio->bi_error to the value of the second argument. So just add this missing assignment in endio callbacks, just as we do in the error path at btrfs_submit_direct() when we fail to clone the dio bio or allocate its private object. This follows the convention of what is done with other similar APIs such as bio_endio() where the caller is responsible for setting the bi_error field in the bio it passes as an argument to bio_endio(). This was detected by the new generic test cases in xfstests: 271, 272, 276 and 278. Which essentially setup a dm error target, then load the error table, do a direct IO write and unload the error table. They expect the write to fail with -EIO, which was not getting reported when testing against btrfs. Cc: stable@vger.kernel.org # 4.3+ Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio") Signed-off-by: Filipe Manana <fdmanana@suse.com>
2016-02-15pinctrl: samsung: fix SMP race conditionYoungmin Nam1-13/+35
Previously, samsung_gpio_drection_in/output function were not covered with a spinlock. For example, samsung_gpio_direction_output function consists of two functions. 1. samsung_gpio_set 2. samsung_gpio_set_direction When 2 CPUs try to control the same gpio pin heavily, (situation like i2c control with gpio emulation) This situation can cause below problem. CPU 0 | CPU1 | samsung_gpio_direction_output | samsung_gpio_set(pin A as 1) | samsung_gpio_direction_output | samsung_gpio_set(pin A as 0) samsung_gpio_set_direction | | samsung_gpio_set_direction The initial value of pin A will be set as 0 while we wanted to set pin A as 1. This patch modifies samsung_gpio_direction_in/output function to be done in one spinlock to fix race condition. Additionally, the new samsung_gpio_set_value was added to implement gpio set callback(samsung_gpio_set) with spinlock using this function. Cc: stable@vger.kernel.org Signed-off-by: Youngmin Nam <ym0914@gmail.com> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-15tracing: Fix freak link error caused by branch tracerArnd Bergmann1-1/+1
In my randconfig tests, I came across a bug that involves several components: * gcc-4.9 through at least 5.3 * CONFIG_GCOV_PROFILE_ALL enabling -fprofile-arcs for all files * CONFIG_PROFILE_ALL_BRANCHES overriding every if() * The optimized implementation of do_div() that tries to replace a library call with an division by multiplication * code in drivers/media/dvb-frontends/zl10353.c doing u32 adc_clock = 450560; /* 45.056 MHz */ if (state->config.adc_clock) adc_clock = state->config.adc_clock; do_div(value, adc_clock); In this case, gcc fails to determine whether the divisor in do_div() is __builtin_constant_p(). In particular, it concludes that __builtin_constant_p(adc_clock) is false, while __builtin_constant_p(!!adc_clock) is true. That in turn throws off the logic in do_div() that also uses __builtin_constant_p(), and instead of picking either the constant- optimized division, and the code in ilog2() that uses __builtin_constant_p() to figure out whether it knows the answer at compile time. The result is a link error from failing to find multiple symbols that should never have been called based on the __builtin_constant_p(): dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN' dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod' ERROR: "____ilog2_NaN" [drivers/media/dvb-frontends/zl10353.ko] undefined! ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/zl10353.ko] undefined! This patch avoids the problem by changing __trace_if() to check whether the condition is known at compile-time to be nonzero, rather than checking whether it is actually a constant. I see this one link error in roughly one out of 1600 randconfig builds on ARM, and the patch fixes all known instances. Link: http://lkml.kernel.org/r/1455312410-1058841-1-git-send-email-arnd@arndb.de Acked-by: Nicolas Pitre <nico@linaro.org> Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y") Cc: stable@vger.kernel.org # v2.6.30+ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2016-02-15tracepoints: Do not trace when cpu is offlineSteven Rostedt (Red Hat)1-0/+5
The tracepoint infrastructure uses RCU sched protection to enable and disable tracepoints safely. There are some instances where tracepoints are used in infrastructure code (like kfree()) that get called after a CPU is going offline, and perhaps when it is coming back online but hasn't been registered yet. This can probuce the following warning: [ INFO: suspicious RCU usage. ] 4.4.0-00006-g0fe53e8-dirty #34 Tainted: G S ------------------------------- include/trace/events/kmem.h:141 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 no locks held by swapper/8/0. stack backtrace: CPU: 8 PID: 0 Comm: swapper/8 Tainted: G S 4.4.0-00006-g0fe53e8-dirty #34 Call Trace: [c0000005b76c78d0] [c0000000008b9540] .dump_stack+0x98/0xd4 (unreliable) [c0000005b76c7950] [c00000000010c898] .lockdep_rcu_suspicious+0x108/0x170 [c0000005b76c79e0] [c00000000029adc0] .kfree+0x390/0x440 [c0000005b76c7a80] [c000000000055f74] .destroy_context+0x44/0x100 [c0000005b76c7b00] [c0000000000934a0] .__mmdrop+0x60/0x150 [c0000005b76c7b90] [c0000000000e3ff0] .idle_task_exit+0x130/0x140 [c0000005b76c7c20] [c000000000075804] .pseries_mach_cpu_die+0x64/0x310 [c0000005b76c7cd0] [c000000000043e7c] .cpu_die+0x3c/0x60 [c0000005b76c7d40] [c0000000000188d8] .arch_cpu_idle_dead+0x28/0x40 [c0000005b76c7db0] [c000000000101e6c] .cpu_startup_entry+0x50c/0x560 [c0000005b76c7ed0] [c000000000043bd8] .start_secondary+0x328/0x360 [c0000005b76c7f90] [c000000000008a6c] start_secondary_prolog+0x10/0x14 This warning is not a false positive either. RCU is not protecting code that is being executed while the CPU is offline. Instead of playing "whack-a-mole(TM)" and adding conditional statements to the tracepoints we find that are used in this instance, simply add a cpu_online() test to the tracepoint code where the tracepoint will be ignored if the CPU is offline. Use of raw_smp_processor_id() is fine, as there should never be a case where the tracepoint code goes from running on a CPU that is online and suddenly gets migrated to a CPU that is offline. Link: http://lkml.kernel.org/r/1455387773-4245-1-git-send-email-kda@linux-powerpc.org Reported-by: Denis Kirjanov <kda@linux-powerpc.org> Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints") Cc: stable@vger.kernel.org # v2.6.28+ Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2016-02-15dmaengine: dw: disable BLOCK IRQs for non-cyclic xferAndy Shevchenko1-5/+10
The commit 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks") re-enabled BLOCK interrupts with regard to make cyclic transfers work. However, this change becomes a regression for non-cyclic transfers as interrupt counters under stress test had been grown enormously (approximately per 4-5 bytes in the UART loop back test). Taking into consideration above enable BLOCK interrupts if and only if channel is programmed to perform cyclic transfer. Fixes: 2895b2cad6e7 ("dmaengine: dw: fix cyclic transfer callbacks") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mans Rullgard <mans@mansr.com> Tested-by: Mans Rullgard <mans@mansr.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-02-15arm/arm64: crypto: assure that ECB modes don't require an IVJeremy Linton2-4/+4
ECB modes don't use an initialization vector. The kernel /proc/crypto interface doesn't reflect this properly. Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-02-15ALSA: hda - Cancel probe work instead of flush at removeTakashi Iwai1-2/+2
The commit [991f86d7ae4e: ALSA: hda - Flush the pending probe work at remove] introduced the sync of async probe work at remove for fixing the race. However, this may lead to another hangup when the module removal is performed quickly before starting the probe work, because it issues flush_work() and it's blocked forever. The workaround is to use cancel_work_sync() instead of flush_work() there. Fixes: 991f86d7ae4e ('ALSA: hda - Flush the pending probe work at remove') Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-15ALSA: seq: Fix leak of pool buffer at concurrent writesTakashi Iwai1-4/+9
When multiple concurrent writes happen on the ALSA sequencer device right after the open, it may try to allocate vmalloc buffer for each write and leak some of them. It's because the presence check and the assignment of the buffer is done outside the spinlock for the pool. The fix is to move the check and the assignment into the spinlock. (The current implementation is suboptimal, as there can be multiple unnecessary vmallocs because the allocation is done before the check in the spinlock. But the pool size is already checked beforehand, so this isn't a big problem; that is, the only possible path is the multiple writes before any pool assignment, and practically seen, the current coverage should be "good enough".) The issue was triggered by syzkaller fuzzer. BugLink: http://lkml.kernel.org/r/CACT4Y+bSzazpXNvtAr=WXaL8hptqjHwqEyFA+VN2AWEx=aurkg@mail.gmail.com Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-15drm/exynos/decon: fix disable clocks orderAndrzej Hajda1-2/+2
Decon requires that clocks should be disabled in reverse order. Otherwise system hangs. Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: fix incorrect cpu address for dma_mmap_attrs()Marek Szyprowski2-2/+2
dma_mmap_attrs() should be called with cpu address returned by dma_alloc_attrs(). Existing code however passed pages array base as cpu address. This worked only by a pure luck on ARM architecture. This patch fixes this issue. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enableMarek Szyprowski1-1/+1
BIT_IRQS_ENABLED was never set because of incorrect test in decon_vlank_enable() function, what resulted in lack of enabling vblank support. This patch fixes this issue. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enableMarek Szyprowski1-2/+0
Patch ebf3fd403b79ba6561bd1a4bb5a7cacc99da08e5 ("drm/exynos: add pm_runtime to DECON 5433") removed some code from decon_enable() function, but it left set_bit(BIT_SUSPENDED, &ctx->flags) call, which was earlier called only in error path. This patch removes it, what finally lets driver to go out of suspended state. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: dsi: restore support for drm bridgeMarek Szyprowski1-0/+1
This patch fixes issue introduced by commit cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 ("drm/exynos: remove struct exynos_drm_display"), which removed assigning of drm bridge to drm encoder. Lack of it caused that no bridge callbacks were called on encoder enable/disable actions. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: mic: make all functions staticMarek Szyprowski1-5/+5
There is no point exposing all internal functions to global kernel name space, so make all internals functions static. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: mic: convert to component frameworkMarek Szyprowski1-20/+36
MIC is SoC component and important part of kms pipeline on Exynos5433, so convert it to use component framework like other KMS/CRTC drivers. MIC driver is already listed on KMS component driver list in Exynos DRM core, so without this conversion, initialization of Exynos DRM core fails on Exynos 5433 SoC. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: mic: use devm_clk interfaceMarek Szyprowski1-5/+1
Drivers should use devm_clk* interface instead of of_clk* functions. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: fix types for compilation on 64bit architecturesMarek Szyprowski3-6/+9
This patch fixes compilation warnings (on 64bit architectures) and bugs related to casting pointers through 32bit integers. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: ipp: fix incorrect format specifiers in debug messagesMarek Szyprowski4-19/+19
Drivers should use %p for printing pointers instead of hardcoding them as hexadecimal integers. This patch fixes compilation warnings on 64bit architectures. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOSJoonyoung Shim1-1/+1
Because PLAT_SAMSUNG isn't include exynos SoCs for arm64, but ARCH_EXYNOS can do it. And it also needs to add ARCH_S3C64XX instead of PLAT_SAMSUNG. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2016-02-15iommu/vt-d: Clear PPR bit to ensure we get more page request interruptsDavid Woodhouse2-0/+7
According to the VT-d specification we need to clear the PPR bit in the Page Request Status register when handling page requests, or the hardware won't generate any more interrupts. This wasn't actually necessary on SKL/KBL (which may well be the subject of a hardware erratum, although it's harmless enough). But other implementations do appear to get it right, and we only ever get one interrupt unless we clear the PPR bit. Reported-by: CQ Tang <cq.tang@intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org
2016-02-15powerpc/mm: Fix Multi hit ERAT cause by recent THP updateAneesh Kumar K.V4-0/+45
With ppc64 we use the deposited pgtable_t to store the hash pte slot information. We should not withdraw the deposited pgtable_t without marking the pmd none. This ensure that low level hash fault handling will skip this huge pte and we will handle them at upper levels. Recent change to pmd splitting changed the above in order to handle the race between pmd split and exit_mmap. The race is explained below. Consider following race: CPU0 CPU1 shrink_page_list() add_to_swap() split_huge_page_to_list() __split_huge_pmd_locked() pmdp_huge_clear_flush_notify() // pmd_none() == true exit_mmap() unmap_vmas() zap_pmd_range() // no action on pmd since pmd_none() == true pmd_populate() As result the THP will not be freed. The leak is detected by check_mm(): BUG: Bad rss-counter state mm:ffff880058d2e580 idx:1 val:512 The above required us to not mark pmd none during a pmd split. The fix for ppc is to clear the huge pte of _PAGE_USER, so that low level fault handling code skip this pte. At higher level we do take ptl lock. That should serialze us against the pmd split. Once the lock is acquired we do check the pmd again using pmd_same. That should always return false for us and hence we should retry the access. We do the pmd_same check in all case after taking plt with THP (do_huge_pmd_wp_page, do_huge_pmd_numa_page and huge_pmd_set_accessed) Also make sure we wait for irq disable section in other cpus to finish before flipping a huge pte entry with a regular pmd entry. Code paths like find_linux_pte_or_hugepte depend on irq disable to get a stable pte_t pointer. A parallel thp split need to make sure we don't convert a pmd pte to a regular pmd entry without waiting for the irq disable section to finish. Fixes: eef1b3ba053a ("thp: implement split_huge_pmd()") Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>