History log of /linux-master/arch/x86/um/shared/sysdep/stub_32.h
Revision Date Author Comments
# 83aec96c 09-Nov-2023 Benjamin Berg <benjamin@sipsolutions.net>

um: Mark 32bit syscall helpers as clobbering memory

The 64bit helper are marked to clobber the memory, but the 32bit ones
are not. Add the appropriate clobber to the 32bit helper routines so
that the compiler cannot do invalid optimizations.

Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Richard Weinberger <richard@nod.at>


# 7b84543c 09-Nov-2023 Benjamin Berg <benjamin@sipsolutions.net>

um: Always inline stub functions

The stub executable page is remapped to a different location in the
userland process. As these functions may be used by the stub, they
really need to be always inlined rather than permitting the compiler to
emit a function.

Signed-off-by: Benjamin Berg <benjamin@sipsolutions.net>
Signed-off-by: Richard Weinberger <richard@nod.at>


# 6032aca0 14-Apr-2023 Johannes Berg <johannes.berg@intel.com>

um: make stub data pages size tweakable

There's a lot of code here that hard-codes that the
data is a single page, and right now that seems to
be sufficient, but to make it easier to change this
in the future, add a new STUB_DATA_PAGES constant
and use it throughout the code.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>


# adf9ae0d 13-Jul-2021 Johannes Berg <johannes.berg@intel.com>

um: fix stub location calculation

In commit 9f0b4807a44f ("um: rework userspace stubs to not hard-code
stub location") I changed stub_segv_handler() to do a calculation with
a pointer to a stack variable to find the data page that we're using
for the stack and the rest of the data. This same commit was meant to
do it as well for stub_clone_handler(), but the change inadvertently
went into commit 84b2789d6115 ("um: separate child and parent errors
in clone stub") instead.

This was reported to not be compiled correctly by gcc 5, causing the
code to crash here. I'm not sure why, perhaps it's UB because the var
isn't initialized? In any case, this trick always seemed bad, so just
create a new inline function that does the calculation in assembly.

Reported-by: subashab@codeaurora.org
Fixes: 9f0b4807a44f ("um: rework userspace stubs to not hard-code stub location")
Fixes: 84b2789d6115 ("um: separate child and parent errors in clone stub")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>


# dc01a3b9 23-Feb-2021 Johannes Berg <johannes.berg@intel.com>

um: Fix tag order in stub_32.h

"static void inline" is the wrong way around, fix that.

Reported-by: kernel test robot <lkp@intel.com>
Fixes: 9f0b4807a44f ("um: rework userspace stubs to not hard-code stub location")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>


# 9f0b4807 13-Jan-2021 Johannes Berg <johannes.berg@intel.com>

um: rework userspace stubs to not hard-code stub location

The userspace stacks mostly have a stack (and in the case of the
syscall stub we can just set their stack pointer) that points to
the location of the stub data page already.

Rework the stubs to use the stack pointer to derive the start of
the data page, rather than requiring it to be hard-coded.

In the clone stub, also integrate the int3 into the stack remap,
since we really must not use the stack while we remap it.

This prepares for putting the stub at a variable location that's
not part of the normal address space of the userspace processes
running inside the UML machine.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>


# 84b2789d 13-Jan-2021 Johannes Berg <johannes.berg@intel.com>

um: separate child and parent errors in clone stub

If the two are mixed up, then it looks as though the parent
returned an error if the child failed (before) the mmap(),
and then the resulting process never gets killed. Fix this
by splitting the child and parent errors, reporting and
using them appropriately.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>


# 5c48b108 18-Aug-2011 Al Viro <viro@ftp.linux.org.uk>

um: take arch/um/sys-x86 to arch/x86/um

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>