aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-05-24treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 26Thomas Gleixner14-196/+14
Based on 1 normalized pattern(s): gnupg is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version gnupg is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 59 temple place suite 330 boston ma 02111 1307 usa note this code is heavily based on the gnu mp library actually it s the same code with only minor changes in the way the data is stored this is to support the abstraction of an optional secure memory allocation which may be used to avoid revealing of sensitive data due to paging etc the gnu mp library itself is published under the lgpl however i decided to publish this code under the plain gpl extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 14 file(s). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Allison Randal <[email protected]> Reviewed-by: Kate Stewart <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-05-24drm/mcde: Add new driver for ST-Ericsson MCDELinus Walleij13-0/+3745
This adds a new DRM driver for the ST-Ericsson Multi Channel Display Engine, MCDE display controller. This hardware has three independent DSI hosts and can composit and display several memory buffers onto an LCD display. It was developed for several years inside of ST-Ericsson and shipped with a few million mobile phones from Sony and Samsung, as well as with the Snowball community development board. The driver is currently pretty rudimentary but supports a simple framebuffer so we can get penguins and graphics when using these SoCs. Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-24arm64: insn: Add BUILD_BUG_ON() for invalid masksJean-Philippe Brucker1-5/+11
Detect invalid instruction masks at build time. Some versions of GCC can warn about the situation, but not all of them, it seems. Suggested-by: Will Deacon <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-24arm64: insn: Fix ldadd instruction encodingJean-Philippe Brucker1-1/+1
GCC 8.1.0 reports that the ldadd instruction encoding, recently added to insn.c, doesn't match the mask and couldn't possibly be identified: linux/arch/arm64/include/asm/insn.h: In function 'aarch64_insn_is_ldadd': linux/arch/arm64/include/asm/insn.h:280:257: warning: bitwise comparison always evaluates to false [-Wtautological-compare] Bits [31:30] normally encode the size of the instruction (1 to 8 bytes) and the current instruction value only encodes the 4- and 8-byte variants. At the moment only the BPF JIT needs this instruction, and doesn't require the 1- and 2-byte variants, but to be consistent with our other ldr and str instruction encodings, clear the size field in the insn value. Fixes: 34b8ab091f9ef57a ("bpf, arm64: use more scalable stadd over ldxr / stxr loop in xadd") Acked-by: Daniel Borkmann <[email protected]> Reported-by: Kuninori Morimoto <[email protected]> Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-24arm64: Kconfig: Make ARM64_PSEUDO_NMI depend on BROKEN for nowWill Deacon1-0/+1
Although we merged support for pseudo-nmi using interrupt priority masking in 5.1, we've since uncovered a number of non-trivial issues with the implementation. Although there are patches pending to address these problems, we're facing issues that prevent us from merging them at this current time: https://lkml.kernel.org/r/[email protected] For now, simply mark this optional feature as BROKEN in the hope that we can fix things properly in the near future. Cc: <[email protected]> # 5.1 Cc: Julien Thierry <[email protected]> Acked-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2019-05-24KVM: arm/arm64: Move cc/it checks under hyp's Makefile to avoid instrumentationJames Morse4-121/+138
KVM has helpers to handle the condition codes of trapped aarch32 instructions. These are marked __hyp_text and used from HYP, but they aren't built by the 'hyp' Makefile, which has all the runes to avoid ASAN and KCOV instrumentation. Move this code to a new hyp/aarch32.c to avoid a hyp-panic when starting an aarch32 guest on a host built with the ASAN/KCOV debug options. Fixes: 021234ef3752f ("KVM: arm64: Make kvm_condition_valid32() accessible from EL2") Fixes: 8cebe750c4d9a ("arm64: KVM: Make kvm_skip_instr32 available to HYP") Signed-off-by: James Morse <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-05-24KVM: arm64: Move pmu hyp code under hyp's Makefile to avoid instrumentationJames Morse3-41/+39
KVM's pmu.c contains the __hyp_text needed to switch the pmu registers between host and guest. Because this isn't covered by the 'hyp' Makefile, it can be built with kasan and friends when these are enabled in Kconfig. When starting a guest, this results in: | Kernel panic - not syncing: HYP panic: | PS:a00003c9 PC:000083000028ada0 ESR:86000007 | FAR:000083000028ada0 HPFAR:0000000029df5300 PAR:0000000000000000 | VCPU:000000004e10b7d6 | CPU: 0 PID: 3088 Comm: qemu-system-aar Not tainted 5.2.0-rc1 #11026 | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Plat | Call trace: | dump_backtrace+0x0/0x200 | show_stack+0x20/0x30 | dump_stack+0xec/0x158 | panic+0x1ec/0x420 | panic+0x0/0x420 | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x002,25006082 | Memory Limit: none | ---[ end Kernel panic - not syncing: HYP panic: This is caused by functions in pmu.c calling the instrumented code, which isn't mapped to hyp. From objdump -r: | RELOCATION RECORDS FOR [.hyp.text]: | OFFSET TYPE VALUE | 0000000000000010 R_AARCH64_CALL26 __sanitizer_cov_trace_pc | 0000000000000018 R_AARCH64_CALL26 __asan_load4_noabort | 0000000000000024 R_AARCH64_CALL26 __asan_load4_noabort Move the affected code to a new file under 'hyp's Makefile. Fixes: 3d91befbb3a0 ("arm64: KVM: Enable !VHE support for :G/:H perf event modifiers") Cc: Andrew Murray <[email protected]> Signed-off-by: James Morse <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-05-24MAINTAINERS: KVM: arm/arm64: Remove myself as maintainerChristoffer Dall1-2/+0
I no longer have time to actively review patches and manage the tree and it's time to make that official. Huge thanks to the incredible Linux community and all the contributors who have put up with me over the past years. I also take this opportunity to remove the website link to the Columbia web page, as that information is no longer up to date and I don't know who manages that anymore. Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
2019-05-24Revert "drm/amd/display: Don't load DMCU for Raven 1"Dave Airlie1-10/+2
This reverts commit 55143dc23ca4792868ea8c17bce65ca7b3d3e8c4. This causes build breakags with some Kconfigs so revert for now. Fixes: 55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1") Signed-off-by: Dave Airlie <[email protected]>
2019-05-24drm/i915/gen11: enable support for headerless msgsDongwon Kim2-0/+5
Setting bit5 (headerless msg for preemptible GPGPU context) of SAMPLER_MODE register to enable support for the headless msgs on gen11. None of existing use cases will be affected by this as this change makes both types of message - headerless and w/ header supported at the same time. It also complies with the new recommendation for the default bit value for the next gen. v2: rewrote commit message to include more information v3: setting the bit in icl_ctx_workarounds_init() Signed-off-by: Dongwon Kim <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Chris Wilson <[email protected]>
2019-05-24drm/i915/gtt: Neuter the deferred unbind callback from gen6_ppgtt_cleanupChris Wilson1-0/+28
Having deferred the vma destruction to a worker where we can acquire the struct_mutex, we have to avoid chasing back into the now destroyed ppgtt. The pd_vma is special in having a custom unbind function to scan for unused pages despite the VMA itself being notionally part of the GGTT. As such, we need to disable that callback to avoid a use-after-free. This unfortunately blew up so early during boot that CI declared the machine unreachable as opposed to being the major failure it was. Oops. Fixes: d3622099c76f ("drm/i915/gtt: Always acquire struct_mutex for gen6_ppgtt_cleanup") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Tomi Sarvela <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-24drm/meson: imply dw-hdmi i2s audio for meson hdmiJerome Brunet1-0/+1
Imply the i2s part of the Synopsys HDMI driver for Amlogic SoCs. This will enable the i2s part by default when meson hdmi driver is enable but let platforms not supported by the audio subsystem disable it if necessary. Signed-off-by: Jerome Brunet <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-24drm/stm: dsi: check hardware versionYannick Fertré1-1/+23
Check version of DSI hardware IP. Only versions 1.30 & 1.31 are supported. Signed-off-by: Yannick Fertré <[email protected]> Acked-by: Philippe Cornu <[email protected]> Signed-off-by: Benjamin Gaignard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-24drm/stm: ltdc: remove clk_round_rate commentYannick Fertré1-7/+3
Clk_round_rate returns rounded clock without changing the hardware in any way. This function couldn't replace set_rate/get_rate calls. Todo comment has been removed & a new log inserted. Signed-off-by: Yannick Fertré <[email protected]> Signed-off-by: Benjamin Gaignard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-24dt-bindings: fix up for vendor prefixes file conversionStephen Rothwell2-468/+6
Link: Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Fixes: 374ed5429346 ("Merge drm/drm-next into drm-misc-next") Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2019-05-23thermal: rcar_gen3_thermal: Update temperature conversion methodYoshihiro Kaneko1-10/+18
Update the formula to calculate temperature: Currently, current TEMP is calculated as average of val1 (is calculated by formula 1) and val2 (is calculated by formula 2). But, as description in HWM (chapter 10A.3.1.2 Normal Mode.) If (TEMP_CODE < THCODE2[11:0]) CTEMP value should be val1. If (TEMP_CODE > THCODE2[11:0]) CTEMP value should be val2. Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23thermal: rcar_gen3_thermal: Update calculation formula of IRQTEMPYoshihiro Kaneko1-16/+17
Update the formula to calculate CTEMP: Currently, the CTEMP is average of val1 (is calculated by formula 1) and val2 (is calculated by formula 2). But, as description in HWM (chapter 10A.3.1.1 Setting of Normal Mode) If (STEMP < Tj_T) CTEMP value should be val1. If (STEMP > Tj_T) CTEMP value should be val2. Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23thermal: rcar_gen3_thermal: Update value of Tj_1Yoshihiro Kaneko1-11/+30
As evaluation of hardware team, temperature calculation formula of M3-W is difference from all other SoCs as below: - M3-W: Tj_1: 116 (so Tj_1 - Tj_3 = 157) - Others: Tj_1: 126 (so Tj_1 - Tj_3 = 167) Signed-off-by: Yoshihiro Kaneko <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23thermal: tegra: Make tegra210_tsensor_thermtrips staticYueHaibing1-1/+1
Fix sparse warning: drivers/thermal/tegra/tegra210-soctherm.c:211:33: warning: symbol 'tegra210_tsensor_thermtrips' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-23Revert "thermal: rockchip: fix up the tsadc pinctrl setting error"Heiko Stuebner1-33/+3
This reverts commit 28694e009e512451ead5519dd801f9869acb1f60. The commit causes multiple issues in that: - the added call to ->control does potentially run unclocked causing a hang of the machine - the added pinctrl-states are undocumented in the binding - the added pinctrl-states are not backwards compatible, breaking old devicetrees. Fixes: 28694e009e51 ("thermal: rockchip: fix up the tsadc pinctrl setting error") Signed-off-by: Heiko Stuebner <[email protected]> Reported-by: kernelci.org bot <[email protected]> Reported-by: Enric Balletbo Serra <[email protected]> Reported-by: Vicente Bergas <[email protected]> Reported-by: Jack Mitchell <[email protected]> Reported-by: Douglas Anderson <[email protected]> Tested-by: Douglas Anderson <[email protected]> Signed-off-by: Eduardo Valentin <[email protected]>
2019-05-24Merge tag 'drm-intel-fixes-2019-05-23' of ↵Dave Airlie11-196/+202
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 Signed-off-by: Dave Airlie <[email protected]> From: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23ext4: do not delete unlinked inode from orphan list on failed truncateJan Kara1-1/+1
It is possible that unlinked inode enters ext4_setattr() (e.g. if somebody calls ftruncate(2) on unlinked but still open file). In such case we should not delete the inode from the orphan list if truncate fails. Note that this is mostly a theoretical concern as filesystem is corrupted if we reach this path anyway but let's be consistent in our orphan handling. Reviewed-by: Ira Weiny <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected]
2019-05-23ext4: wait for outstanding dio during truncate in nojournal modeJan Kara1-12/+9
We didn't wait for outstanding direct IO during truncate in nojournal mode (as we skip orphan handling in that case). This can lead to fs corruption or stale data exposure if truncate ends up freeing blocks and these get reallocated before direct IO finishes. Fix the condition determining whether the wait is necessary. CC: [email protected] Fixes: 1c9114f9c0f1 ("ext4: serialize unlocked dio reads with truncate") Reviewed-by: Ira Weiny <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Theodore Ts'o <[email protected]>
2019-05-23drm/i915: remove unused IO_TLB_SEGPAGES which should be defined by swiotlbDongli Zhang1-3/+0
This patch removes IO_TLB_SEGPAGES which is no longer used since commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen"). As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb, IO_TLB_SEGPAGES should be defined on swiotlb side if it is required in the future. Signed-off-by: Dongli Zhang <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/uc: Skip reset preparation if GuC is already deadMichal Wajdeczko1-1/+1
We may skip reset preparation steps if GuC is already sanitized. v2: replace USES_GUC with guc_is_loaded Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/uc: Stop talking with GuC when resettingMichal Wajdeczko2-1/+17
Knowing that GuC will be reset soon, we may stop all communication immediately without doing graceful cleanup as it is not needed. This patch will also help us capture any unwanted/unexpected attempts to talk with GuC after we decided to reset it. And we need to keep 'disable' part as current and upcoming firmware still expect graceful cleanup. v2: update commit msg Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/uc: Skip GuC HW unwinding if GuC is already deadMichal Wajdeczko1-1/+1
We should not attempt to unwind GuC hardware/firmware setup if we already have sanitized GuC. v2: replace USES_GUC with guc_is_loaded Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/uc: Use GuC firmware status helperMichal Wajdeczko1-6/+3
We already have helper function for checking GuC firmware load status. Replace existing open-coded checks. v2: drop redundant USES_GUC check Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/uc: Explicitly sanitize GuC/HuC on failure and finishMichal Wajdeczko1-5/+13
Explicitly sanitize GuC/HuC on load failure and when we finish using them to make sure our fw state tracking is always correct. While around, use new helper in uc_reset_prepare. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/guc: Rename intel_guc_is_alive to intel_guc_is_loadedMichal Wajdeczko2-6/+6
This function just check our software flag, while 'is_alive' may suggest that we are checking runtime firmware status. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/selftests: Use prepare/finish during atomic reset testMichal Wajdeczko1-0/+2
We were testing full GPU reset in atomic context without correctly wrapping it by prepare/finish steps. This could confuse our GuC reset handling code. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/selftests: Split igt_atomic_reset testcaseMichal Wajdeczko5-90/+124
Split igt_atomic_reset selftests into separate full & engines parts, so we can move former to the dedicated reset selftests file. While here change engines test to loop first over atomic phases and then loop over available engines. Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/selftests: Move some reset testcases to separate fileMichal Wajdeczko4-50/+81
igt_global_reset and igt_wedged_reset testcases are first candidates. Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/i915/gtt: Always acquire struct_mutex for gen6_ppgtt_cleanupChris Wilson2-2/+33
We rearranged the vm_destroy_ioctl to avoid taking struct_mutex, little realising that buried underneath the gen6 ppgtt release path was a struct_mutex requirement (to remove its GGTT vma). Until that struct_mutex is vanquished, take a detour in gen6_ppgtt_cleanup to do the i915_vma_destroy from inside a worker under the struct_mutex. <4> [257.740160] WARN_ON(debug_locks && !lock_is_held(&(&vma->vm->i915->drm.struct_mutex)->dep_map)) <4> [257.740213] WARNING: CPU: 3 PID: 1507 at drivers/gpu/drm/i915/i915_vma.c:841 i915_vma_destroy+0x1ae/0x3a0 [i915] <4> [257.740214] Modules linked in: snd_hda_codec_hdmi i915 x86_pkg_temp_thermal mei_hdcp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core r8169 realtek snd_pcm mei_me mei prime_numbers lpc_ich <4> [257.740224] CPU: 3 PID: 1507 Comm: gem_vm_create Tainted: G U 5.2.0-rc1-CI-CI_DRM_6118+ #1 <4> [257.740225] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016 <4> [257.740249] RIP: 0010:i915_vma_destroy+0x1ae/0x3a0 [i915] <4> [257.740250] Code: 00 00 00 48 81 c7 c8 00 00 00 e8 ed 08 f0 e0 85 c0 0f 85 78 fe ff ff 48 c7 c6 e8 ec 30 a0 48 c7 c7 da 55 33 a0 e8 42 8c e9 e0 <0f> 0b 8b 83 40 01 00 00 85 c0 0f 84 63 fe ff ff 48 c7 c1 c1 58 33 <4> [257.740251] RSP: 0018:ffffc90000aafc68 EFLAGS: 00010282 <4> [257.740252] RAX: 0000000000000000 RBX: ffff8883f7957840 RCX: 0000000000000003 <4> [257.740253] RDX: 0000000000000046 RSI: 0000000000000006 RDI: ffffffff8212d1b9 <4> [257.740254] RBP: ffffc90000aafcc8 R08: 0000000000000000 R09: 0000000000000000 <4> [257.740255] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8883f4d5c2a8 <4> [257.740256] R13: ffff8883f4d5d680 R14: ffff8883f4d5c668 R15: ffff8883f4d5c2f0 <4> [257.740257] FS: 00007f777fa8fe40(0000) GS:ffff88840f780000(0000) knlGS:0000000000000000 <4> [257.740258] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [257.740259] CR2: 00007f777f6522b0 CR3: 00000003c612a006 CR4: 00000000001606e0 <4> [257.740260] Call Trace: <4> [257.740283] gen6_ppgtt_cleanup+0x25/0x60 [i915] <4> [257.740306] i915_ppgtt_release+0x102/0x290 [i915] <4> [257.740330] i915_gem_vm_destroy_ioctl+0x7c/0xa0 [i915] <4> [257.740376] ? i915_gem_vm_create_ioctl+0x160/0x160 [i915] <4> [257.740379] drm_ioctl_kernel+0x83/0xf0 <4> [257.740382] drm_ioctl+0x2f3/0x3b0 <4> [257.740422] ? i915_gem_vm_create_ioctl+0x160/0x160 [i915] <4> [257.740426] ? _raw_spin_unlock_irqrestore+0x39/0x60 <4> [257.740430] do_vfs_ioctl+0xa0/0x6e0 <4> [257.740433] ? lock_acquire+0xa6/0x1c0 <4> [257.740436] ? __task_pid_nr_ns+0xb9/0x1f0 <4> [257.740439] ksys_ioctl+0x35/0x60 <4> [257.740441] __x64_sys_ioctl+0x11/0x20 <4> [257.740443] do_syscall_64+0x55/0x1c0 <4> [257.740445] entry_SYSCALL_64_after_hwframe+0x49/0xbe References: e0695db7298e ("drm/i915: Create/destroy VM (ppGTT) for use with contexts") Fixes: 7f3f317a66ca ("drm/i915: Restore control over ppgtt for context creation ABI") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23Merge tag 'xfs-5.2-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds3-0/+27
Pull xfs fix from Darrick Wong: "Fix an accounting mistake where we included the log space when calculating the reserve space for metadata expansion" * tag 'xfs-5.2-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: don't reserve per-AG space for an internal log
2019-05-23drm/edid: Fix docbook in drm_hdmi_infoframe_set_hdr_metadata()Sean Paul1-1/+1
Fixes the following warnings: ../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member 'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata' ../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter 'hdr_metadata' description in 'drm_hdmi_infoframe_set_hdr_metadata' Fixes: 2cdbfd66a829 ("drm: Enable HDR infoframe support") Cc: Uma Shankar <[email protected]> Cc: Shashank Sharma <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Bartlomiej Zolnierkiewicz <[email protected]> Cc: "Ville Syrjälä" <[email protected]> Cc: Hans Verkuil <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23Merge branch 'nvme-5.2-rc2' of git://git.infradead.org/nvme into for-linusJens Axboe4-42/+77
Pull NVMe changes from Keith. * 'nvme-5.2-rc2' of git://git.infradead.org/nvme: nvme-pci: use blk-mq mapping for unmanaged irqs nvme: update MAINTAINERS nvme: copy MTFA field from identify controller nvme: fix memory leak for power latency tolerance nvme: release namespace SRCU protection before performing controller ioctls nvme: merge nvme_ns_ioctl into nvme_ioctl nvme: remove the ifdef around nvme_nvm_ioctl nvme: fix srcu locking on error return in nvme_get_ns_from_disk nvme: Fix known effects nvme-pci: Sync queues on reset nvme-pci: Unblock reset_work on IO failure nvme-pci: Don't disable on timeout in reset state nvme-pci: Fix controller freeze wait disabling
2019-05-23tools/io_uring: sync with liburingJens Axboe5-61/+118
Various fixes and changes have been applied to liburing since we copied some select bits to the kernel testing/examples part, sync up with liburing to get those changes. Most notable is the change that split the CQE reading into the peek and seen event, instead of being just a single function. Also fixes an unsigned wrap issue in io_uring_submit(), leak of 'fd' in setup if we fail, and various other little issues. Signed-off-by: Jens Axboe <[email protected]>
2019-05-23tools/io_uring: fix Makefile for pthread library linkJens Axboe1-1/+1
Currently fails with: io_uring-bench.o: In function `main': /home/axboe/git/linux-block/tools/io_uring/io_uring-bench.c:560: undefined reference to `pthread_create' /home/axboe/git/linux-block/tools/io_uring/io_uring-bench.c:588: undefined reference to `pthread_join' collect2: error: ld returned 1 exit status Makefile:11: recipe for target 'io_uring-bench' failed make: *** [io_uring-bench] Error 1 Move -lpthread to the end. Signed-off-by: Jens Axboe <[email protected]>
2019-05-23blk-mq: fix hang caused by freeze/unfreeze sequenceBob Liu3-11/+18
The following is a description of a hang in blk_mq_freeze_queue_wait(). The hang happens on attempt to freeze a queue while another task does queue unfreeze. The root cause is an incorrect sequence of percpu_ref_resurrect() and percpu_ref_kill() and as a result those two can be swapped: CPU#0 CPU#1 ---------------- ----------------- q1 = blk_mq_init_queue(shared_tags) q2 = blk_mq_init_queue(shared_tags): blk_mq_add_queue_tag_set(shared_tags): blk_mq_update_tag_set_depth(shared_tags): list_for_each_entry() blk_mq_freeze_queue(q1) > percpu_ref_kill() > blk_mq_freeze_queue_wait() blk_cleanup_queue(q1) blk_mq_freeze_queue(q1) > percpu_ref_kill() ^^^^^^ freeze_depth can't guarantee the order blk_mq_unfreeze_queue() > percpu_ref_resurrect() > blk_mq_freeze_queue_wait() ^^^^^^ Hang here!!!! This wrong sequence raises kernel warning: percpu_ref_kill_and_confirm called more than once on blk_queue_usage_counter_release! WARNING: CPU: 0 PID: 11854 at lib/percpu-refcount.c:336 percpu_ref_kill_and_confirm+0x99/0xb0 But the most unpleasant effect is a hang of a blk_mq_freeze_queue_wait(), which waits for a zero of a q_usage_counter, which never happens because percpu-ref was reinited (instead of being killed) and stays in PERCPU state forever. How to reproduce: - "insmod null_blk.ko shared_tags=1 nr_devices=0 queue_mode=2" - cpu0: python Script.py 0; taskset the corresponding process running on cpu0 - cpu1: python Script.py 1; taskset the corresponding process running on cpu1 Script.py: ------ #!/usr/bin/python3 import os import sys while True: on = "echo 1 > /sys/kernel/config/nullb/%s/power" % sys.argv[1] off = "echo 0 > /sys/kernel/config/nullb/%s/power" % sys.argv[1] os.system(on) os.system(off) ------ This bug was first reported and fixed by Roman, previous discussion: [1] Message id: [email protected] [2] Message id: [email protected] [3] https://patchwork.kernel.org/patch/9268199/ Reviewed-by: Hannes Reinecke <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Roman Pen <[email protected]> Signed-off-by: Bob Liu <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: remove the bi_seg_{front,back}_size fields in struct bioChristoph Hellwig2-89/+12
At this point these fields aren't used for anything, so we can remove them. Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: remove the segment size check in bio_will_gapChristoph Hellwig1-18/+1
We fundamentally do not have a maximum segement size for devices with a virt boundary. So don't bother checking it, especially given that the existing checks didn't properly work to start with as we never fully update the front/back segment size and miss the bi_seg_front_size that wuld have been required for some cases. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: force an unlimited segment size on queues with a virt boundaryChristoph Hellwig1-0/+11
We currently fail to update the front/back segment size in the bio when deciding to allow an otherwise gappy segement to a device with a virt boundary. The reason why this did not cause problems is that devices with a virt boundary fundamentally don't use segments as we know it and thus don't care. Make that assumption formal by forcing an unlimited segement size in this case. Fixes: f6970f83ef79 ("block: don't check if adjacent bvecs in one bio can be mergeable") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23block: don't decrement nr_phys_segments for physically contigous segmentsChristoph Hellwig1-22/+1
Currently ll_merge_requests_fn, unlike all other merge functions, reduces nr_phys_segments by one if the last segment of the previous, and the first segment of the next segement are contigous. While this seems like a nice solution to avoid building smaller than possible requests it causes a mismatch between the segments actually present in the request and those iterated over by the bvec iterators, including __rq_for_each_bio. This can for example mistrigger the single segment optimization in the nvme-pci driver, and might lead to mismatching nr_phys_segments number when recalculating the number of request when inserting a cloned request. We could possibly work around this by making the bvec iterators take the front and back segment size into account, but that would require moving them from the bio to the bio_iter and spreading this mess over all users of bvecs. Or we could simply remove this optimization under the assumption that most users already build good enough bvecs, and that the bio merge patch never cared about this optimization either. The latter is what this patch does. dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests"). Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Hannes Reinecke <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23sbitmap: fix improper use of smp_mb__before_atomic()Andrea Parri1-1/+1
This barrier only applies to the read-modify-write operations; in particular, it does not apply to the atomic_set() primitive. Replace the barrier with an smp_mb(). Fixes: 6c0ca7ae292ad ("sbitmap: fix wakeup hang after sbq resize") Cc: [email protected] Reported-by: "Paul E. McKenney" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Andrea Parri <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Omar Sandoval <[email protected]> Cc: Ming Lei <[email protected]> Cc: [email protected] Cc: "Paul E. McKenney" <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23bio: fix improper use of smp_mb__before_atomic()Andrea Parri1-1/+1
This barrier only applies to the read-modify-write operations; in particular, it does not apply to the atomic_set() primitive. Replace the barrier with an smp_mb(). Fixes: dac56212e8127 ("bio: skip atomic inc/dec of ->bi_cnt for most use cases") Cc: [email protected] Reported-by: "Paul E. McKenney" <[email protected]> Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Andrea Parri <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Ming Lei <[email protected]> Cc: [email protected] Cc: "Paul E. McKenney" <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23aoe: list new maintainer for aoe driverEd Cashin1-1/+1
Justin Sanders, who has extensive experience with ATA over Ethernet in general and AoE SCSI and block-device drivers in particular, is ready to take on the role of aoe maintainer. The driver needs a more active maintainer. Signed-off-by: Ed Cashin <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-05-23drm/vc4: Allocate binner bo when starting to use the V3DPaul Kocialkowski6-20/+125
The binner BO is not required until the V3D is in use, so avoid allocating it at probe and do it on the first non-dumb BO allocation. Keep track of which clients are using the V3D and liberate the buffer when there is none left, using a kref. Protect the logic with a mutex to avoid race conditions. The binner BO is created at the time of the first render ioctl and is destroyed when there is no client and no exec job using it left. The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid enabling it before having allocated a binner bo. We also want to keep the BO alive during runtime suspend/resume to avoid failing to allocate it at resume. This happens when the CMA pool is full at that point and results in a hard crash. Signed-off-by: Paul Kocialkowski <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/vc4: Check for the binner bo before handling OOM interruptPaul Kocialkowski1-0/+3
Since the OOM interrupt directly deals with the binner bo, it doesn't make sense to try and handle it without a binner buffer registered. Signed-off-by: Paul Kocialkowski <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-05-23drm/vc4: Check for V3D before binner bo allocPaul Kocialkowski1-0/+3
Check that we have a V3D device registered before attempting to allocate a binner buffer object. Signed-off-by: Paul Kocialkowski <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]