Skip to content

L
linux
Switch branch/tag
  1. 27 Jun, 2024 1 commit
    • Arnd Bergmann's avatar
      kallsyms: rework symbol lookup return codes · 7e1f4eb9
      Arnd Bergmann authored 
      Building with W=1 in some configurations produces a false positive
warning for kallsyms:

kernel/kallsyms.c: In function '__sprint_symbol.isra':
kernel/kallsyms.c:503:17: error: 'strcpy' source argument is the same as destination [-Werror=restrict]
  503 |                 strcpy(buffer, name);
      |                 ^~~~~~~~~~~~~~~~~~~~

This originally showed up while building with -O3, but later started
happening in other configurations as well, depending on inlining
decisions. The underlying issue is that the local 'name' variable is
always initialized to the be the same as 'buffer' in the called functions
that fill the buffer, which gcc notices while inlining, though it could
see that the address check always skips the copy.

The calling conventions here are rather unusual, as all of the internal
lookup functions (bpf_address_lookup, ftrace_mod_address_lookup,
ftrace_func_address_lookup, module_address_lookup and
kallsyms_lookup_buildid) already use the provided buffer and either return
the address of that buffer to indicate success, or NULL for failure,
but the callers are written to also expect an arbitrary other buffer
to be returned.

Rework the calling conventions to return the length of the filled buffer
instead of its address, which is simpler and easier to follow as well
as avoiding the warning. Leave only the kallsyms_lookup() calling conventions
unchanged, since that is called from 16 different functions and
adapting this would be a much bigger change.

Link: https://lore.kernel.org/lkml/20200107214042.855757-1-arnd@arndb.de/
Link: https://lore.kernel.org/lkml/20240326130647.7bfb1d92@gandalf.local.home/Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: default avatarLuis Chamberlain <mcgrof@kernel.org>
Acked-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      7e1f4eb9
  3. 25 Jun, 2024 12 commits
    • Arnd Bergmann's avatar
      linux/syscalls.h: add missing __user annotations · 0fa8ab5f
      Arnd Bergmann authored 
      A couple of declarations in linux/syscalls.h are missing __user
annotations on their pointers, which can lead to warnings from
sparse because these don't match the implementation that have
the correct address space annotations.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      0fa8ab5f
    • Arnd Bergmann's avatar
      syscalls: mmap(): use unsigned offset type consistently · 295f1006
      Arnd Bergmann authored 
      Most architectures that implement the old-style mmap() with byte offset
use 'unsigned long' as the type for that offset, but microblaze and
riscv have the off_t type that is shared with userspace, matching the
prototype in include/asm-generic/syscalls.h.

Make this consistent by using an unsigned argument everywhere. This
changes the behavior slightly, as the argument is shifted to a page
number, and an user input with the top bit set would result in a
negative page offset rather than a large one as we use elsewhere.

For riscv, the 32-bit sys_mmap2() definition actually used a custom
type that is different from the global declaration, but this was
missed due to an incorrect type check.
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      295f1006
    • Arnd Bergmann's avatar
      s390: remove native mmap2() syscall · 5daf62da
      Arnd Bergmann authored 
      The mmap2() syscall has never been used on 64-bit s390x and should
have been removed as part of 5a79859a ("s390: remove 31 bit
support").

Remove it now.
Acked-by: default avatarHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      5daf62da
    • Arnd Bergmann's avatar
      hexagon: fix fadvise64_64 calling conventions · 89684228
      Arnd Bergmann authored 
      fadvise64_64() has two 64-bit arguments at the wrong alignment
for hexagon, which turns them into a 7-argument syscall that is
not supported by Linux.

The downstream musl port for hexagon actually asks for a 6-argument
version the same way we do it on arm, csky, powerpc, so make the
kernel do it the same way to avoid having to change both.

Link: https://github.com/quic/musl/blob/hexagon/arch/hexagon/syscall_arch.h#L78
Cc: stable@vger.kernel.org
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      89684228
    • Arnd Bergmann's avatar
      csky, hexagon: fix broken sys_sync_file_range · 3339b99e
      Arnd Bergmann authored 
      Both of these architectures require u64 function arguments to be
passed in even/odd pairs of registers or stack slots, which in case of
sync_file_range would result in a seven-argument system call that is
not currently possible. The system call is therefore incompatible with
all existing binaries.

While it would be possible to implement support for seven arguments
like on mips, it seems better to use a six-argument version, either
with the normal argument order but misaligned as on most architectures
or with the reordered sync_file_range2() calling conventions as on
arm and powerpc.

Cc: stable@vger.kernel.org
Acked-by: default avatarGuo Ren <guoren@kernel.org>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      3339b99e
    • Arnd Bergmann's avatar
      sh: rework sync_file_range ABI · 30766f11
      Arnd Bergmann authored 
      The unusual function calling conventions on SuperH ended up causing
sync_file_range to have the wrong argument order, with the 'flags'
argument getting sorted before 'nbytes' by the compiler.

In userspace, I found that musl, glibc, uclibc and strace all expect the
normal calling conventions with 'nbytes' last, so changing the kernel
to match them should make all of those work.

In order to be able to also fix libc implementations to work with existing
kernels, they need to be able to tell which ABI is used. An easy way
to do this is to add yet another system call using the sync_file_range2
ABI that works the same on all architectures.

Old user binaries can now work on new kernels, and new binaries can
try the new sync_file_range2() to work with new kernels or fall back
to the old sync_file_range() version if that doesn't exist.

Cc: stable@vger.kernel.org
Fixes: 75c92acd ("sh: Wire up new syscalls.")
Acked-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      30766f11
    • Arnd Bergmann's avatar
      powerpc: restore some missing spu syscalls · b1e31c13
      Arnd Bergmann authored 
      A couple of system calls were inadventently removed from the table during
a bugfix for 32-bit powerpc entry. Restore the original behavior.

Fixes: e2375062 ("powerpc/32: fix syscall wrappers with 64-bit arguments of unaligned register-pairs")
Acked-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      b1e31c13
    • Arnd Bergmann's avatar
      parisc: use generic sys_fanotify_mark implementation · 403f17a3
      Arnd Bergmann authored 
      The sys_fanotify_mark() syscall on parisc uses the reverse word order
for the two halves of the 64-bit argument compared to all syscalls on
all 32-bit architectures. As far as I can tell, the problem is that
the function arguments on parisc are sorted backwards (26, 25, 24, 23,
...) compared to everyone else, so the calling conventions of using an
even/odd register pair in native word order result in the lower word
coming first in function arguments, matching the expected behavior
on little-endian architectures. The system call conventions however
ended up matching what the other 32-bit architectures do.

A glibc cleanup in 2020 changed the userspace behavior in a way that
handles all architectures consistently, but this inadvertently broke
parisc32 by changing to the same method as everyone else.

The change made it into glibc-2.35 and subsequently into debian 12
(bookworm), which is the latest stable release. This means we
need to choose between reverting the glibc change or changing the
kernel to match it again, but either hange will leave some systems
broken.

Pick the option that is more likely to help current and future
users and change the kernel to match current glibc. This also
means the behavior is now consistent across architectures, but
it breaks running new kernels with old glibc builds before 2.35.

Link: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d150181d73d9
Link: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/arch/parisc/kernel/sys_parisc.c?h=57b1dfbd5b4a39d
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Tested-by: default avatarHelge Deller <deller@gmx.de>
Acked-by: default avatarHelge Deller <deller@gmx.de>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
---
I found this through code inspection, please double-check to make
sure I got the bug and the fix right.

The alternative is to fix this by reverting glibc back to the
unusual behavior.
      403f17a3
    • Arnd Bergmann's avatar
      parisc: use correct compat recv/recvfrom syscalls · 20a50787
      Arnd Bergmann authored 
      Johannes missed parisc back when he introduced the compat version
of these syscalls, so receiving cmsg messages that require a compat
conversion is still broken.

Use the correct calls like the other architectures do.

Fixes: 1dacc76d ("net/compat/wext: send different messages to compat tasks")
Acked-by: default avatarHelge Deller <deller@gmx.de>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      20a50787
    • Arnd Bergmann's avatar
      sparc: fix compat recv/recvfrom syscalls · d6fbd26f
      Arnd Bergmann authored 
      sparc has the wrong compat version of recv() and recvfrom() for both the
direct syscalls and socketcall().

The direct syscalls just need to use the compat version. For socketcall,
the same thing could be done, but it seems better to completely remove
the custom assembler code for it and just use the same implementation that
everyone else has.

Fixes: 1dacc76d ("net/compat/wext: send different messages to compat tasks")
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d6fbd26f
    • Arnd Bergmann's avatar
      sparc: fix old compat_sys_select() · bae6428a
      Arnd Bergmann authored 
      sparc has two identical select syscalls at numbers 93 and 230, respectively.
During the conversion to the modern syscall.tbl format, the older one of the
two broke in compat mode, and now refers to the native 64-bit syscall.

Restore the correct behavior. This has very little effect, as glibc has
been using the newer number anyway.

Fixes: 6ff645dd ("sparc: add system call table generation support")
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      bae6428a
    • Arnd Bergmann's avatar
      syscalls: fix compat_sys_io_pgetevents_time64 usage · d3882564
      Arnd Bergmann authored 
      Using sys_io_pgetevents() as the entry point for compat mode tasks
works almost correctly, but misses the sign extension for the min_nr
and nr arguments.

This was addressed on parisc by switching to
compat_sys_io_pgetevents_time64() in commit 6431e92f ("parisc:
io_pgetevents_time64() needs compat syscall in 32-bit compat mode"),
as well as by using more sophisticated system call wrappers on x86 and
s390. However, arm64, mips, powerpc, sparc and riscv still have the
same bug.

Change all of them over to use compat_sys_io_pgetevents_time64()
like parisc already does. This was clearly the intention when the
function was originally added, but it got hooked up incorrectly in
the tables.

Cc: stable@vger.kernel.org
Fixes: 48166e6e ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d3882564
  5. 24 Jun, 2024 1 commit
    • Arnd Bergmann's avatar
      ftruncate: pass a signed offset · 4b8e88e5
      Arnd Bergmann authored 
      The old ftruncate() syscall, using the 32-bit off_t misses a sign
extension when called in compat mode on 64-bit architectures.  As a
result, passing a negative length accidentally succeeds in truncating
to file size between 2GiB and 4GiB.

Changing the type of the compat syscall to the signed compat_off_t
changes the behavior so it instead returns -EINVAL.

The native entry point, the truncate() syscall and the corresponding
loff_t based variants are all correct already and do not suffer
from this mistake.

Fixes: 3f6d078d ("fix compat truncate/ftruncate")
Reviewed-by: default avatarChristian Brauner <brauner@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      4b8e88e5
  7. 23 Jun, 2024 8 commits
  9. 22 Jun, 2024 18 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7