kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-10 20:48:12 +00:00
Code Issues Releases Packages Activity
No description
1,315,481 commits 117 branches 5,827 tags 6.3 GiB
  • C 96.8%
  • Assembly 0.9%
  • Rust 0.7%
  • Shell 0.6%
  • Python 0.5%
  • Other 0.3%
Find a file
Michael Kelley cfffe46a99 fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs 
[ Upstream commit 3043863730 ]

Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer
device. When the kdump kernel runs in such a VM, loading the efifb
driver may hang because of accessing the framebuffer at the wrong
memory address.

The scenario occurs when the hyperv_fb driver in the original kernel
moves the framebuffer to a different MMIO address because of conflicts
with an already-running efifb or simplefb driver. The hyperv_fb driver
then informs Hyper-V of the change, which is allowed by the Hyper-V FB
VMBus device protocol. However, when the kexec command loads the kdump
kernel into crash memory via the kexec_file_load() system call, the
system call doesn't know the framebuffer has moved, and it sets up the
kdump screen_info using the original framebuffer address. The transition
to the kdump kernel does not go through the Hyper-V host, so Hyper-V
does not reset the framebuffer address like it would do on a reboot.
When efifb tries to run, it accesses a non-existent framebuffer
address, which traps to the Hyper-V host. After many such accesses,
the Hyper-V host thinks the guest is being malicious, and throttles
the guest to the point that it runs very slowly or appears to have hung.

When the kdump kernel is loaded into crash memory via the kexec_load()
system call, the problem does not occur. In this case, the kexec command
builds the screen_info table itself in user space from data returned
by the FBIOGET_FSCREENINFO ioctl against /dev/fb0, which gives it the
new framebuffer location.

This problem was originally reported in 2020 [1], resulting in commit
3cb73bc3fa ("hyperv_fb: Update screen_info after removing old
framebuffer"). This commit solved the problem by setting orig_video_isVGA
to 0, so the kdump kernel was unaware of the EFI framebuffer. The efifb
driver did not try to load, and no hang occurred. But in 2024, commit
c25a19afb8 ("fbdev/hyperv_fb: Do not clear global screen_info")
effectively reverted 3cb73bc3fa. Commit c25a19afb8 has no reference
to 3cb73bc3fa, so perhaps it was done without knowing the implications
that were reported with 3cb73bc3fa. In any case, as of commit
c25a19afb8, the original problem came back again.

Interestingly, the hyperv_drm driver does not have this problem because
it never moves the framebuffer. The difference is that the hyperv_drm
driver removes any conflicting framebuffers *before* allocating an MMIO
address, while the hyperv_fb drivers removes conflicting framebuffers
*after* allocating an MMIO address. With the "after" ordering, hyperv_fb
may encounter a conflict and move the framebuffer to a different MMIO
address. But the conflict is essentially bogus because it is removed
a few lines of code later.

Rather than fix the problem with the approach from 2020 in commit
3cb73bc3fa, instead slightly reorder the steps in hyperv_fb so
conflicting framebuffers are removed before allocating an MMIO address.
Then the default framebuffer MMIO address should always be available, and
there's never any confusion about which framebuffer address the kdump
kernel should use -- it's always the original address provided by
the Hyper-V host. This approach is already used by the hyperv_drm
driver, and is consistent with the usage guidelines at the head of
the module with the function aperture_remove_conflicting_devices().

This approach also solves a related minor problem when kexec_load()
is used to load the kdump kernel. With current code, unbinding and
rebinding the hyperv_fb driver could result in the framebuffer moving
back to the default framebuffer address, because on the rebind there
are no conflicts. If such a move is done after the kdump kernel is
loaded with the new framebuffer address, at kdump time it could again
have the wrong address.

This problem and fix are described in terms of the kdump kernel, but
it can also occur with any kernel started via kexec.

See extensive discussion of the problem and solution at [2].

[1] https://lore.kernel.org/linux-hyperv/20201014092429.1415040-1-kasong@redhat.com/
[2] https://lore.kernel.org/linux-hyperv/BLAPR10MB521793485093FDB448F7B2E5FDE92@BLAPR10MB5217.namprd10.prod.outlook.com/

Reported-by: Thomas Tai <thomas.tai@oracle.com>
Fixes: c25a19afb8 ("fbdev/hyperv_fb: Do not clear global screen_info")
Signed-off-by: Michael Kelley <mhklinux@outlook.com>
Link: https://lore.kernel.org/r/20250218230130.3207-1-mhklinux@outlook.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Message-ID: <20250218230130.3207-1-mhklinux@outlook.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
History 2025-03-22 12:54:11 -07:00
arch x86/mm: Don't disable PCID when INVLPG has been fixed by microcode 2025-03-13 13:02:20 +01:00
block block: fix conversion of GPT partition name to 7-bit 2025-03-13 13:01:58 +01:00
certs sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3 2024-09-20 19:52:48 +03:00
crypto crypto: api - Fix boot-up self-test race 2025-02-08 09:57:28 +01:00
Documentation docs: rust: remove spurious item in expect list 2025-03-13 13:02:18 +01:00
drivers fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs 2025-03-22 12:54:11 -07:00
fs fs/netfs/read_collect: fix crash due to uninitialized prev variable 2025-03-13 13:02:18 +01:00
include Revert "Bluetooth: hci_core: Fix sleeping function called from invalid context" 2025-03-22 12:54:11 -07:00
init Compiler Attributes: disable __counted_by for clang < 19.1.3 2024-12-05 14:02:45 +01:00
io_uring io_uring/net: save msg_control for compat 2025-03-07 18:25:35 +01:00
ipc ipc: fix memleak if msg_init_ns failed in create_ipc_ns 2024-12-05 14:03:02 +01:00
kernel mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq 2025-03-22 12:54:09 -07:00
lib rcuref: Plug slowpath race in rcuref_put() 2025-03-07 18:25:43 +01:00
LICENSES LICENSES: add 0BSD license text 2024-09-01 20:43:24 -07:00
mm userfaultfd: fix PTE unmapping stack-allocated PTE copies 2025-03-22 12:54:09 -07:00
net netpoll: hold rcu read lock in __netpoll_send_skb() 2025-03-22 12:54:11 -07:00
rust rust: map long to isize and char to u8 2025-03-13 13:02:13 +01:00
samples rust: treewide: switch to the kernel Vec type 2025-03-13 13:01:46 +01:00
scripts kbuild: rust: remove the alloc crate and GlobalAlloc 2025-03-13 13:01:47 +01:00
security ima: Reset IMA_NONACTION_RULE_FLAGS after post_setattr 2025-03-07 18:25:44 +01:00
sound ALSA: hda: realtek: fix incorrect IS_REACHABLE() usage 2025-03-13 13:02:18 +01:00
tools selftests/bpf: Clean up open-coded gettid syscall invocations 2025-03-13 13:02:19 +01:00
usr kbuild: hdrcheck: fix cross build with clang 2025-03-13 13:02:18 +01:00
virt KVM: x86: switch hugepage recovery thread to vhost_task 2024-12-05 14:02:43 +01:00
.clang-format clang-format: Update with v6.11-rc1's for_each macro list 2024-08-02 13:20:31 +02:00
.clippy.toml rust: enable Clippy's check-private-items 2025-03-13 13:01:42 +01:00
.cocciconfig scripts: add Linux .cocciconfig for coccinelle 2016-07-22 12:13:39 +02:00
.editorconfig .editorconfig: remove trim_trailing_whitespace option 2024-06-13 16:47:52 +02:00
.get_maintainer.ignore Add Jeff Kirsher to .get_maintainer.ignore 2024-03-08 11:36:54 +00:00
.gitattributes .gitattributes: set diff driver for Rust source code files 2023-05-31 17:48:25 +02:00
.gitignore rust: introduce .clippy.toml 2025-03-13 13:01:42 +01:00
.mailmap mailmap: add entry for Thorsten Blum 2024-11-07 14:14:59 -08:00
.rustfmt.toml rust: add .rustfmt.toml 2022-09-28 09:02:20 +02:00
COPYING COPYING: state that all contributions really are covered by this file 2020-02-10 13:32:20 -08:00
CREDITS MAINTAINERS: Remove self from DSA entry 2024-11-03 12:52:38 -08:00
Kbuild Kbuild updates for v6.1 2022-10-10 12:00:45 -07:00
Kconfig kbuild: ensure full rebuild when the compiler is updated 2020-05-12 13:28:33 +09:00
MAINTAINERS MAINTAINERS: add entry for the Rust alloc module 2025-03-13 13:01:47 +01:00
Makefile Linux 6.12.19 2025-03-13 13:02:20 +01:00
README README: Fix spelling 2024-03-18 03:36:32 -06:00

README 

Linux kernel
============

There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.

In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.  The formatted documentation can also be read online at:

    https://www.kernel.org/doc/html/latest/

There are various text files in the Documentation/ subdirectory,
several of them using the reStructuredText markup notation.

Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.