The sys_foo() naming scheme used by the syscall wrappers may collide
with application symbols. Especially as 'sys_' is an obvious naming
scheme an application may choose for its own custom systemcall wrappers.
Avoid these conflicts by using an leading underscore which moves the
names into the implementation's namespace. This naming scheme was chosen
over a '__nolibc_' prefix, as these functions are not an implementation
detail but a documented interface meant to be used by applications.
While this may break some existing users, adapting them should be
straightforward. Given that nolibc is most-likely vendored, no
unexpected breakage should happen. No in-tree users are affected.
These conflicts happen when compiling some of the kernel selftests
with nolibc.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260319-nolibc-namespacing-v1-1-33c22eaddb5e@weissschuh.net
The naming convention of the my_syscallX() macros is a bit unfortunate.
They may conflict with application code and the name is very generic.
Switch to __nolibc_syscallX(). The leading underscores place the symbols
in the implementation-defined namespace, avoiding conflicting names.
It is also clearer that these are non-standard extensions from nolibc.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260223-nolibc-namespacing-v1-1-52574ffebb2c@weissschuh.net
Currently the generic variants of sys_fork() and sys_vfork() differ in
both they precedence of used system calls and the usage of sys_clone()
vs sys_clone3(). While the interface of clone3() in sys_vfork() is more
consistent over different architectures, qemu-user does not support it,
making testing harder. We already handle the different clone()
interfaces for sys_fork() in the architecture-specific headers, and can
do so also for sys_vfork(). In fact SPARC already has such handling and
only s390 is currently missing.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://patch.msgid.link/20260104-nolibc-vfork-v1-1-a63464b9e4e6@weissschuh.net
As off_t is now always 64-bit wide this overflow can not happen anymore,
remove the check.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Make sure to always use the 64-bit safe system call
in preparation for 64-bit off_t on 32 bit architectures.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Modern programs tend to include sys/select.h to get FD_SET() and
FD_CLR() definitions as well as struct fd_set, but in our case it
didn't exist.
The definitions were moved from types.h to sys/select.h, which is
now included from nolibc.h, and the sys_select() definition moved
there as well from sys.h.
Signed-off-by: Willy Tarreau <w@1wt.eu>
[Thomas: adapt to current -next branch]
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
In principle, it is possible to use nolibc for only some object files in
a program. In that case, the startup code in _start and _start_c is not
going to be used. Add the NOLIBC_NO_RUNTIME compile time option to
disable it entirely and also remove anything that depends on it.
Doing this avoids warnings from modpost for UML as the _start_c code
references the main function from the .init.text section while it is not
inside .init itself.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
To allow testing of vfork() support in the arm64 basic-gcs test provide an
implementation for nolibc, using the vfork() syscall if one is available
and otherwise clone3(). We implement in terms of clone3() since the order
of the arguments for clone() varies between architectures.
As for fork() SPARC returns the parent PID rather than 0 in the child
for vfork() so needs custom handling.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250703-arm64-gcs-vfork-exit-v3-2-1e9a9d2ddbbe@kernel.org
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Thomas Weißschuh
Thomas WeißschuhandThomas Weißschuh
Willy TarreauandThomas Weißschuh
Benjamin BergandThomas Weißschuh
Mark BrownandThomas Weißschuh