Commit 3d3539018d2c ("mm: create the new vm_fault_t type") in mainline
5.1-rc1 changed the definition of vm_fault_t type to unsigned to catch
vm_operations_struct::fault handlers which still have int as return value.
LinuxDriverFault() in vmmon module is one of those.
As handler return type was changed by commit 1c8f422059ae ("mm: change
return type to vm_fault_t") in 4.17-rc1, make LinuxDriverFault() always
return vm_fault_t and define vm_fault_t as int when building against
a pre-4.17 kernel.
Commit 736706bee329 ("get rid of legacy 'get_ds()' function") in v5.1-rc1
removed get_ds() helper. As this helper always returned KERNEL_DS on x86_64
since the architecture was introduced (and even on i386, it did so since
v2.1.0), simply use KERNEL_DS regardless of kernel version.
Since commit 96d4f267e40f ("Remove 'type' argument from access_ok()
function") in v5.0-rc1, the type argument of access_ok() was dropped.
The same commit also dropped macros VERIFY_READ and VERIFY_WRITE so check
for their existence on pre-5.0 kernels to allow build against kernels with
this change backported.
The do_gettimeofday() helper was removed by commit e4b92b108c6c
("timekeeping: remove obsolete time accessors") in v5.0-rc1. Bring it back
for users in vmmon-only/linux/hostif.c.
This feels like a quick and clumsy band aid to allow build with post-4.20
kernels. On a closer look, the whole gymnastics around uptimeState and
HostIFReadUptimeWork() with jiffies and wall time checking and correcting
each other seems to be a workaround for an absence of high resolution
monotonic time. Considering ktime_get_ts64() is available since 3.17 and
before that, ktime_get_ts() since 2.6.17, perhaps the time has come to
clean all this machinery up. But something like this would be beyond the
scope of this repository.
Since commit ca79b0c211af ("mm: convert totalram_pages and totalhigh_pages
variables to atomic") in v5.0-rc1, totalram_pages() is an accessor function
and the actual variable is an atomic.
Since commit 0126be38d988 ("kbuild: announce removal of SUBDIRS if used")
in v5.0-rc1, using SUBDIRS when building out of tree modules produces
a deprecation warning. As M used to work since pretty much ever, use it
unconditionally.
Commit 11c5ad0ec441 ("eventpoll: switch to ->poll_mask") in v4.18-rc1, made
eventpoll switch from ->poll() to ->poll_mask(), resulting in a null
pointer dereference as vmmon calls the callback directly without checking
its availability.
Rather than calling the callback directly (which would result in null
pointer dereference), use vfs_poll() wrapper. As this wrapper is only
available since 4.18-rc1 cycle as well, provide a copy to use when building
against older kernels.
Note: even if the commit revealing the problem was reverted in 4.18-rc3
(and is unlikely to go back in the same form) so that vmmon no longer
crashes with 4.18 kernel, calling the callback without a check is a bad
practice so let's keep the patch in place.
Build against kernel with retpoline support issues warning
objtool: Task_Switch()+0x425: indirect call found in RETPOLINE build
This is because an indirect call in TaskSwitchToMonitor() is encoded using
inline assembler so that it bypasses retpoline generation. For this
purpose, macro CALL_NOSPEC exists since v4.15-rc8 (and has been backported
into some distribution kernels with the rest of retpoline support). Use the
macro if available and fallback to the original code if not.
Function declared with __attribute__((always_inline)) should also be
declared as inline, otherwise gcc issues a warning "always_inline function
might not be inlinable". It's just cosmetic but getting rid of known
harmless warnings makes it easier to spot actual problems. Use the
__always_inline macro for LinuxDriverSyncReadTSCs() as this is how always
inline functions should be declared in kernel code.
The MSR_K7_HWCR_SMMLOCK macro is defined in mainline since commit
18c71ce9c882 ("x86/CPU/AMD: Add the Secure Encrypted Virtualization CPU
feature") in v4.16-rc1.
Remove .cache.mk inside vmmon-only and vmnet-only when executing
"make clean". This file can cause issues when upgrading gcc as make will
still look for includes inside older gcc includes directory.
File .cache.mk with cache of generated variables is created by build since
kernel v4.15-rc1, commit 3298b690b21c ("kbuild: Add a cache for generated
variables").
As discussed in
https://bugzilla.suse.com/show_bug.cgi?id=1059674
the reason for multiple objtool warnings is the fact that vmmon module
defines its own Panic() function which never returns. While it is marked as
such which is used by the compiler for optimization, there is no way to
find this from object file.
While this seems innocuous, it might result in problems with unwinder
later. The quickest way around is to replace vmmon's own Panic() with
standard kernel panic() until a cleaner solution is found.
The CR3_PCID_MASK is defined in mainline asm/processor-flags.h since
commit 6c690ee1039b ("x86/mm: Split read_cr3() into read_cr3_pa() and
__read_cr3()") in v4.13-rc1.
The MSR_MISC_FEATURES_ENABLES macro is defined in mainline since commit
ab6d9468631a ("x86/msr: Rename MISC_FEATURE_ENABLES to
MISC_FEATURES_ENABLES") in v4.12-rc1.
The MSR_MISC_FEATURES_ENABLES_CPUID_FAULT macro is defined in mainline
since commit e9ea1e7f53b8 ("x86/arch_prctl: Add ARCH_[GET|SET]_CPUID") in
v4.12-rc1.
The PCI_VENDOR_ID_VMWARE macro is defined in mainline pci_ids.h since
commit 94e57fea6202 ("PCI: Move PCI_VENDOR_ID_VMWARE to pci_ids.h")
in v3.18-rc1.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.