um: x86: clean up elf specific definitions

The file arch/x86/um/asm/module.h is equivalent to the definition of
asm-generic. Thus this commit cleans up to use it.

Signed-off-by: Hajime Tazaki <the

um: x86: clean up elf specific definitions

The file arch/x86/um/asm/module.h is equivalent to the definition of
asm-generic. Thus this commit cleans up to use it.

Signed-off-by: Hajime Tazaki <[email protected]>
Link: https://patch.msgid.link/2d70a0ed79ee0a0bef80ad4790063f4833dd9bed.1737348399.git.thehajime@gmail.com
Signed-off-by: Johannes Berg <[email protected]>

show more ...

um: move thread info into task

This selects the THREAD_INFO_IN_TASK option for UM and changes the way
that the current task is discovered. This is trivial though, as UML
already tracks the current t

um: move thread info into task

This selects the THREAD_INFO_IN_TASK option for UM and changes the way
that the current task is discovered. This is trivial though, as UML
already tracks the current task in cpu_tasks[] and this can be used to
retrieve it.

Also remove the signal handler code that copies the thread information
into the IRQ stack. It is obsolete now, which also means that the
mentioned race condition cannot happen anymore.

Signed-off-by: Benjamin Berg <[email protected]>
Reviewed-by: Hajime Tazaki <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Johannes Berg <[email protected]>

show more ...

um: Use generic runtime constant implementation

UML should not be using the architecture native runtime constants, since
that requires also having the appropriate instruction fixups (and all
the lin

um: Use generic runtime constant implementation

UML should not be using the architecture native runtime constants, since
that requires also having the appropriate instruction fixups (and all
the linker script details).

Not that using that code would be impossible, but it's not worth it.
Just point UML at the generic version.

Reported-by: Nathan Chancellor <[email protected]>
Fixes: e3c92e81711d ("runtime constants: add x86 architecture support")
Link: https://lore.kernel.org/all/20240716143644.GA1827132@thelio-3990X/
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

um: don't generate asm/bpf_perf_event.h

If we start validating the existence of the asm-generic side of
generated headers, this one causes a warning:

make[3]: *** No rule to make target 'arch/um/in

um: don't generate asm/bpf_perf_event.h

If we start validating the existence of the asm-generic side of
generated headers, this one causes a warning:

make[3]: *** No rule to make target 'arch/um/include/generated/asm/bpf_perf_event.h', needed by 'all'. Stop.

The problem is that the asm-generic header only exists for the uapi
variant, but arch/um has no uapi headers and instead uses the x86
userspace API.

Add a custom file with an explicit redirect to avoid this.

Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

arch: Rename fbdev header and source files

The per-architecture fbdev code has no dependencies on fbdev and can
be used for any video-related subsystem. Rename the files to 'video'.
Use video-sti.c

arch: Rename fbdev header and source files

The per-architecture fbdev code has no dependencies on fbdev and can
be used for any video-related subsystem. Rename the files to 'video'.
Use video-sti.c on parisc as the source file depends on CONFIG_STI_CORE.

On arc, arm, arm64, sh, and um the asm header file is an empty wrapper
around the file in asm-generic. Let Kbuild generate the file. The build
system does this automatically. Only um needs to generate video.h
explicitly, so that it overrides the host architecture's header. The
latter would otherwise interfere with the build.

Further update all includes statements, include guards, and Makefiles.
Also update a few strings and comments to refer to video instead of
fbdev.

v3:
- arc, arm, arm64, sh: generate asm header via build system (Sam,
Helge, Arnd)
- um: rename fb.h to video.h
- fix typo in commit message (Sam)

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Cc: Vineet Gupta <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: WANG Xuerui <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Thomas Bogendoerfer <[email protected]>
Cc: "James E.J. Bottomley" <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Andreas Larsson <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: [email protected]
Cc: "H. Peter Anvin" <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

um: Use asm-generic/dma-mapping.h

If DMA (PCI over virtio) is enabled, then some drivers may
enable CONFIG_DMA_OPS as well, and then we pull in the x86
definition of get_arch_dma_ops(), which uses t

um: Use asm-generic/dma-mapping.h

If DMA (PCI over virtio) is enabled, then some drivers may
enable CONFIG_DMA_OPS as well, and then we pull in the x86
definition of get_arch_dma_ops(), which uses the dma_ops
symbol, which isn't defined.

Since we don't have real DMA ops nor any kind of IOMMU fix
this in the simplest possible way: pull in the asm-generic
file instead of inheriting the x86 one. It's not clear why
those drivers that do (e.g. VDPA) "select DMA_OPS", and if
they'd even work with this, but chances are nobody will be
wanting to do that anyway, so fixing the build failure is
good enough.

Reported-by: Randy Dunlap <[email protected]>
Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Johannes Berg <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Cc: [email protected]
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

parport_pc: Also enable driver for PCI systems

Nowadays PC-style parallel ports come in the form of PCI and PCIe option
cards and there are some combined parallel/serial option cards as well
that we

parport_pc: Also enable driver for PCI systems

Nowadays PC-style parallel ports come in the form of PCI and PCIe option
cards and there are some combined parallel/serial option cards as well
that we handle in the parport subsystem. There is nothing in particular
that would prevent them from being used in any system equipped with PCI
or PCIe connectivity, except that we do not permit the PARPORT_PC config
option to be selected for platforms for which ARCH_MIGHT_HAVE_PC_PARPORT
has not been set for.

The only PCI platforms that actually can't make use of PC-style parallel
port hardware are those newer PCIe systems that have no support for I/O
cycles in the host bridge, required by such parallel ports. Notably,
this includes the s390 arch, which has port I/O accessors that cause
compilation warnings (promoted to errors with `-Werror'), and there are
other cases such as the POWER9 PHB4 device, though this one has variable
port I/O accessors that depend on the particular system. Also it is not
clear whether the serial port side of devices enabled by PARPORT_SERIAL
uses port I/O or MMIO. Finally Super I/O solutions are always either
ISA or platform devices.

Make the PARPORT_PC option selectable also for PCI systems then, except
for the s390 arch, however limit the availability of PARPORT_PC_SUPERIO
to platforms that enable ARCH_MIGHT_HAVE_PC_PARPORT. Update platforms
accordingly for the required <asm/parport.h> header.

Acked-by: Sudip Mukherjee <[email protected]>
Signed-off-by: Maciej W. Rozycki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

uml/x86: use x86 load_unaligned_zeropad()

allows, among other things, to drop !DCACHE_WORD_ACCESS mess in
x86 csum-partial_64.c

Signed-off-by: Al Viro <[email protected]>

um: add a UML specific futex implementation

The generic asm futex implementation emulates atomic access to
memory by doing a get_user followed by put_user. These translate
to two mapping operations

um: add a UML specific futex implementation

The generic asm futex implementation emulates atomic access to
memory by doing a get_user followed by put_user. These translate
to two mapping operations on UML with paging enabled in the
meantime. This, in turn may end up changing interrupts,
invoking the signal loop, etc.

This replaces the generic implementation by a mapping followed
by an operation on the mapped segment.

Signed-off-by: Anton Ivanov <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

um: add PCI over virtio emulation driver

To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devi

um: add PCI over virtio emulation driver

To support testing of PCI/PCIe drivers in UML, add a PCI bus
support driver. This driver uses virtio, which in UML is really
just vhost-user, to talk to devices, and adds the devices to
the virtual PCI bus in the system.

Since virtio already allows DMA/bus mastering this really isn't
all that hard, of course we need the logic_iomem infrastructure
that was added by a previous patch.

The protocol to talk to the device is has a few fairly simple
messages for reading to/writing from config and IO spaces, and
messages for the device to send the various interrupts (INT#,
MSI/MSI-X and while suspended PME#).

Note that currently no offical virtio device ID is assigned for
this protocol, as a consequence this patch requires defining it
in the Kconfig, with a default that makes the driver refuse to
work at all.

Finally, in order to add support for MSI/MSI-X interrupts, some
small changes are needed in the UML IRQ code, it needs to have
more interrupts, changing NR_IRQS from 64 to 128 if this driver
is enabled, but not actually use them for anything so that the
generic IRQ domain/MSI infrastructure can allocate IRQ numbers.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

um: allow disabling NO_IOMEM

Adjust the kconfig a little to allow disabling NO_IOMEM in UML. To
make an "allyesconfig" with CONFIG_NO_IOMEM=n build, adjust a few
Kconfig things elsewhere and add dum

um: allow disabling NO_IOMEM

Adjust the kconfig a little to allow disabling NO_IOMEM in UML. To
make an "allyesconfig" with CONFIG_NO_IOMEM=n build, adjust a few
Kconfig things elsewhere and add dummy asm/fb.h and asm/vga.h files.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

um: Enforce the usage of asm-generic/softirq_stack.h

The recent rework of the X86 irq stack switching mechanism broke UM as UM
pulls in the X86 specific variant of softirq_stack.h.

Enforce the usag

um: Enforce the usage of asm-generic/softirq_stack.h

The recent rework of the X86 irq stack switching mechanism broke UM as UM
pulls in the X86 specific variant of softirq_stack.h.

Enforce the usage of the asm-generic variant.

Fixes: 72f40a2823d6 ("x86/softirq/64: Inline do_softirq_own_stack()")
Reported-by: Guenter Roeck <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Richard Weinberger <[email protected]>

show more ...

um: remove process stub VMA

This mostly reverts the old commit 3963333fe676 ("uml: cover stubs
with a VMA") which had added a VMA to the existing PTEs. However,
there's no real reason to have the PT

um: remove process stub VMA

This mostly reverts the old commit 3963333fe676 ("uml: cover stubs
with a VMA") which had added a VMA to the existing PTEs. However,
there's no real reason to have the PTEs in the first place and the
VMA cannot be 'fixed' in place, which leads to bugs that userspace
could try to unmap them and be forcefully killed, or such. Also,
there's a bit of an ugly hole in userspace's address space.

Simplify all this: just install the stub code/page at the top of
the (inner) address space, i.e. put it just above TASK_SIZE. The
pages are simply hard-coded to be mapped in the userspace process
we use to implement an mm context, and they're out of reach of the
inner mmap/munmap/mprotect etc. since they're above TASK_SIZE.

Getting rid of the VMA also makes vma_merge() no longer hit one of
the VM_WARN_ON()s there because we installed a VMA while the code
assumes the stack VMA is the first one.

It also removes a lockdep warning about mmap_sem usage since we no
longer have uml_setup_stubs() and thus no longer need to do any
manipulation that would require mmap_sem in activate_mm().

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

mm: Remove arch_remap() and mm-arch-hooks.h

powerpc was the last provider of arch_remap() and the last
user of mm-arch-hooks.h.

Since commit 526a9c4a7234 ("powerpc/vdso: Provide vdso_remap()"),
arc

mm: Remove arch_remap() and mm-arch-hooks.h

powerpc was the last provider of arch_remap() and the last
user of mm-arch-hooks.h.

Since commit 526a9c4a7234 ("powerpc/vdso: Provide vdso_remap()"),
arch_remap() hence mm-arch-hooks.h are not used anymore.

Remove them.

Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

kbuild: preprocess module linker script

There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)

The difference between vmlin

kbuild: preprocess module linker script

There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)

The difference between vmlinux.lds and module.lds is that the latter
is needed for external module builds, thus must be cleaned up by
'make mrproper' instead of 'make clean'. Also, it must be created
by 'make modules_prepare'.

You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
scripts/module.lds.S.

scripts/module.lds is fine because 'make clean' keeps all the
build artifacts under scripts/.

You can add arch-specific sections in <asm/module.lds.h>.

Signed-off-by: Masahiro Yamada <[email protected]>
Tested-by: Jessica Yu <[email protected]>
Acked-by: Will Deacon <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Acked-by: Jessica Yu <[email protected]>

show more ...

um: Implement ndelay/udelay in time-travel mode

In external or inf-cpu time-travel mode, ndelay/udelay currently
just waste CPU time since the simulation time doesn't advance.
Implement them properl

um: Implement ndelay/udelay in time-travel mode

In external or inf-cpu time-travel mode, ndelay/udelay currently
just waste CPU time since the simulation time doesn't advance.
Implement them properly in this case.

Note that the "if (time_travel_mode == ...)" parts compile out
if CONFIG_UML_TIME_TRAVEL_SUPPORT isn't set, time_travel_mode is
defined to TT_MODE_OFF in that case.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

um: Fix time-travel=inf-cpu with xor/raid6

Today, I erroneously built a time-travel configuration with btrfs
enabled, and noticed it cannot boot in time-travel=inf-cpu mode,
both xor and raid6 speed

um: Fix time-travel=inf-cpu with xor/raid6

Today, I erroneously built a time-travel configuration with btrfs
enabled, and noticed it cannot boot in time-travel=inf-cpu mode,
both xor and raid6 speed measurement gets stuck.

For xor, work around it by picking the first algorithm if inf-cpu
mode is enabled.

For raid6, I didn't find such a workaround, so disallow enabling
time-travel mode if RAID6_PQ_BENCHMARK is enabled.

With this, and RAID6_PQ_BENCHMARK disabled, I can boot a kernel
that has btrfs enabled in time-travel=inf-cpu mode.

Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Anton Ivanov <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

um: Don't use generic barrier.h

UML has its own platform-specific barrier.h under arch/x86/um/,
which should get used. Fix the build system to use it, and then
fix the barrier.h to actually compile.

um: Don't use generic barrier.h

UML has its own platform-specific barrier.h under arch/x86/um/,
which should get used. Fix the build system to use it, and then
fix the barrier.h to actually compile.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

treewide: Add SPDX license identifier - Kbuild

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license,

treewide: Add SPDX license identifier - Kbuild

Add SPDX license identifiers to all Make/Kconfig files which:

- Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0

Reported-by: Masahiro Yamada <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

arch: Use asm-generic header for asm/mmiowb.h

Hook up asm-generic/mmiowb.h to Kbuild for all architectures so that we
can subsequently include asm/mmiowb.h from core code.

Cc: Masahiro Yamada <yama

arch: Use asm-generic header for asm/mmiowb.h

Hook up asm-generic/mmiowb.h to Kbuild for all architectures so that we
can subsequently include asm/mmiowb.h from core code.

Cc: Masahiro Yamada <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

show more ...

um: remove redundant generic-y

This commit removes redundant generic-y defines in
arch/um/include/asm/Kbuild.

It is redundant to define generic-y when arch-specific implementation
exists in arch/$(

um: remove redundant generic-y

This commit removes redundant generic-y defines in
arch/um/include/asm/Kbuild.

It is redundant to define generic-y when arch-specific implementation
exists in arch/$(ARCH)/include/asm/*.h

Remove the following generic-y:

hardirq.h
io.h

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Richard Weinberger <[email protected]>

show more ...

time: Add an asm-generic/compat.h file

We have a couple of files that try to include asm/compat.h on
architectures where this is available. Those should generally use the
higher-level linux/compat.h

time: Add an asm-generic/compat.h file

We have a couple of files that try to include asm/compat.h on
architectures where this is available. Those should generally use the
higher-level linux/compat.h file, but that in turn fails to include
asm/compat.h when CONFIG_COMPAT is disabled, unless we can provide
that header on all architectures.

This adds the asm/compat.h for all remaining architectures to
simplify the dependencies.

Architectures that are getting removed in linux-4.17 are not changed
here, to avoid needless conflicts with the removal patches. Those
architectures are broken by this patch, but we have already shown
that they have no users.

Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

arch: Remove clkdev.h asm-generic from Kbuild

Now that every architecture is using the generic clkdev.h file
and we no longer include asm/clkdev.h anywhere in the tree, we
can remove it.

Cc: Russel

arch: Remove clkdev.h asm-generic from Kbuild

Now that every architecture is using the generic clkdev.h file
and we no longer include asm/clkdev.h anywhere in the tree, we
can remove it.

Cc: Russell King <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Cc: <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]> [m68k]
Signed-off-by: Stephen Boyd <[email protected]>

show more ...

bpf: fix build issues on um due to mising bpf_perf_event.h

[ Note, this is a Git cherry-pick of the following commit:

a23f06f06dbe ("bpf: fix build issues on um due to mising bpf_perf_event.h")

bpf: fix build issues on um due to mising bpf_perf_event.h

[ Note, this is a Git cherry-pick of the following commit:

a23f06f06dbe ("bpf: fix build issues on um due to mising bpf_perf_event.h")

... for easier x86 PTI code testing and back-porting. ]

Since c895f6f703ad ("bpf: correct broken uapi for
BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build
on i386 or x86_64:

[...]
CC init/main.o
In file included from ../include/linux/perf_event.h:18:0,
from ../include/linux/trace_events.h:10,
from ../include/trace/syscall.h:7,
from ../include/linux/syscalls.h:82,
from ../init/main.c:20:
../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
asm/bpf_perf_event.h: No such file or directory #include
<asm/bpf_perf_event.h>
[...]

Lets add missing bpf_perf_event.h also to um arch. This seems
to be the only one still missing.

Fixes: c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type")
Reported-by: Randy Dunlap <[email protected]>
Suggested-by: Richard Weinberger <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Cc: Hendrik Brueckner <[email protected]>
Cc: Richard Weinberger <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

bpf: fix build issues on um due to mising bpf_perf_event.h

Since c895f6f703ad ("bpf: correct broken uapi for
BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build
on i386 or x86_64:

[...]

bpf: fix build issues on um due to mising bpf_perf_event.h

Since c895f6f703ad ("bpf: correct broken uapi for
BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build
on i386 or x86_64:

[...]
CC init/main.o
In file included from ../include/linux/perf_event.h:18:0,
from ../include/linux/trace_events.h:10,
from ../include/trace/syscall.h:7,
from ../include/linux/syscalls.h:82,
from ../init/main.c:20:
../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
asm/bpf_perf_event.h: No such file or directory #include
<asm/bpf_perf_event.h>
[...]

Lets add missing bpf_perf_event.h also to um arch. This seems
to be the only one still missing.

Fixes: c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type")
Reported-by: Randy Dunlap <[email protected]>
Suggested-by: Richard Weinberger <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Cc: Hendrik Brueckner <[email protected]>
Cc: Richard Weinberger <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>

show more ...