summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-06-15ASoC: SOF: Intel: hda: Clear RIRB status before reading WPBrent Lu
Port commit 6d011d5057ff ("ALSA: hda: Clear RIRB status before reading WP") from legacy HDA driver to fix the get response timeout issue. Current SOF driver does not suffer from this issue because sync write is enabled in hda_init. The issue will come back if the sync write is disabled for some reason. Signed-off-by: Brent Lu <brent.lu@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/1591959048-15813-1-git-send-email-brent.lu@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15ASoC: rt1015: Update rt1015 default register value according to spec ↵Jack Yu
modification. Update rt1015 default register value according to spec modification. Signed-off-by: Jack Yu <jack.yu@realtek.com> Link: https://lore.kernel.org/r/20200615032433.31061-1-jack.yu@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15ASoC: qcom: common: set correct directions for dailinksSrinivas Kandagatla
Currently both FE and BE dai-links are configured bi-directional, However the DSP BE dais are only single directional, so set the directions as supported by the BE dais. Fixes: c25e295cd77b (ASoC: qcom: Add support to parse common audio device nodes) Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200612123711.29130-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15ASoc: q6afe: add support to get port directionSrinivas Kandagatla
This patch adds support to q6afe_is_rx_port() to get direction of DSP BE dai port, this is useful for setting dailink directions correctly. Fixes: c25e295cd77b (ASoC: qcom: Add support to parse common audio device nodes) Reported-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200612123711.29130-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15ASoC: soc-pcm: fix checks for multi-cpu FE dailinksPierre-Louis Bossart
soc_dpcm_fe_runtime_update() is called for all dailinks, and we want to first discard all back-ends, then deal with front-ends. The existing code first reports an error with multi-cpu front-ends, and that check needs to be moved after we know that we are dealing with a front-end. Fixes: 6e1276a5e613d ('ASoC: Return error if the function does not support multi-cpu') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> BugLink: https://github.com/thesofproject/linux/issues/1970 Link: https://lore.kernel.org/r/20200612203507.25621-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15ASoC: rt5682: Let dai clks be registered whether mclk exists or notderek.fang
According to ideal rt5682 CCF, the root clk is mclk. But in some platforms, mclk is not exported to CCF. In this condition, rt5682_register_dai_clks will not be called. This patch lets dai clks could be registered whether mclk exists or not. Signed-off-by: derek.fang <derek.fang@realtek.com> Link: https://lore.kernel.org/r/1591938925-1070-5-git-send-email-derek.fang@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15RDMA/mlx5: Remove duplicated assignment to resp.response_lengthColin Ian King
The assignment to resp.response_length is never read since it is being updated again on the next statement. The assignment is redundant so removed it. Fixes: a645a89d9a78 ("RDMA/mlx5: Return ECE DC support") Link: https://lore.kernel.org/r/20200604143902.56021-1-colin.king@canonical.com Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-06-15kvm/svm: disable KCSAN for svm_vcpu_run()Qian Cai
For some reasons, running a simple qemu-kvm command with KCSAN will reset AMD hosts. It turns out svm_vcpu_run() could not be instrumented. Disable it for now. # /usr/libexec/qemu-kvm -name ubuntu-18.04-server-cloudimg -cpu host -smp 2 -m 2G -hda ubuntu-18.04-server-cloudimg.qcow2 === console output === Kernel 5.6.0-next-20200408+ on an x86_64 hp-dl385g10-05 login: <...host reset...> HPE ProLiant System BIOS A40 v1.20 (03/09/2018) (C) Copyright 1982-2018 Hewlett Packard Enterprise Development LP Early system initialization, please wait... Signed-off-by: Qian Cai <cai@lca.pw> Message-Id: <20200415153709.1559-1-cai@lca.pw> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-15ASoC: soc-topology: use devm_snd_soc_register_dai()Pierre-Louis Bossart
Use devm_ to avoid use-after-free KASAN reports and simplify error handling. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> BugLink: https://github.com/thesofproject/linux/issues/2186 Link: https://lore.kernel.org/r/20200612205938.26415-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15ASoC: soc-devres: add devm_snd_soc_register_dai()Pierre-Louis Bossart
The registration of DAIs may be done at two distinct times, once during a component registration and later when loading a topology. Since devm_ managed resources are freed in the reverse order they were allocated, when a component starts unregistering DAIs by walking through the DAI list, the memory allocated for the topology-registered DAIs was freed already, which leads to 100% reproducible KASAN use-after-free reports. This patch suggests a new devm_ function to force the DAI list to be updated prior to freeing the memory chunks referenced by the list pointers. Suggested-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> BugLink: https://github.com/thesofproject/linux/issues/2186 Link: https://lore.kernel.org/r/20200612205938.26415-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-15efi: Replace zero-length array and use struct_size() helperGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. Lastly, make use of the sizeof_field() helper instead of an open-coded version. This issue was found with the help of Coccinelle and audited _manually_. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20200527171425.GA4053@embeddedor Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-15efivarfs: Don't return -EINTR when rate-limiting readsTony Luck
Applications that read EFI variables may see a return value of -EINTR if they exceed the rate limit and a signal delivery is attempted while the process is sleeping. This is quite surprising to the application, which probably doesn't have code to handle it. Change the interruptible sleep to a non-interruptible one. Reported-by: Lennart Poettering <mzxreary@0pointer.de> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20200528194905.690-3-tony.luck@intel.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-15efivarfs: Update inode modification time for successful writesTony Luck
Some applications want to be able to see when EFI variables have been updated. Update the modification time for successful writes. Reported-by: Lennart Poettering <mzxreary@0pointer.de> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20200528194905.690-2-tony.luck@intel.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-15efi/esrt: Fix reference count leak in esre_create_sysfs_entry.Qiushi Wu
kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 0bb549052d33 ("efi: Add esrt support") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-15powerpc: Fix kernel crash in show_instructions() w/DEBUG_VIRTUALAneesh Kumar K.V
With CONFIG_DEBUG_VIRTUAL=y, we can hit a BUG() if we take a hard lockup watchdog interrupt when in OPAL mode. This happens in show_instructions() if the kernel takes the watchdog NMI IPI, or any other interrupt, with MSR_IR == 0. show_instructions() updates the variable pc in the loop and the second iteration will result in BUG(). We hit the BUG_ON due the below check in __va() #define __va(x) ({ VIRTUAL_BUG_ON((unsigned long)(x) >= PAGE_OFFSET); (void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET); }) Fix it by moving the check out of the loop. Also update nip so that the nip == pc check still matches. Fixes: 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [mpe: Use IS_ENABLED(), massage change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200524093822.423487-1-aneesh.kumar@linux.ibm.com
2020-06-15efi/tpm: Verify event log header before parsingFabian Vogt
It is possible that the first event in the event log is not actually a log header at all, but rather a normal event. This leads to the cast in __calc_tpm2_event_size being an invalid conversion, which means that the values read are effectively garbage. Depending on the first event's contents, this leads either to apparently normal behaviour, a crash or a freeze. While this behaviour of the firmware is not in accordance with the TCG Client EFI Specification, this happens on a Dell Precision 5510 with the TPM enabled but hidden from the OS ("TPM On" disabled, state otherwise untouched). The EFI firmware claims that the TPM is present and active and that it supports the TCG 2.0 event log format. Fortunately, this can be worked around by simply checking the header of the first event and the event log header signature itself. Commit b4f1874c6216 ("tpm: check event log version before reading final events") addressed a similar issue also found on Dell models. Fixes: 6b0326190205 ("efi: Attempt to get the TCG2 event log in the boot stub") Signed-off-by: Fabian Vogt <fvogt@suse.de> Link: https://lore.kernel.org/r/1927248.evlx2EsYKh@linux-e202.suse.de Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1165773 Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-15x86/cpu: Reinitialize IA32_FEAT_CTL MSR on BSP during wakeupSean Christopherson
Reinitialize IA32_FEAT_CTL on the BSP during wakeup to handle the case where firmware doesn't initialize or save/restore across S3. This fixes a bug where IA32_FEAT_CTL is left uninitialized and results in VMXON taking a #GP due to VMX not being fully enabled, i.e. breaks KVM. Use init_ia32_feat_ctl() to "restore" IA32_FEAT_CTL as it already deals with the case where the MSR is locked, and because APs already redo init_ia32_feat_ctl() during suspend by virtue of the SMP boot flow being used to reinitialize APs upon wakeup. Do the call in the early wakeup flow to avoid dependencies in the syscore_ops chain, e.g. simply adding a resume hook is not guaranteed to work, as KVM does VMXON in its own resume hook, kvm_resume(), when KVM has active guests. Fixes: 21bd3467a58e ("KVM: VMX: Drop initialization of IA32_FEAT_CTL MSR") Reported-by: Brad Campbell <lists2009@fnarfbargle.com> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Tested-by: Brad Campbell <lists2009@fnarfbargle.com> Cc: stable@vger.kernel.org # v5.6 Link: https://lkml.kernel.org/r/20200608174134.11157-1-sean.j.christopherson@intel.com
2020-06-15docs/arm64: Fix typo'd #define in sve.rstDave Martin
sve.rst describes a flag PR_SVE_SET_VL_INHERIT for the PR_SVE_SET_VL prctl, but there is no flag of this name. The flag is shared between the _GET and _SET calls, so the _SET prefix was dropped, giving the name PR_SVE_VL_INHERIT in the headers. Fix it. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Link: https://lore.kernel.org/r/1591808590-20210-2-git-send-email-Dave.Martin@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-06-15arm64: remove TEXT_OFFSET randomizationArd Biesheuvel
TEXT_OFFSET was recently changed to 0x0, in preparation for its removal at a later stage, and a warning is emitted into the kernel log when the bootloader appears to have failed to take the TEXT_OFFSET image header value into account. Ironically, this warning itself fails to take TEXT_OFFSET into account, and compares the kernel image's alignment modulo 2M against a hardcoded value of 0x0, and so the warning will trigger spuriously when TEXT_OFFSET randomization is enabled. Given the intent to get rid of TEXT_OFFSET entirely, let's fix this oversight by just removing support for TEXT_OFFSET randomization. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20200615101939.634391-1-ardb@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2020-06-15x86/entry, bug: Comment the instrumentation_begin() usage for WARN()Peter Zijlstra
Explain the rationale for annotating WARN(), even though, strictly speaking printk() and friends are very much not safe in many of the places we put them. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2020-06-15x86/entry, ubsan, objtool: Whitelist __ubsan_handle_*()Peter Zijlstra
The UBSAN instrumentation only inserts external CALLs when things go 'BAD', much like WARN(). So treat them similar to WARN()s for noinstr, that is: allow them, at the risk of taking the machine down, to get their message out. Suggested-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Marco Elver <elver@google.com>
2020-06-15x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline()Peter Zijlstra
vmlinux.o: warning: objtool: exc_nmi()+0x12: call to cpumask_test_cpu.constprop.0() leaves .noinstr.text section vmlinux.o: warning: objtool: mce_check_crashing_cpu()+0x12: call to cpumask_test_cpu.constprop.0()leaves .noinstr.text section cpumask_test_cpu() test_bit() instrument_atomic_read() arch_test_bit() Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2020-06-15compiler_types.h: Add __no_sanitize_{address,undefined} to noinstrMarco Elver
Adds the portable definitions for __no_sanitize_address, and __no_sanitize_undefined, and subsequently changes noinstr to use the attributes to disable instrumentation via KASAN or UBSAN. Reported-by: syzbot+dc1fa714cb070b184db5@syzkaller.appspotmail.com Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Link: https://lore.kernel.org/lkml/000000000000d2474c05a6c938fe@google.com/
2020-06-15kasan: Bump required compiler versionMarco Elver
Adds config variable CC_HAS_WORKING_NOSANITIZE_ADDRESS, which will be true if we have a compiler that does not fail builds due to no_sanitize_address functions. This does not yet mean they work as intended, but for automated build-tests, this is the minimum requirement. For example, we require that __always_inline functions used from no_sanitize_address functions do not generate instrumentation. On GCC <= 7 this fails to build entirely, therefore we make the minimum version GCC 8. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Andrey Konovalov <andreyknvl@google.com> Link: https://lkml.kernel.org/r/20200602175859.GC2604@hirez.programming.kicks-ass.net
2020-06-15x86, kcsan: Add __no_kcsan to noinstrPeter Zijlstra
The 'noinstr' function attribute means no-instrumentation, this should very much include *SAN. Because lots of that is broken at present, only include KCSAN for now, as that is limited to clang11, which has sane function attribute behaviour. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2020-06-15kcsan: Remove __no_kcsan_or_inlinePeter Zijlstra
There are no more user of this function attribute, also, with us now actively supporting '__no_kcsan inline' it doesn't make sense to have in any case. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2020-06-15x86, kcsan: Remove __no_kcsan_or_inline usagePeter Zijlstra
Now that KCSAN relies on -tsan-distinguish-volatile we no longer need the annotation for constant_test_bit(). Remove it. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2020-06-15efi/x86: Fix build with gcc 4Arvind Sankar
Commit bbf8e8b0fe04 ("efi/libstub: Optimize for size instead of speed") changed the optimization level for the EFI stub to -Os from -O2. Andrey Ignatov reports that this breaks the build with gcc 4.8.5. Testing on godbolt.org, the combination of -Os, -fno-asynchronous-unwind-tables, and ms_abi functions doesn't work, failing with the error: sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it This does appear to work with gcc 4.9 onwards. Add -maccumulate-outgoing-args explicitly to unbreak the build with pre-4.9 versions of gcc. Reported-by: Andrey Ignatov <rdna@fb.com> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200605150638.1011637-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-06-15drm/i915: work around false-positive maybe-uninitialized warningArnd Bergmann
gcc-9 gets confused by the code flow in check_dirty_whitelist: drivers/gpu/drm/i915/gt/selftest_workarounds.c: In function 'check_dirty_whitelist': drivers/gpu/drm/i915/gt/selftest_workarounds.c:492:17: error: 'rsvd' may be used uninitialized in this function [-Werror=maybe-uninitialized] I could not figure out a good way to do this in a way that gcc understands better, so initialize the variable to zero, as last resort. Fixes: aee20aaed887 ("drm/i915: Implement read-only support in whitelist selftest") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200527140526.1458215-2-arnd@arndb.de (cherry picked from commit cc649a9eafc1ef5c40db023084cb94422d08aa84) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-06-15drm/i915/pmu: avoid an maybe-uninitialized warningArnd Bergmann
Conditional spinlocks make it hard for gcc and for lockdep to follow the code flow. This one causes a warning with at least gcc-9 and higher: In file included from include/linux/irq.h:14, from drivers/gpu/drm/i915/i915_pmu.c:7: drivers/gpu/drm/i915/i915_pmu.c: In function 'i915_sample': include/linux/spinlock.h:289:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized] 289 | _raw_spin_unlock_irqrestore(lock, flags); \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/i915_pmu.c:288:17: note: 'flags' was declared here 288 | unsigned long flags; | ^~~~~ Split out the part between the locks into a separate function for readability and to let the compiler figure out what the logic actually is. Fixes: d79e1bd676f0 ("drm/i915/pmu: Only use exclusive mmio access for gen7") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200527140526.1458215-1-arnd@arndb.de (cherry picked from commit 6ec81b82732e2b4a5ac0853fd33919ff1ca94238) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-06-15drm/i915/gt: Incorporate the virtual engine into timeslicingChris Wilson
It was quite the oversight to only factor in the normal queue to decide the timeslicing switch priority. By leaving out the next virtual request from the priority decision, we would not timeslice the current engine if there was an available virtual request. Testcase: igt/gem_exec_balancer/sliced Fixes: 3df2deed411e ("drm/i915/execlists: Enable timeslice on partial virtual engine dequeue") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200519132046.22443-3-chris@chris-wilson.co.uk (cherry picked from commit 6ad249ba59badc7ff157d4db1f835748f0e2c9b6) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2020-06-15KVM: MIPS: Fix a build error for !CPU_LOONGSON64Huacai Chen
During the KVM merging progress, a CONFIG_CPU_LOONGSON64 guard in commit 7f2a83f1c2a941ebfee53 ("KVM: MIPS: Add CPUCFG emulation for Loongson-3") is missing by accident. So add it to avoid building error. Fixes: 7f2a83f1c2a941ebfee53 ("KVM: MIPS: Add CPUCFG emulation for Loongson-3") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Huacai Chen <chenhc@lemote.com> Message-Id: <1592204215-28704-1-git-send-email-chenhc@lemote.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-06-15syscalls: Fix offset type of ksys_ftruncate()Jiri Slaby
After the commit below, truncate() on x86 32bit uses ksys_ftruncate(). But ksys_ftruncate() truncates the offset to unsigned long. Switch the type of offset to loff_t which is what do_sys_ftruncate() expects. Fixes: 121b32a58a3a (x86/entry/32: Use IA32-specific wrappers for syscalls taking 64-bit arguments) Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Brian Gerst <brgerst@gmail.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200610114851.28549-1-jslaby@suse.cz
2020-06-15drm/ttm: Fix dma_fence refcnt leak when adding move fenceXiyu Yang
ttm_bo_add_move_fence() invokes dma_fence_get(), which returns a reference of the specified dma_fence object to "fence" with increased refcnt. When ttm_bo_add_move_fence() returns, local variable "fence" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of ttm_bo_add_move_fence(). When no_wait_gpu flag is equals to true, the function forgets to decrease the refcnt increased by dma_fence_get(), causing a refcnt leak. Fix this issue by calling dma_fence_put() when no_wait_gpu flag is equals to true. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/370221/ Signed-off-by: Christian König <christian.koenig@amd.com>
2020-06-15drm/ttm: Fix dma_fence refcnt leak in ttm_bo_vm_fault_reservedXiyu Yang
ttm_bo_vm_fault_reserved() invokes dma_fence_get(), which returns a reference of the specified dma_fence object to "moving" with increased refcnt. When ttm_bo_vm_fault_reserved() returns, local variable "moving" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in several exception handling paths of ttm_bo_vm_fault_reserved(). When those error scenarios occur such as "err" equals to -EBUSY, the function forgets to decrease the refcnt increased by dma_fence_get(), causing a refcnt leak. Fix this issue by calling dma_fence_put() when no_wait_gpu flag is equals to true. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/370219/ Signed-off-by: Christian König <christian.koenig@amd.com>
2020-06-15crypto: drbg - always try to free Jitter RNG instanceStephan Müller
The Jitter RNG is unconditionally allocated as a seed source follwoing the patch 97f2650e5040. Thus, the instance must always be deallocated. Reported-by: syzbot+2e635807decef724a1fa@syzkaller.appspotmail.com Fixes: 97f2650e5040 ("crypto: drbg - always seeded with SP800-90B ...") Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15crypto: marvell/octeontx - Fix a potential NULL dereferenceDan Carpenter
Smatch reports that: drivers/crypto/marvell/octeontx/otx_cptvf_algs.c:132 otx_cpt_aead_callback() warn: variable dereferenced before check 'cpt_info' (see line 121) This function is called from process_pending_queue() as: drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.c 599 /* 600 * Call callback after current pending entry has been 601 * processed, we don't do it if the callback pointer is 602 * invalid. 603 */ 604 if (callback) 605 callback(res_code, areq, cpt_info); It does appear to me that "cpt_info" can be NULL so this could lead to a NULL dereference. Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15crypto: algboss - don't wait during notifier callbackEric Biggers
When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST is sent to crypto_chain. cryptomgr_schedule_probe() handles this by starting a thread to instantiate the template, then waiting for this thread to complete via crypto_larval::completion. This can deadlock because instantiating the template may require loading modules, and this (apparently depending on userspace) may need to wait for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But crc-t10dif's module_init function uses crypto_register_notifier() and therefore takes crypto_chain.rwsem for write. That can't proceed until the notifier callback has finished, as it holds this semaphore for read. Fix this by removing the wait on crypto_larval::completion from within cryptomgr_schedule_probe(). It's actually unnecessary because crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending CRYPTO_MSG_ALG_REQUEST. This only actually became a problem in v4.20 due to commit b76377543b73 ("crc-t10dif: Pick better transform if one becomes available"), but the unnecessary wait was much older. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159 Reported-by: Mike Gerow <gerow@google.com> Fixes: 398710379f51 ("crypto: algapi - Move larval completion into algboss") Cc: <stable@vger.kernel.org> # v3.6+ Cc: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Reported-by: Kai Lüke <kai@kinvolk.io> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15crypto: caam - fix typosHeinrich Schuchardt
Fix CAAM related typos. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15crypto: ccp - Fix sparse warnings in sev-devHerbert Xu
This patch fixes a bunch of sparse warnings in sev-dev where the __user marking is incorrectly handled. Reported-by: kbuild test robot <lkp@intel.com> Fixes: 7360e4b14350 ("crypto: ccp: Implement SEV_PEK_CERT_IMPORT...") Fixes: e799035609e1 ("crypto: ccp: Implement SEV_PEK_CSR ioctl...") Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT...") Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15crypto: hisilicon - Cap block size at 2^31Herbert Xu
The function hisi_acc_create_sg_pool may allocate a block of memory of size PAGE_SIZE * 2^(MAX_ORDER - 1). This value may exceed 2^31 on ia64, which would overflow the u32. This patch caps it at 2^31. Reported-by: kernel test robot <lkp@intel.com> Fixes: d8ac7b85236b ("crypto: hisilicon - fix large sgl memory...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15crypto: algif_skcipher - Cap recv SG list at ctx->usedHerbert Xu
Somewhere along the line the cap on the SG list length for receive was lost. This patch restores it and removes the subsequent test which is now redundant. Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of...") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15hwrng: ks-sa - Fix runtime PM imbalance on errorDinghao Liu
pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-06-15x86/resctrl: Fix memory bandwidth counter width for AMDBabu Moger
Memory bandwidth is calculated reading the monitoring counter at two intervals and calculating the delta. It is the software’s responsibility to read the count often enough to avoid having the count roll over _twice_ between reads. The current code hardcodes the bandwidth monitoring counter's width to 24 bits for AMD. This is due to default base counter width which is 24. Currently, AMD does not implement the CPUID 0xF.[ECX=1]:EAX to adjust the counter width. But, the AMD hardware supports much wider bandwidth counter with the default width of 44 bits. Kernel reads these monitoring counters every 1 second and adjusts the counter value for overflow. With 24 bits and scale value of 64 for AMD, it can only measure up to 1GB/s without overflowing. For the rates above 1GB/s this will fail to measure the bandwidth. Fix the issue setting the default width to 44 bits by adjusting the offset. AMD future products will implement CPUID 0xF.[ECX=1]:EAX. [ bp: Let the line stick out and drop {}-brackets around a single statement. ] Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/159129975546.62538.5656031125604254041.stgit@naples-babu.amd.com
2020-06-15ALSA: usb-audio: Set 48 kHz rate for RodecasterChristopher Swenson
Like the Line6 devices, the Rode Rodecaster Pro does not support UAC2_CS_RANGE and only supports a sample rate of 48 kHz. Tested against a Rode Rodecaster Pro. Tested-by: Christopher Swenson <swenson@swenson.io> Signed-off-by: Christopher Swenson <swenson@swenson.io> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/ebdb9e72-9649-0b5e-b9b9-d757dbf26927@swenson.io Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-06-15ALSA: usb-audio: add quirk for Denon DCD-1500REYick W. Tse
fix error "clock source 41 is not valid, cannot use" [] New USB device found, idVendor=154e, idProduct=1002, bcdDevice= 1.00 [] New USB device strings: Mfr=1, Product=2, SerialNumber=0 [] Product: DCD-1500RE [] Manufacturer: D & M Holdings Inc. [] [] clock source 41 is not valid, cannot use [] usbcore: registered new interface driver snd-usb-audio Signed-off-by: Yick W. Tse <y_w_tse@yahoo.com.hk> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1373857985.210365.1592048406997@mail.yahoo.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-06-15dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOLDavid Rientjes
DMA_REMAP is an unnecessary requirement for AMD SEV, which requires DMA_COHERENT_POOL, so avoid selecting it when it is otherwise unnecessary. The only other requirement for DMA coherent pools is DMA_DIRECT_REMAP, so ensure that properly selects the config option when needed. Fixes: 82fef0ad811f ("x86/mm: unencrypted non-blocking DMA allocations use coherent pools") Reported-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Signed-off-by: David Rientjes <rientjes@google.com> Tested-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-06-15esp, ah: modernize the crypto algorithm selectionsEric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are out-of-date with the guidance of RFC 8221, which lists the legacy algorithms MD5 and DES as "MUST NOT" be implemented, and some more modern algorithms like AES-GCM and HMAC-SHA256 as "MUST" be implemented. But the options select the legacy algorithms, not the modern ones. Therefore, modify these options to select the MUST algorithms -- and *only* the MUST algorithms. Also improve the help text. Note that other algorithms may still be explicitly enabled in the kconfig, and the choice of which to actually use is still controlled by userspace. This change only modifies the list of algorithms for which kernel support is guaranteed to be present. Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Suggested-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Corentin Labbe <clabbe@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2020-06-15esp: select CRYPTO_SEQIVEric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most users since GCM and several other encryption algorithms require "seqiv" -- and RFC 8221 lists AES-GCM as "MUST" be implemented. Just make XFRM_ESP select CRYPTO_SEQIV. Fixes: f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Corentin Labbe <clabbe@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2020-06-15esp, ah: consolidate the crypto algorithm selectionsEric Biggers
Instead of duplicating the algorithm selections between INET_AH and INET6_AH and between INET_ESP and INET6_ESP, create new tristates XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be selected by the corresponding INET* options. Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Corentin Labbe <clabbe@baylibre.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
generated by cgit (git 2.34.1) at 2025-09-13 22:28:42 +0000