- 24 Feb, 2020 40 commits
-
-
Marc Zyngier authored
[ Upstream commit 926b5dfa ] We currently allocate redistributor region structures for individual redistributors when ACPI doesn't present us with compact MMIO regions covering multiple redistributors. It turns out that we allocate these structures even when the redistributor is flagged as disabled by ACPI. It works fine until someone actually tries to tarse one of these structures, and access the corresponding MMIO region. Instead, track the number of enabled redistributors, and only allocate what is required. This makes sure that there is no invalid data to misuse. Signed-off-by:
Marc Zyngier <maz@kernel.org> Reported-by:
Heyi Guo <guoheyi@huawei.com> Tested-by:
Sasha Levin <sashal@kernel.org>
-
Dor Askayo authored
[ Upstream commit bb67bfd2 ] This allocation isn't required and can fail when resuming from suspend. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009 Signed-off-by:
Dor Askayo <dor.askayo@gmail.com> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit a55e601b ] gcc -O3 warns about a dummy variable that is passed down into rbd_img_fill_nodata without being initialized: drivers/block/rbd.c: In function 'rbd_img_fill_nodata': drivers/block/rbd.c:2573:13: error: 'dummy' is used uninitialized in this function [-Werror=uninitialized] fctx->iter = *fctx->pos; Since this is a dummy, I assume the warning is harmless, but it's better to initialize it anyway and avoid the warning. Fixes: mmtom ("init/Kconfig: enable -O3 for all arches") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Xiubo Li authored
[ Upstream commit 97820058 ] If all the MDS daemons are down for some reason, then the first mount attempt will fail with EIO after the mount request times out. A mount attempt will also fail with EIO if all of the MDS's are laggy. This patch changes the code to return -EHOSTUNREACH in these situations and adds a pr_info error message to help the admin determine the cause. URL: https://tracker.ceph.com/issues/4386 Signed-off-by:
Xiubo Li <xiubli@redhat.com> Reviewed-by:
Jeff Layton <jlayton@kernel.org> Signed-off-by:
-
Christophe Leroy authored
[ Upstream commit 0f9aee0c ] Running vdsotest leaves many times the following log: [ 79.629901] vdsotest[396]: User access of kernel address (ffffffff) - exploit attempt? (uid: 0) A pointer set to (-1) is likely a programming error similar to a NULL pointer and is not worth logging as an exploit attempt. Don't log user accesses to 0xffffffff. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/0728849e826ba16f1fbd6fa7f5c6cc87bd64e097.1577087627.git.christophe.leroy@c-s.fr Signed-off-by:
-
Vasily Averin authored
[ Upstream commit 90435a78 ] If seq_file .next fuction does not change position index, read after some lseek can generate an unexpected output. See also: https://bugzilla.kernel.org/show_bug.cgi?id=206283 v1 -> v2: removed missed increment in end of function Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/eca84fdd-c374-a154-d874-6c7b55fc3bc4@virtuozzo.com Signed-off-by:
-
Ronnie Sahlberg authored
[ Upstream commit fe129268 ] RHBZ: 1760879 Fix an oops in match_prepath() by making sure that the prepath string is not NULL before we pass it into strcmp(). This is similar to other checks we make for example in cifs_root_iget() Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Paulo Alcantara (SUSE) authored
[ Upstream commit 5739375e ] Starting from 4a367dc0 , we must set the mount options based on the DFS full path rather than the resolved target, that is, cifs_mount() will be responsible for resolving the DFS link (cached) as well as performing failover to any other targets in the referral. Signed-off-by:
Paulo Alcantara (SUSE) <pc@cjr.nz> Reported-by:
Martijn de Gouw <martijn.de.gouw@prodrive-technologies.com> Fixes: 4a367dc0 ("cifs: Add support for failover in cifs_mount()") Link: https://lore.kernel.org/linux-cifs/39643d7d-2abb-14d3-ced6-c394fab9a777@prodrive-technologies.com Tested-by:
-
Steve French authored
[ Upstream commit 463a7b45 ] static analysis with Coverity detected an issue with the following commit: Author: Paulo Alcantara (SUSE) <pc@cjr.nz> Date: Wed Dec 4 17:38:03 2019 -0300 cifs: Avoid doing network I/O while holding cache lock Addresses-Coverity: ("Uninitialized pointer read") Reported-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit c2f9a4e4 ] The loop counter addr is a u16 where as the upper limit of the loop is an int. In the unlikely event that the il->cfg->eeprom_size is greater than 64K then we end up with an infinite loop since addr will wrap around an never reach upper loop limit. Fix this by making addr an int. Addresses-Coverity: ("Infinite loop") Fixes: be663ab6 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965") Signed-off-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Yan-Hsuan Chuang authored
[ Upstream commit f4f84ff8 ] Sometimes the TX queue may be empty and we could possible dequeue a NULL pointer, crash the kernel. If the skb is NULL then there is nothing to do, just leave the ISR. And the TX queue should not be empty here, so print an error to see if there is anything wrong for DMA ring. Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver") Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit b61156fb ] Clang warns: ../drivers/net/wireless/intersil/hostap/hostap_ap.c:2511:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] if (sta->tx_supp_rates & WLAN_RATE_5M5) ^ ../drivers/net/wireless/intersil/hostap/hostap_ap.c:2509:2: note: previous statement is here if (sta->tx_supp_rates & WLAN_RATE_2M) ^ 1 warning generated. This warning occurs because there is a space before the tab on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: ff1d2767 ("Add HostAP wireless driver.") Link: https://github.com/ClangBuiltLinux/linux/issues/813 Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Nicola Lunghi authored
[ Upstream commit b81cbf7a ] With firmware 2.82 Line6 changed the usb id of some of the Helix devices but the quirks is still needed. Add it to the quirk list for line6 helix family of devices. Thanks to Jens for pointing out the missing ids. Signed-off-by:
Nicola Lunghi <nick83ola@gmail.com> Link: https://lore.kernel.org/r/20200125150917.5040-1-nick83ola@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Vincenzo Frascino authored
[ Upstream commit 76950f71 ] To perform the reserve_crashkernel() operation kexec uses SECTION_SIZE to find a memblock in a range. SECTION_SIZE is not defined for nommu systems. Trying to compile kexec in these conditions results in a build error: linux/arch/arm/kernel/setup.c: In function ‘reserve_crashkernel’: linux/arch/arm/kernel/setup.c:1016:25: error: ‘SECTION_SIZE’ undeclared (first use in this function); did you mean ‘SECTIONS_WIDTH’? crash_size, SECTION_SIZE); ^~~~~~~~~~~~ SECTIONS_WIDTH linux/arch/arm/kernel/setup.c:1016:25: note: each undeclared identifier is reported only once for each function it appears in linux/scripts/Makefile.build:265: recipe for target 'arch/arm/kernel/setup.o' failed Make KEXEC depend on MMU to fix the compilation issue. Signed-off-by:
Vincenzo Frascino <vincenzo.frascino@arm.com> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Oliver O'Halloran authored
[ Upstream commit 414f5043 ] Some newer cards supported by aacraid can take up to 40s to recover after an EEH event. This causes spurious failures in the basic EEH self-test since the current maximim timeout is only 30s. Fix the immediate issue by bumping the timeout to a default of 60s, and allow the wait time to be specified via an environmental variable (EEH_MAX_WAIT). Reported-by:
Steve Best <sbest@redhat.com> Suggested-by:
Douglas Miller <dougmill@us.ibm.com> Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Signed-off-by:
-
Michael Bringmann authored
[ Upstream commit f1dbc1c5 ] Correct overflow problem in calculation and display of Maximum Memory value to syscfg. Signed-off-by:
Michael Bringmann <mwb@linux.ibm.com> [mpe: Only n_lmbs needs casting to unsigned long] Signed-off-by:
-
zhangyi (F) authored
[ Upstream commit 0e98c084 ] Commit fb7c0244 ("ext4: pass -ESHUTDOWN code to jbd2 layer") want to allow jbd2 layer to distinguish shutdown journal abort from other error cases. So the ESHUTDOWN should be taken precedence over any other errno which has already been recoded after EXT4_FLAGS_SHUTDOWN is set, but it only update errno in the journal suoerblock now if the old errno is 0. Fixes: fb7c0244 ("ext4: pass -ESHUTDOWN code to jbd2 layer") Signed-off-by:
zhangyi (F) <yi.zhang@huawei.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20191204124614.45424-4-yi.zhang@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
zhangyi (F) authored
[ Upstream commit d0a186e0 ] We invoke jbd2_journal_abort() to abort the journal and record errno in the jbd2 superblock when committing journal transaction besides the failure on submitting the commit record. But there is no need for the case and we can also invoke jbd2_journal_abort() instead of __jbd2_journal_abort_hard(). Fixes: 818d276c ("ext4: Add the journal checksum feature") Signed-off-by:
-
Lorenz Bauer authored
[ Upstream commit 51bad0f0 ] Currently, there is a lot of false positives if a single reuseport test fails. This is because expected_results and the result map are not cleared. Zero both after individual test runs, which fixes the mentioned false positives. Fixes: 91134d84 ("bpf: Test BPF_PROG_TYPE_SK_REUSEPORT") Signed-off-by:
Lorenz Bauer <lmb@cloudflare.com> Signed-off-by:
Jakub Sitnicki <jakub@cloudflare.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Acked-by:
John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20200124112754.19664-5-lmb@cloudflare.com Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit c79108bd ] The alarmtimer_suspend() function will fail if an RTC device is on a bus such as SPI or i2c and that RTC device registers and probes after alarmtimer_init() registers and probes the 'alarmtimer' platform device. This is because system wide suspend suspends devices in the reverse order of their probe. When alarmtimer_suspend() attempts to program the RTC for a wakeup it will try to program an RTC device on a bus that has already been suspended. Move the alarmtimer device registration to happen when the RTC which is used for wakeup is registered. Register the 'alarmtimer' platform device as a child of the RTC device too, so that it can be guaranteed that the RTC device won't be suspended when alarmtimer_suspend() is called. Reported-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
-
Lu Baolu authored
[ Upstream commit 857f0814 ] Address field in device TLB invalidation descriptor is qualified by the S field. If S field is zero, a single page at page address specified by address [63:12] is requested to be invalidated. If S field is set, the least significant bit in the address field with value 0b (say bit N) indicates the invalidation address range. The spec doesn't require the address [N - 1, 0] to be cleared, hence remove the unnecessary WARN_ON_ONCE(). Otherwise, the caller might set "mask = MAX_AGAW_PFN_WIDTH" in order to invalidating all the cached mappings on an endpoint, and below overflow error will be triggered. [...] UBSAN: Undefined behaviour in drivers/iommu/dmar.c:1354:3 shift exponent 64 is too large for 64-bit type 'long long unsigned int' [...] Reported-and-tested-by:
Frank <fgndev@posteo.de> Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Coly Li authored
[ Upstream commit ae3cd299 ] The patch "bcache: rework error unwinding in register_bcache" introduces a use-after-free regression in register_bcache(). Here are current code, 2510 out_free_path: 2511 kfree(path); 2512 out_module_put: 2513 module_put(THIS_MODULE); 2514 out: 2515 pr_info("error %s: %s", path, err); 2516 return ret; If some error happens and the above code path is executed, at line 2511 path is released, but referenced at line 2515. Then KASAN reports a use- after-free error message. This patch changes line 2515 in the following way to fix the problem, 2515 pr_info("error %s: %s", path?path:"", err); Signed-off-by:
Coly Li <colyli@suse.de> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit 50246693 ] Split the successful and error return path, and use one goto label for each resource to unwind. This also fixes some small errors like leaking the module reference count in the reboot case (which seems entirely harmless) or printing the wrong warning messages for early failures. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Liang Chen authored
[ Upstream commit e8547d42 ] Same as cache device, the buffer page needs to be put while freeing cached_dev. Otherwise a page would be leaked every time a cached_dev is stopped. Signed-off-by:
Liang Chen <liangchen.linux@gmail.com> Signed-off-by:
-
Nikolay Borisov authored
[ Upstream commit 1362089d ] Current code doesn't correctly handle the situation which arises when a file system that has METADATA_UUID_INCOMPAT flag set and has its FSID changed to the one in metadata uuid. This causes the incompat flag to disappear. In case of a power failure we could end up in a situation where part of the disks in a multi-disk filesystem are correctly reverted to METADATA_UUID_INCOMPAT flag unset state, while others have METADATA_UUID_INCOMPAT set and CHANGING_FSID_V2_IN_PROGRESS. This patch corrects the behavior required to handle the case where a disk of the second type is scanned first, creating the necessary btrfs_fs_devices. Subsequently, when a disk which has already completed the transition is scanned it should overwrite the data in btrfs_fs_devices. Reported-by:
Su Yue <Damenly_Su@gmx.com> Reviewed-by:
Josef Bacik <josef@toxicpanda.com> Signed-off-by:
Nikolay Borisov <nborisov@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
David Sterba authored
[ Upstream commit 68c467cb ] There's a report where objtool detects unreachable instructions, eg.: fs/btrfs/ctree.o: warning: objtool: btrfs_search_slot()+0x2d4: unreachable instruction This seems to be a false positive due to compiler version. The cause is in the ASSERT macro implementation that does the conditional check as IS_DEFINED(CONFIG_BTRFS_ASSERT) and not an #ifdef. To avoid that, use the ifdefs directly. There are still 2 reports that aren't fixed: fs/btrfs/extent_io.o: warning: objtool: __set_extent_bit()+0x71f: unreachable instruction fs/btrfs/relocation.o: warning: objtool: find_data_references()+0x4e0: unreachable instruction Co-developed-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Sergey Zakharchenko authored
[ Upstream commit 1dd2e8f9 ] This device does not function correctly in raw mode in kernel versions validating buffer sizes in bulk mode. It erroneously announces 16 bits per pixel instead of 12 for NV12 format, so it needs this quirk to fix computed frame size and avoid legitimate frames getting discarded. [Move info and div variables to local scope] Signed-off-by:
Sergey Zakharchenko <szakharchenko@digital-loggers.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Oliver O'Halloran authored
[ Upstream commit 1fb4124c ] When disabling virtual functions on an SR-IOV adapter we currently do not correctly remove the EEH state for the now-dead virtual functions. When removing the pci_dn that was created for the VF when SR-IOV was enabled we free the corresponding eeh_dev without removing it from the child device list of the eeh_pe that contained it. This can result in crashes due to the use-after-free. Signed-off-by:
Sam Bobroff <sbobroff@linux.ibm.com> Tested-by:
-
Ben Skeggs authored
[ Upstream commit 35e4909b ] Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 1d821637 ] When we unhash the cache entry, we need to handle any pending upcalls by calling cache_fresh_unlocked(). Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Peter Große authored
[ Upstream commit ef7d84ca ] Lenovo Thinkpad T420s uses the same codec as T420, so apply the same quirk to enable audio output on a docking station. Signed-off-by:
Peter Große <pegro@friiks.de> Link: https://lore.kernel.org/r/20200122180106.9351-1-pegro@friiks.de Signed-off-by:
-
Chris Down authored
[ Upstream commit 2a67a6cc ] When trying to compile with CONFIG_DEBUG_INFO_BTF enabled, I got this error: % make -s Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Compiling again without -s shows the true error (that pahole is missing), but since this is fatal, we should show the error unconditionally on stderr as well, not silence it using the `info` function. With this patch: % make -s BTF: .tmp_vmlinux.btf: pahole (pahole) is not available Failed to generate BTF for vmlinux Try to disable CONFIG_DEBUG_INFO_BTF make[3]: *** [vmlinux] Error 1 Signed-off-by:
Chris Down <chris@chrisdown.name> Signed-off-by:
Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200122000110.GA310073@chrisdown.name Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 0707cfa5 ] Currently the check that a u32 variable i is >= 0 is always true because the unsigned variable will never be negative, causing the loop to run forever. Fix this by changing the pre-decrement check to a zero check on i followed by a decrement of i. Addresses-Coverity: ("Unsigned compared against 0") Fixes: 39cc539f ("driver core: platform: Prevent resouce overflow from causing infinite loops") Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20200116175758.88396-1-colin.king@canonical.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Vasily Gorbik authored
[ Upstream commit 45f7a0da ] Currently backtrace from ftraced function does not contain ftraced function itself. e.g. for "path_openat": arch_stack_walk+0x15c/0x2d8 stack_trace_save+0x50/0x68 stack_trace_call+0x15e/0x3d8 ftrace_graph_caller+0x0/0x1c <-- ftrace code do_filp_open+0x7c/0xe8 <-- ftraced function caller do_open_execat+0x76/0x1b8 open_exec+0x52/0x78 load_elf_binary+0x180/0x1160 search_binary_handler+0x8e/0x288 load_script+0x2a8/0x2b8 search_binary_handler+0x8e/0x288 __do_execve_file.isra.39+0x6fa/0xb40 __s390x_sys_execve+0x56/0x68 system_call+0xdc/0x2d8 Ftraced function is expected in the backtrace by ftrace kselftests, which are now failing. It would also be nice to have it for clarity reasons. "ftrace_caller" itself is called without stack frame allocated for it and does not store its caller (ftraced function). Instead it simply allocates a stack frame for "ftrace_trace_function" and sets backchain to point to ftraced function stack frame (which contains ftraced function caller in saved r14). To fix this issue make "ftrace_caller" allocate a stack frame for itself just to store ftraced function for the stack unwinder. As a result backtrace looks like the following: arch_stack_walk+0x15c/0x2d8 stack_trace_save+0x50/0x68 stack_trace_call+0x15e/0x3d8 ftrace_graph_caller+0x0/0x1c <-- ftrace code path_openat+0x6/0xd60 <-- ftraced function do_filp_open+0x7c/0xe8 <-- ftraced function caller do_open_execat+0x76/0x1b8 open_exec+0x52/0x78 load_elf_binary+0x180/0x1160 search_binary_handler+0x8e/0x288 load_script+0x2a8/0x2b8 search_binary_handler+0x8e/0x288 __do_execve_file.isra.39+0x6fa/0xb40 __s390x_sys_execve+0x56/0x68 system_call+0xdc/0x2d8 Reported-by:
Sven Schnelle <sven.schnelle@ibm.com> Tested-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
[ Upstream commit 253b3c4b ] clang 10 introduces -mpacked-stack compiler option implementation. At the same time currently it does not support a combination of -mpacked-stack and -mbackchain. This leads to the following build error: clang: error: unsupported option '-mpacked-stack with -mbackchain' for target 's390x-ibm-linux' If/when clang adds support for a combination of -mpacked-stack and -mbackchain it would also require -msoft-float (like gcc does). According to Ulrich Weigand "stack slot assigned to the kernel backchain overlaps the stack slot assigned to the FPR varargs (both are required to be placed immediately after the saved r15 slot if present)." Extend -mpacked-stack compiler option support check to include all 3 options -mpacked-stack -mbackchain -msoft-float which must present to support -mpacked-stack with -mbackchain. Acked-by:
-
Masami Hiramatsu authored
[ Upstream commit 8b7e20a7 ] Add TEST opcode to Group3-2 reg=001b as same as Group3-1 does. Commit 12a78d43 ("x86/decoder: Add new TEST instruction pattern") added a TEST opcode assignment to f6 XX/001/XXX (Group 3-1), but did not add f7 XX/001/XXX (Group 3-2). Actually, this TEST opcode variant (ModRM.reg /1) is not described in the Intel SDM Vol2 but in AMD64 Architecture Programmer's Manual Vol.3, Appendix A.2 Table A-6. ModRM.reg Extensions for the Primary Opcode Map. Without this fix, Randy found a warning by insn_decoder_test related to this issue as below. HOSTCC arch/x86/tools/insn_decoder_test HOSTCC arch/x86/tools/insn_sanity TEST posttest arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. arch/x86/tools/insn_decoder_test: warning: ffffffff81000bf1: f7 0b 00 01 08 00 testl $0x80100,(%rbx) arch/x86/tools/insn_decoder_test: warning: objdump says 6 bytes, but insn_get_length() says 2 arch/x86/tools/insn_decoder_test: warning: Decoded and checked 11913894 instructions with 1 failures TEST posttest arch/x86/tools/insn_sanity: Success: decoded and checked 1000000 random instructions with 0 errors (seed:0x871ce29c) To fix this error, add the TEST opcode according to AMD64 APM Vol.3. [ bp: Massage commit message. ] Reported-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
-
Shile Zhang authored
[ Upstream commit 8580bed7 ] Building objtool with ARCH=x86_64 fails with: $make ARCH=x86_64 -C tools/objtool ... CC arch/x86/decode.o arch/x86/decode.c:10:22: fatal error: asm/insn.h: No such file or directory #include <asm/insn.h> ^ compilation terminated. mv: cannot stat ‘arch/x86/.decode.o.tmp’: No such file or directory make[2]: *** [arch/x86/decode.o] Error 1 ... The root cause is that the command-line variable 'ARCH' cannot be overridden. It can be replaced by 'SRCARCH', which is defined in 'tools/scripts/Makefile.arch'. Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Reviewed-by:
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/d5d11370ae116df6c653493acd300ec3d7f5e925.1579543924.git.jpoimboe@redhat.com Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 3bed1b7b ] Currently, -E (stop after the preprocessing stage) is used to check whether the given compiler flag is supported. While it is faster than -S (or -c), it can be false-positive. You need to run the compilation proper to check the flag more precisely. For example, -E and -S disagree about the support of "--param asan-instrument-allocas=1". $ gcc -Werror --param asan-instrument-allocas=1 -E -x c /dev/null -o /dev/null $ echo $? 0 $ gcc -Werror --param asan-instrument-allocas=1 -S -x c /dev/null -o /dev/null cc1: error: invalid --param name ‘asan-instrument-allocas’; did you mean ‘asan-instrument-writes’? $ echo $? 1 Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Michael Walle authored
[ Upstream commit b0177aca ] Make use of a core helper to ensure the desired width is respected when calling spi-mem operators. Otherwise only the SPI controller will be matched with the flash chip, which might lead to wrong widths. Also consider the width specified by the user in the device tree. Fixes: 84d04318 ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Signed-off-by:
Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200114154613.8195-1-michael@walle.cc Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Kai Vehmanen authored
[ Upstream commit 2928fa0a ] The initial snd_hda_get_sub_node() can fail on certain devices (e.g. some Chromebook models using Intel GLK). The failure rate is very low, but as this is is part of the probe process, end-user impact is high. In observed cases, related hardware status registers have expected values, but the node query still fails. Retrying the node query does seem to help, so fix the problem by adding retry logic to the query. This does not impact non-Intel platforms. BugLink: https://github.com/thesofproject/linux/issues/1642 Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
-
