summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/syscall-counts-by-pid.py
diff options
context:
space:
mode:
authorMichael Kelley <mhklinux@outlook.com>2025-02-10 02:52:52 +0300
committerWei Liu <wei.liu@kernel.org>2025-02-21 22:45:02 +0300
commit7241c886a71797cc51efc6fadec7076fcf6435c2 (patch)
tree48395336e30adce7faee8c8e36d2245d2664d829 /tools/perf/scripts/python/syscall-counts-by-pid.py
parent59115e2e25f42924181055ed7cc1d123af7598b7 (diff)
downloadlinux-7241c886a71797cc51efc6fadec7076fcf6435c2.tar.xz
fbdev: hyperv_fb: iounmap() the correct memory when removing a device
When a Hyper-V framebuffer device is removed, or the driver is unbound from a device, any allocated and/or mapped memory must be released. In particular, MMIO address space that was mapped to the framebuffer must be unmapped. Current code unmaps the wrong address, resulting in an error like: [ 4093.980597] iounmap: bad address 00000000c936c05c followed by a stack dump. Commit d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") changed the kind of address stored in info->screen_base, and the iounmap() call in hvfb_putmem() was not updated accordingly. Fix this by updating hvfb_putmem() to unmap the correct address. Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") Signed-off-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com> Link: https://lore.kernel.org/r/20250209235252.2987-1-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250209235252.2987-1-mhklinux@outlook.com>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts-by-pid.py')
0 files changed, 0 insertions, 0 deletions