- 23 Apr, 2020 24 commits
-
-
Tianyu Lan authored
[ Upstream commit 040026df ] When sysctl_record_panic_msg is not set, the panic will not be reported to Hyper-V via hyperv_report_panic_msg(). So the crash should be reported via hyperv_report_panic(). Fixes: 81b18bce ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-6-Tianyu.Lan@microsoft.comSigned-off-by:
Wei Liu <wei.liu@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Tianyu Lan authored
[ Upstream commit 73f26e52 ] When a guest VM panics, Hyper-V should be notified only once via the crash synthetic MSRs. Current Linux code might write these crash MSRs twice during a system panic: 1) hyperv_panic/die_event() calling hyperv_report_panic() 2) hv_kmsg_dump() calling hyperv_report_panic_msg() Fix this by not calling hyperv_report_panic() if a kmsg dump has been successfully registered. The notification will happen later via hyperv_report_panic_msg(). Fixes: 7ed4325a ("Drivers: hv: vmbus: Make panic reporting to be more useful") Reviewed-by:
-
Tianyu Lan authored
[ Upstream commit 7f11a2cc ] If kmsg_dump_register() fails, hv_panic_page will not be used anywhere. So free and reset it. Fixes: 81b18bce ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by:
-
Tianyu Lan authored
[ Upstream commit 74347a99 ] When kdump is not configured, a Hyper-V VM might still respond to network traffic after a kernel panic when kernel parameter panic=0. The panic CPU goes into an infinite loop with interrupts enabled, and the VMbus driver interrupt handler still works because the VMbus connection is unloaded only in the kdump path. The network responses make the other end of the connection think the VM is still functional even though it has panic'ed, which could affect any failover actions that should be taken. Fix this by unloading the VMbus connection during the panic process. vmbus_initiate_unload() could then be called twice (e.g., by hyperv_panic_event() and hv_crash_handler(), so reset the connection state in vmbus_initiate_unload() to ensure the unload is done only once. Fixes: 81b18bce ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by:
-
Magnus Karlsson authored
[ Upstream commit 99e3a236 ] Add a check that the headroom cannot be larger than the available space in the chunk. In the current code, a malicious user can set the headroom to a value larger than the chunk size minus the fixed XDP headroom. That way packets with a length larger than the supported size in the umem could get accepted and result in an out-of-bounds write. Fixes: c0c77d8f ("xsk: add user memory registration support sockopt") Reported-by:
Bui Quang Minh <minhquangbui99@gmail.com> Signed-off-by:
Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=207225 Link: https://lore.kernel.org/bpf/1586849715-23490-1-git-send-email-magnus.karlsson@intel.comSigned-off-by:
-
Ilya Dryomov authored
[ Upstream commit 952c48b0 ] rbd_dev_unprobe() is supposed to undo most of rbd_dev_image_probe(), including rbd_dev_header_info(), which means that rbd_dev_header_info() isn't supposed to be called after rbd_dev_unprobe(). However, rbd_dev_image_release() calls rbd_dev_unprobe() before rbd_unregister_watch(). This is racy because a header update notify can sneak in: "rbd unmap" thread ceph-watch-notify worker rbd_dev_image_release() rbd_dev_unprobe() free and zero out header rbd_watch_cb() rbd_dev_refresh() rbd_dev_header_info() read in header The same goes for "rbd map" because rbd_dev_image_probe() calls rbd_dev_unprobe() on errors. In both cases this results in a memory leak. Fixes: fd22aef8 ("rbd: move rbd_unregister_watch() call into rbd_dev_image_release()") Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Jason Dillaman <dillaman@redhat.com> Signed-off-by:
-
Ilya Dryomov authored
[ Upstream commit 0e4e1de5 ] rbd_unregister_watch() flushes notifies and therefore cannot be called under header_rwsem because a header update notify takes header_rwsem to synchronize with "rbd map". If mapping an image fails after the watch is established and a header update notify sneaks in, we deadlock when erroring out from rbd_dev_image_probe(). Move watch registration and unregistration out of the critical section. The only reason they were put there was to make header_rwsem management slightly more obvious. Fixes: 811c6688 ("rbd: fix rbd map vs notify races") Signed-off-by:
-
Nathan Chancellor authored
commit 864eb1af upstream. Clang warns when multiple pairs of parentheses are used for a single conditional statement. drivers/video/fbdev/sis/init301.c:851:42: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* || ~~~~~~~~~~~~~~~~~~~~~~~~^~~~ drivers/video/fbdev/sis/init301.c:851:42: note: remove extraneous parentheses around the comparison to silence this warning } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* || ~ ^ ~ drivers/video/fbdev/sis/init301.c:851:42: note: use '=' to turn this equality comparison into an assignment } else if((SiS_Pr->SiS_IF_DEF_LVDS == 1) /* || ^~ = 1 warning generated. Remove the parentheses and while we're at it, clean up the commented code, which has been here since the beginning of git history. Link: https://github.com/ClangBuiltLinux/linux/issues/118Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Cc: Thomas Winischhofer <thomas@winischhofer.net> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
ndesaulniers@google.com authored
commit 1ad3935b upstream. Clang warns: vector initializers are not compatible with NEON intrinsics in big endian mode [-Wnonportable-vector-initialization] While this is usually the case, it's not an issue for this case since we're initializing the uint8x16_t (16x uint8_t's) with the same value. Instead, use vdupq_n_u8 which both compilers lower into a single movi instruction: https://godbolt.org/z/vBrgzt This avoids the static storage for a constant value. Link: https://github.com/ClangBuiltLinux/linux/issues/214Suggested-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Tianyu Lan authored
commit a1158956 upstream. We want to notify Hyper-V when a Linux guest VM crash occurs, so there is a record of the crash even when kdump is enabled. But crash_kexec_post_notifiers defaults to "false", so the kdump kernel runs before the notifiers and Hyper-V never gets notified. Fix this by always setting crash_kexec_post_notifiers to be true for Hyper-V VMs. Fixes: 81b18bce ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by:
-
Frank Rowand authored
commit 478ff649 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 4 of 5. target_path was not freed in the non-error path. Fixes: e0a58f3e ("of: overlay: remove a dependency on device node full_name") Reported-by:
Erhard F. <erhard_f@mailbox.org> Signed-off-by:
Frank Rowand <frank.rowand@sony.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Frank Rowand authored
commit 145fc138 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 3 of 5. of_unittest_overlay_high_level() failed to kfree the newly created property when the property named 'name' is skipped. Fixes: 39a751a4 ("of: change overlay apply input data from unflattened to FDT") Reported-by:
-
Frank Rowand authored
commit 216830d2 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 2 of 5. of_unittest_platform_populate() left an elevated reference count for grandchild nodes (which are platform devices). Fix the platform device reference counts so that the memory will be freed. Fixes: fb2caa50 ("of/selftest: add testcase for nodes with same name and address") Reported-by:
-
Frank Rowand authored
commit b3fb36ed upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 1 of 5. of_unittest_changeset() reaches deeply into the dynamic devicetree functions. Several nodes were left with an elevated reference count and thus were not properly cleaned up. Fix the reference counts so that the memory will be freed. Fixes: 201c910b ("of: Transactional DT support.") Reported-by:
-
Takashi Iwai authored
commit 25faa4bd upstream. At the error path of the firmware loading error, the driver tries to release the card object and set NULL to drvdata. This may be referred badly at the possible PM action, as the driver itself is still bound and the PM callbacks read the card object. Instead, we continue the probing as if it were no option set. This is often a better choice than the forced abort, too. Fixes: 5cb543db ("ALSA: hda - Deferred probing with request_firmware_nowait()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-2-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Zenghui Yu authored
commit edfc23f6 upstream. Using irq_domain_free_irqs_common() on the irqdomain free path will leave the MSI descriptor unfreed when platform devices get removed. Properly free it by MSI domain free function. Fixes: 9650c60e ("irqchip/mbigen: Create irq domain for each mbigen device") Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200408114352.1604-1-yuzenghui@huawei.comSigned-off-by:
-
Pablo Neira Ayuso authored
commit d9583cdf upstream. EINVAL should be used for malformed netlink messages. New userspace utility and old kernels might easily result in EINVAL when exercising new set features, which is misleading. Fixes: 8aeff920 ("netfilter: nf_tables: add stateful object reference to set elements") Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Martin Fuzzey authored
commit 4141f1a4 upstream. In order to wake from suspend by ethernet magic packets the GPC must be used as intc does not have wakeup functionality. But the FEC DT node currently uses interrupt-extended, specificying intc, thus breaking WoL. This problem is probably fallout from the stacked domain conversion as intc used to chain to GPC. So replace "interrupts-extended" by "interrupts" to use the default parent which is GPC. Fixes: b923ff6a ("ARM: imx6: convert GPC to stacked domains") Signed-off-by:
Martin Fuzzey <martin.fuzzey@flowbird.group> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Luke Nelson authored
commit bb9562cf upstream. The current arm BPF JIT does not correctly compile RSH or ARSH when the immediate shift amount is 0. This causes the "rsh64 by 0 imm" and "arsh64 by 0 imm" BPF selftests to hang the kernel by reaching an instruction the verifier determines to be unreachable. The root cause is in how immediate right shifts are encoded on arm. For LSR and ASR (logical and arithmetic right shift), a bit-pattern of 00000 in the immediate encodes a shift amount of 32. When the BPF immediate is 0, the generated code shifts by 32 instead of the expected behavior (a no-op). This patch fixes the bugs by adding an additional check if the BPF immediate is 0. After the change, the above mentioned BPF selftests pass. Fixes: 39c13c20 ("arm: eBPF JIT compiler") Co-developed-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Luke Nelson <luke.r.nels@gmail.com> Signed-off-by:
-
Michael Walle authored
commit ea104a9e upstream. The restart handler is missing two things, first, the registers has to be unlocked and second there is no synchronization for the write_relaxed() calls. This was tested on a custom board with the NXP LS1028A SoC. Fixes: 6c5c0d48 ("watchdog: sp805: add restart handler") Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20200327162450.28506-1-michael@walle.ccSigned-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
-
Roman Gushchin authored
commit d87f6392 upstream. Since commit a8ac900b ("ext4: use non-movable memory for the superblock") buffers for ext4 superblock were allocated using the sb_bread_unmovable() helper which allocated buffer heads out of non-movable memory blocks. It was necessarily to not block page migrations and do not cause cma allocation failures. However commit 85c8f176 ("ext4: preload block group descriptors") broke this by introducing pre-reading of the ext4 superblock. The problem is that __breadahead() is using __getblk() underneath, which allocates buffer heads out of movable memory. It resulted in page migration failures I've seen on a machine with an ext4 partition and a preallocated cma area. Fix this by introducing sb_breadahead_unmovable() and __breadahead_gfp() helpers which use non-movable memory for buffer head allocations and use them for the ext4 superblock readahead. Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Fixes: 85c8f176 ("ext4: preload block group descriptors") Signed-off-by:
Roman Gushchin <guro@fb.com> Link: https://lore.kernel.org/r/20200229001411.128010-1-guro@fb.comSigned-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Li Bin authored
commit 849f8583 upstream. If the dxfer_len is greater than 256M then the request is invalid and we need to call sg_remove_request in sg_common_write. Link: https://lore.kernel.org/r/1586777361-17339-1-git-send-email-huawei.libin@huawei.com Fixes: f930c704 ("scsi: sg: only check for dxfer_len greater than 256M") Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Li Bin <huawei.libin@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Josh Poimboeuf authored
commit b401efc1 upstream. If a switch jump table's indirect branch is in a ".cold" subfunction in .text.unlikely, objtool doesn't detect it, and instead prints a false warning: drivers/media/v4l2-core/v4l2-ioctl.o: warning: objtool: v4l_print_format.cold()+0xd6: sibling call from callable instruction with modified stack frame drivers/hwmon/max6650.o: warning: objtool: max6650_probe.cold()+0xa5: sibling call from callable instruction with modified stack frame drivers/media/dvb-frontends/drxk_hard.o: warning: objtool: init_drxk.cold()+0x16f: sibling call from callable instruction with modified stack frame Fix it by comparing the function, instead of the section and offset. Fixes: 13810435 ("objtool: Support GCC 8's cold subfunctions") Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Miroslav Benes <mbenes@suse.cz> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/157c35d42ca9b6354bbb1604fe9ad7d1153ccb21.1585761021.git.jpoimboe@redhat.comSigned-off-by:
-
Luke Nelson authored
commit 4178417c upstream. This patch fixes an incorrect check in how immediate memory offsets are computed for BPF_DW on arm. For BPF_LDX/ST/STX + BPF_DW, the 32-bit arm JIT breaks down an 8-byte access into two separate 4-byte accesses using off+0 and off+4. If off fits in imm12, the JIT emits a ldr/str instruction with the immediate and avoids the use of a temporary register. While the current check off <= 0xfff ensures that the first immediate off+0 doesn't overflow imm12, it's not sufficient for the second immediate off+4, which may cause the second access of BPF_DW to read/write the wrong address. This patch fixes the problem by changing the check to off <= 0xfff - 4 for BPF_DW, ensuring off+4 will never overflow. A side effect of simplifying the check is that it now allows using negative immediate offsets in ldr/str. This means that small negative offsets can also avoid the use of a temporary register. This patch introduces no new failures in test_verifier or test_bpf.c. Fixes: c5eae692 ("ARM: net: bpf: improve 64-bit store implementation") Fixes: ec19e02b ("ARM: net: bpf: fix LDX instructions") Co-developed-by:
-
- 21 Apr, 2020 16 commits
-
-
Greg Kroah-Hartman authored
-
Austin Kim authored
commit 7ea36242 upstream. If !area->pages statement is true where memory allocation fails, area is freed. In this case 'area->pages = pages' should not executed. So move 'area->pages = pages' after if statement. [akpm@linux-foundation.org: give area->pages the same treatment] Link: http://lkml.kernel.org/r/20190830035716.GA190684@LGEARND20B15Signed-off-by:
Austin Kim <austindh.kim@gmail.com> Acked-by:
Michal Hocko <mhocko@suse.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Uladzislau Rezki (Sony) <urezki@gmail.com> Cc: Roman Gushchin <guro@fb.com> Cc: Roman Penyaev <rpenyaev@suse.de> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Karthick Gopalasubramanian authored
commit 32dcfe83 upstream. Reset file is not used and may cause race conditions with operational driver if used. Signed-off-by:
Karthick Gopalasubramanian <kargop@codeaurora.org> Signed-off-by:
Maya Erez <merez@codeaurora.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dedy Lansky authored
commit 61e5ec04 upstream. When enlarging rx_ring_order module param, wil6210 fails to load because there are not enough Rx buffers. Fix this by enlarging number of Rx buffers at startup, if needed based on rx_ring_order. Signed-off-by:
Dedy Lansky <dlansky@codeaurora.org> Signed-off-by:
-
Alexei Avshalom Lazar authored
commit ac0e541a upstream. Initialize unset variable, and verify that mid is valid. Signed-off-by:
Alexei Avshalom Lazar <ailizaro@codeaurora.org> Signed-off-by:
-
Maya Erez authored
commit 979c9d8d upstream. HALP ICR is set as long as the FW should stay awake. To prevent its multiple handling the driver masks this IRQ bit. However, if there is a different MISC ICR before the driver clears this bit, there is a risk of race condition between HALP mask and unmask. This race leads to HALP timeout, in case it is mistakenly masked. Add an atomic flag to indicate if HALP ICR should be handled. Signed-off-by:
-
Dedy Lansky authored
commit d6a553c0 upstream. Make sure rx_buff_mgmt is initialized before accessing it. Signed-off-by:
-
Reinette Chatre authored
commit b0151da5 upstream. The default resource group ("rdtgroup_default") is associated with the root of the resctrl filesystem and should never be removed. New resource groups can be created as subdirectories of the resctrl filesystem and they can be removed from user space. There exists a safeguard in the directory removal code (rdtgroup_rmdir()) that ensures that only subdirectories can be removed by testing that the directory to be removed has to be a child of the root directory. A possible deadlock was recently fixed with 334b0f4e ("x86/resctrl: Fix a deadlock due to inaccurate reference"). This fix involved associating the private data of the "mon_groups" and "mon_data" directories to the resource group to which they belong instead of NULL as before. A consequence of this change was that the original safeguard code preventing removal of "mon_groups" and "mon_data" found in the root directory failed resulting in attempts to remove the default resource group that ends in a BUG: kernel BUG at mm/slub.c:3969! invalid opcode: 0000 [#1] SMP PTI Call Trace: rdtgroup_rmdir+0x16b/0x2c0 kernfs_iop_rmdir+0x5c/0x90 vfs_rmdir+0x7a/0x160 do_rmdir+0x17d/0x1e0 do_syscall_64+0x55/0x1d0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by improving the directory removal safeguard to ensure that subdirectories of the resctrl root directory can only be removed if they are a child of the resctrl filesystem's root _and_ not associated with the default resource group. Fixes: 334b0f4e ("x86/resctrl: Fix a deadlock due to inaccurate reference") Reported-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
James Morse authored
commit 9fe04507 upstream. Resctrl assumes that all CPUs are online when the filesystem is mounted, and that CPUs remember their CDP-enabled state over CPU hotplug. This goes wrong when resctrl's CDP-enabled state changes while all the CPUs in a domain are offline. When a domain comes online, enable (or disable!) CDP to match resctrl's current setting. Fixes: 5ff193fb ("x86/intel_rdt: Add basic resctrl filesystem support") Suggested-by:
James Morse <james.morse@arm.com> Signed-off-by:
-
John Allen authored
commit bdf89df3 upstream. Future AMD CPUs will have microcode patches that exceed the default 4K patch size. Raise our limit. Signed-off-by:
John Allen <john.allen@amd.com> Signed-off-by:
-
Maurizio Lombardi authored
[ Upstream commit 57c46e9f ] A number of hangs have been reported against the target driver; they are due to the fact that multiple threads may try to destroy the iscsi session at the same time. This may be reproduced for example when a "targetcli iscsi/iqn.../tpg1 disable" command is executed while a logout operation is underway. When this happens, two or more threads may end up sleeping and waiting for iscsit_close_connection() to execute "complete(session_wait_comp)". Only one of the threads will wake up and proceed to destroy the session structure, the remaining threads will hang forever. Note that if the blocked threads are somehow forced to wake up with complete_all(), they will try to free the same iscsi session structure destroyed by the first thread, causing double frees, memory corruptions etc... With this patch, the threads that want to destroy the iscsi session will increase the session refcount and will set the "session_close" flag to 1; then they wait for the driver to close the remaining active connections. When the last connection is closed, iscsit_close_connection() will wake up all the threads and will wait for the session's refcount to reach zero; when this happens, iscsit_close_connection() will destroy the session structure because no one is referencing it anymore. INFO: task targetcli:5971 blocked for more than 120 seconds. Tainted: P OE 4.15.0-72-generic #81~16.04.1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. targetcli D 0 5971 1 0x00000080 Call Trace: __schedule+0x3d6/0x8b0 ? vprintk_func+0x44/0xe0 schedule+0x36/0x80 schedule_timeout+0x1db/0x370 ? __dynamic_pr_debug+0x8a/0xb0 wait_for_completion+0xb4/0x140 ? wake_up_q+0x70/0x70 iscsit_free_session+0x13d/0x1a0 [iscsi_target_mod] iscsit_release_sessions_for_tpg+0x16b/0x1e0 [iscsi_target_mod] iscsit_tpg_disable_portal_group+0xca/0x1c0 [iscsi_target_mod] lio_target_tpg_enable_store+0x66/0xe0 [iscsi_target_mod] configfs_write_file+0xb9/0x120 __vfs_write+0x1b/0x40 vfs_write+0xb8/0x1b0 SyS_write+0x5c/0xe0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Link: https://lore.kernel.org/r/20200313170656.9716-3-mlombard@redhat.comReported-by:
Matt Coleman <mcoleman@datto.com> Tested-by:
Rahul Kundu <rahul.kundu@chelsio.com> Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Signed-off-by:
-
Maurizio Lombardi authored
[ Upstream commit e49a7d99 ] iscsit_free_session() is equivalent to iscsit_stop_session() followed by a call to iscsit_close_session(). Link: https://lore.kernel.org/r/20200313170656.9716-2-mlombard@redhat.comTested-by:
-
Jim Mattson authored
commit 396d2e87 upstream. The host reports support for the synthetic feature X86_FEATURE_SSBD when any of the three following hardware features are set: CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] CPUID.80000008H:EBX.AMD_SSBD[bit 24] CPUID.80000008H:EBX.VIRT_SSBD[bit 25] Either of the first two hardware features implies the existence of the IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does not. Therefore, CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] should only be set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host. Fixes: 0c54914d ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code") Signed-off-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Jacob Xu <jacobhxu@google.com> Reviewed-by:
Peter Shier <pshier@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Reported-by:
Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> [bwh: Backported to 4.x: adjust indentation] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Jan Kara authored
commit 801674f3 upstream. We do not want to create initialized extents beyond end of file because for e2fsck it is impossible to distinguish them from a case of corrupted file size / extent tree and so it complains like: Inode 12, i_size is 147456, should be 163840. Fix? no Code in ext4_ext_convert_to_initialized() and ext4_split_convert_extents() try to make sure it does not create initialized extents beyond inode size however they check against inode->i_size which is wrong. They should instead check against EXT4_I(inode)->i_disksize which is the current inode size on disk. That's what e2fsck is going to see in case of crash before all dirty data is written. This bug manifests as generic/456 test failure (with recent enough fstests where fsx got fixed to properly pass FALLOC_KEEP_SIZE_FL flags to the kernel) when run with dioread_lock mount option. CC: stable@vger.kernel.org Fixes: 21ca087a ("ext4: Do not zero out uninitialized extents beyond i_size") Reviewed-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Sergei Lopatin authored
commit 8c7f0a44 upstream. Should prevent flicker if PP_OVERDRIVE_MASK is set. bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646 bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1088 bug: https://gitlab.freedesktop.org/drm/amd/-/issues/628Signed-off-by:
Sergei Lopatin <magist3r@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Thinh Nguyen authored
[ Upstream commit a114c4ca ] We track END_TRANSFER command completion. Don't clear transfer started/ended flag prematurely. Otherwise, we'd run into the problem with restarting transfer before END_TRANSFER command finishes. Fixes: 6d8a0196 ("usb: dwc3: gadget: check for Missed Isoc from event status") Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
