Hello,

Now that we mostly fixed the op_pending race condition, I believe it's time to
continue the new syscall work. This patchset is adapted to the robust_try_unlock
mechanics.

 * Use case

The use-case for the new syscalls is detailed in the last patch version:

  
https://lore.kernel.org/lkml/[email protected]

 * The syscall interface

Documented at patches 3/9 "futex: Create set_robust_list2() syscall" and
4/9 "futex: Create get_robust_list2() syscall".

 * Testing

I expanded the current robust list selftest to use the new interface,
and also ported the original syscall to use the new syscall internals,
and everything survived the tests. Tested on both x86 and arm64.

This patchset depends on 
https://lore.kernel.org/lkml/[email protected]/

 * Changelog

Changes from v6:
 - Interface now uses CREATE/MODIFY semantics instead of SET. This allows to
 both libc and app to use the lists without conflicts.
 - Rebased on top of mainline, including the new VDSO changes
 - v6: 
https://lore.kernel.org/r/[email protected]

Changes from v5:
 - Complete interface rewrite, there are so many changes but the main
   ones are the following points
 - Array of robust lists now has a static size, allocated once during the
   first usage of the list
 - Now that the list of robust lists have a fixed size, I removed the
   logic of having a command for creating a new index on the list. To
   simplify things for everyone, userspace just need to call
   set_robust_list2(head, 32-bit/64-bit type, index).
 - Created get_robust_list2()
 - The new code can be better integrated with the original interface
 - v5: 
https://lore.kernel.org/r/[email protected]

Feedback is very welcomed!

---
André Almeida (10):
      futex: Skip test_futex_robust_unlock() if not supported
      futex: Use explicit sizes for compat_robust_list structs
      futex: Make exit_robust_list32() unconditionally available for 64-bit 
kernels
      futex: Create set_robust_list2() syscall
      futex: Create get_robust_list2() syscall
      futex: Wire up set_robust_list2 syscall
      futex: Wire up get_robust_list2 syscall
      selftests/futex: Expand for set_robust_list2()
      selftests/futex: Expand for get_robust_list2()
      futex: Use new robust list API internally

 arch/alpha/kernel/syscalls/syscall.tbl             |   2 +
 arch/arm/tools/syscall.tbl                         |   2 +
 arch/m68k/kernel/syscalls/syscall.tbl              |   2 +
 arch/microblaze/kernel/syscalls/syscall.tbl        |   2 +
 arch/mips/kernel/syscalls/syscall_n32.tbl          |   2 +
 arch/mips/kernel/syscalls/syscall_n64.tbl          |   2 +
 arch/mips/kernel/syscalls/syscall_o32.tbl          |   2 +
 arch/parisc/kernel/syscalls/syscall.tbl            |   2 +
 arch/powerpc/kernel/syscalls/syscall.tbl           |   2 +
 arch/s390/kernel/syscalls/syscall.tbl              |   2 +
 arch/sh/kernel/syscalls/syscall.tbl                |   2 +
 arch/sparc/kernel/syscalls/syscall.tbl             |   2 +
 arch/x86/entry/syscalls/syscall_32.tbl             |   2 +
 arch/x86/entry/syscalls/syscall_64.tbl             |   2 +
 arch/xtensa/kernel/syscalls/syscall.tbl            |   2 +
 include/linux/compat.h                             |  13 +-
 include/linux/futex.h                              |  24 +
 include/linux/futex_types.h                        |   8 +-
 include/linux/sched.h                              |   2 -
 include/uapi/asm-generic/unistd.h                  |   7 +-
 include/uapi/linux/futex.h                         |  28 +
 kernel/futex/core.c                                | 194 +++++--
 kernel/futex/futex.h                               |   5 +
 kernel/futex/syscalls.c                            | 147 +++++-
 kernel/sys_ni.c                                    |   2 +
 scripts/syscall.tbl                                |   2 +
 .../selftests/futex/functional/robust_list.c       | 567 +++++++++++++++++++--
 27 files changed, 907 insertions(+), 122 deletions(-)
---
base-commit: fe2ec83746e501645709761605c2464a44fd2929
change-id: 20250225-tonyk-robust_futex-60adeedac695

Best regards,
--  
André Almeida <[email protected]>


Reply via email to