Linux API

• Date Index

• [PATCH xfstests v1 2/2] open_by_handle: add tests for u64 mount ID, (continued)
  • [PATCH xfstests v1 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
    • Re: [PATCH xfstests v1 2/2] open_by_handle: add tests for u64 mount ID, Amir Goldstein
      • Re: [PATCH xfstests v1 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
  • Re: [PATCH RESEND v3 0/2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
  • [PATCH xfstests v2 1/2] statx: update headers to include newer statx fields, Aleksa Sarai
    • [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
      • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Amir Goldstein
        • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
          • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Amir Goldstein
            • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
              • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Amir Goldstein
                • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
      • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Amir Goldstein
        • Re: [PATCH xfstests v2 2/2] open_by_handle: add tests for u64 mount ID, Aleksa Sarai
    • Re: [PATCH xfstests v2 1/2] statx: update headers to include newer statx fields, Amir Goldstein
  • [PATCH xfstests v3 1/2] open_by_handle: verify u32 and u64 mount IDs, Aleksa Sarai
    • [PATCH xfstests v3 2/2] generic/756: test name_to_handle_at(AT_HANDLE_MNT_ID_UNIQUE) explicitly, Aleksa Sarai
      • Re: [PATCH xfstests v3 2/2] generic/756: test name_to_handle_at(AT_HANDLE_MNT_ID_UNIQUE) explicitly, Amir Goldstein
        • Re: [PATCH xfstests v3 2/2] generic/756: test name_to_handle_at(AT_HANDLE_MNT_ID_UNIQUE) explicitly, Aleksa Sarai
    • Re: [PATCH xfstests v3 1/2] open_by_handle: verify u32 and u64 mount IDs, Amir Goldstein
  • [PATCH xfstests v4 1/2] open_by_handle: verify u32 and u64 mount IDs, Aleksa Sarai
    • [PATCH xfstests v4 2/2] generic/756: test name_to_handle_at(AT_HANDLE_MNT_ID_UNIQUE) explicitly, Aleksa Sarai
• Recommended version handshake for FUSE clients, Florian Weimer
  • Re: Recommended version handshake for FUSE clients, Miklos Szeredi
• [PATCH RFT v10 0/8] fork: Support shadow stacks in clone3(), Mark Brown
  • [PATCH RFT v10 1/8] Documentation: userspace-api: Add shadow stack API documentation, Mark Brown
  • [PATCH RFT v10 2/8] selftests: Provide helper header for shadow stack testing, Mark Brown
  • [PATCH RFT v10 3/8] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Mark Brown
  • [PATCH RFT v10 4/8] fork: Add shadow stack support to clone3(), Mark Brown
  • [PATCH RFT v10 5/8] selftests/clone3: Remove redundant flushes of output streams, Mark Brown
  • [PATCH RFT v10 6/8] selftests/clone3: Factor more of main loop into test_clone3(), Mark Brown
  • [PATCH RFT v10 7/8] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code, Mark Brown
  • [PATCH RFT v10 8/8] selftests/clone3: Test shadow stack support, Mark Brown
• It is correct to introduce new sys calls to stable versions?, Miao Wang
  • Re: It is correct to introduce new sys calls to stable versions?, Cyril Hrubis
  • Re: It is correct to introduce new sys calls to stable versions?, Greg Kroah-Hartman
    • Re: It is correct to introduce new sys calls to stable versions?, Miao Wang
      • Re: It is correct to introduce new sys calls to stable versions?, Greg Kroah-Hartman
        • Re: It is correct to introduce new sys calls to stable versions?, Willy Tarreau
          • Re: It is correct to introduce new sys calls to stable versions?, Miao Wang
            • Re: It is correct to introduce new sys calls to stable versions?, Willy Tarreau
              • Re: It is correct to introduce new sys calls to stable versions?, Miao Wang
      • Re: It is correct to introduce new sys calls to stable versions?, Theodore Ts'o
• [PATCH RFT v9 0/8] fork: Support shadow stacks in clone3(), Mark Brown
  • [PATCH RFT v9 1/8] Documentation: userspace-api: Add shadow stack API documentation, Mark Brown
  • [PATCH RFT v9 2/8] selftests: Provide helper header for shadow stack testing, Mark Brown
    • Re: [PATCH RFT v9 2/8] selftests: Provide helper header for shadow stack testing, Edgecombe, Rick P
  • [PATCH RFT v9 3/8] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Mark Brown
  • [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
    • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
      • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
        • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
          • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
            • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
              • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
                • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
                  • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
                    • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Catalin Marinas
                    • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Christian Brauner
                      • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
                        • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Christian Brauner
                          • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
                            • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
                              • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
                                • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Mark Brown
                                • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
                          • Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3(), Yury Khrustalev
  • [PATCH RFT v9 5/8] selftests/clone3: Remove redundant flushes of output streams, Mark Brown
  • [PATCH RFT v9 6/8] selftests/clone3: Factor more of main loop into test_clone3(), Mark Brown
  • [PATCH RFT v9 7/8] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code, Mark Brown
  • [PATCH RFT v9 8/8] selftests/clone3: Test shadow stack support, Mark Brown
• Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Levi Zim
  • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Charlie Jenkins
    • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Levi Zim
      • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Palmer Dabbelt
        • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Yangyu Chen
          • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Charlie Jenkins
            • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Yangyu Chen
              • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Charlie Jenkins
                • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Yangyu Chen
                  • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Charlie Jenkins
    • Message not available
      • Re: [PATCH v3 1/3] riscv: mm: Use hint address in mmap if available, Charlie Jenkins
• Manpower Recruitment For Canada™, TFWP-PROGRAM
  • <Possible follow-ups>
  • Manpower Recruitment For Canada™, TFWP PROGRAM
• [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3(), Mark Brown
  • [PATCH RFT v8 1/9] Documentation: userspace-api: Add shadow stack API documentation, Mark Brown
    • Re: [PATCH RFT v8 1/9] Documentation: userspace-api: Add shadow stack API documentation, Catalin Marinas
  • [PATCH RFT v8 2/9] selftests: Provide helper header for shadow stack testing, Mark Brown
  • [PATCH RFT v8 3/9] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Mark Brown
    • Re: [PATCH RFT v8 3/9] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Catalin Marinas
  • [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
    • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Catalin Marinas
      • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
        • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Catalin Marinas
          • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
            • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Catalin Marinas
              • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
    • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
      • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
      • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Catalin Marinas
        • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
          • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Catalin Marinas
            • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
        • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Edgecombe, Rick P
          • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
          • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Catalin Marinas
            • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
      • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Jann Horn
        • Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3(), Mark Brown
  • [PATCH RFT v8 5/9] selftests/clone3: Remove redundant flushes of output streams, Mark Brown
  • [PATCH RFT v8 6/9] selftests/clone3: Factor more of main loop into test_clone3(), Mark Brown
  • [PATCH RFT v8 7/9] selftests/clone3: Explicitly handle child exits due to signals, Mark Brown
  • [PATCH RFT v8 8/9] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code, Mark Brown
  • [PATCH RFT v8 9/9] selftests/clone3: Test shadow stack support, Mark Brown
  • Re: [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3(), Kees Cook
    • Re: [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3(), Edgecombe, Rick P
  • Re: [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3(), Jann Horn
    • Re: [PATCH RFT v8 0/9] fork: Support shadow stacks in clone3(), Mark Brown
• [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, kernel test robot
  • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
    • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Pedro Falcato
      • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
        • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
          • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
            • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Michael Ellerman
              • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
                • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Michael Ellerman
                  • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
                    • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Michael Ellerman
            • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Oliver Sang
              • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
              • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Pedro Falcato
                • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Oliver Sang
          • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
            • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
              • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
              • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Nicholas Piggin
                • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
                  • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
                  • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Michael Ellerman
                    • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Linus Torvalds
                    • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Christophe Leroy
    • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
  • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
  • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
    • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Oliver Sang
      • Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec -4.4% regression, Jeff Xu
• [GIT PULL] asm-generic: fixes for 6.11, Arnd Bergmann
  • Re: [GIT PULL] asm-generic: fixes for 6.11, pr-tracker-bot
• [PATCH] syscalls: fix syscall macros for newfstat/newfstatat, Arnd Bergmann
  • Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat, Rudi Heitbaum
    • Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat, Jakub Jelinek
      • Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat, Arnd Bergmann
        • Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat, Jakub Jelinek
          • Re: [PATCH] syscalls: fix syscall macros for newfstat/newfstatat, Arnd Bergmann
• [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, Andy Pan via B4 Relay
  • Re:[PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
  • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
    • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
    • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
  • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
    • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
      • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
        • Re: [PATCH v5] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
• syscall.tbl refactoring seems to have dropped definition of __NR_newfstatat on arm64 and riscv (64-bit) at least, Florian Weimer
  • Re: syscall.tbl refactoring seems to have dropped definition of __NR_newfstatat on arm64 and riscv (64-bit) at least, Andreas Schwab
    • Re: syscall.tbl refactoring seems to have dropped definition of __NR_newfstatat on arm64 and riscv (64-bit) at least, Arnd Bergmann
• [PATCH RFC v3 0/2] fhandle: expose u64 mount id to name_to_handle_at(2), Aleksa Sarai
  • [PATCH RFC v3 1/2] uapi: explain how per-syscall AT_* flags should be allocated, Aleksa Sarai
    • Re: [PATCH RFC v3 1/2] uapi: explain how per-syscall AT_* flags should be allocated, Jeff Layton
  • [PATCH RFC v3 2/2] fhandle: expose u64 mount id to name_to_handle_at(2), Aleksa Sarai
    • Re: [PATCH RFC v3 2/2] fhandle: expose u64 mount id to name_to_handle_at(2), Jeff Layton
  • Re: [PATCH RFC v3 0/2] fhandle: expose u64 mount id to name_to_handle_at(2), Josef Bacik
    • Re: [PATCH RFC v3 0/2] fhandle: expose u64 mount id to name_to_handle_at(2), Aleksa Sarai
• [PATCH v4] epoll.7: clarify the event distribution under edge-triggered mode, Andy Pan via B4 Relay
• [PATCH RFT v7 0/9] fork: Support shadow stacks in clone3(), Mark Brown
  • [PATCH RFT v7 1/9] Documentation: userspace-api: Add shadow stack API documentation, Mark Brown
  • [PATCH RFT v7 2/9] selftests: Provide helper header for shadow stack testing, Mark Brown
  • [PATCH RFT v7 3/9] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Mark Brown
  • [PATCH RFT v7 4/9] fork: Add shadow stack support to clone3(), Mark Brown
  • [PATCH RFT v7 5/9] selftests/clone3: Remove redundant flushes of output streams, Mark Brown
  • [PATCH RFT v7 6/9] selftests/clone3: Factor more of main loop into test_clone3(), Mark Brown
  • [PATCH RFT v7 7/9] selftests/clone3: Explicitly handle child exits due to signals, Mark Brown
  • [PATCH RFT v7 8/9] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code, Mark Brown
  • [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
    • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Kees Cook
      • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
        • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Kees Cook
          • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
            • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Kees Cook
            • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Kees Cook
              • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
                • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Kees Cook
      • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
        • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Kees Cook
          • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
            • Re: [PATCH RFT v7 9/9] selftests/clone3: Test shadow stack support, Mark Brown
  • Re: [PATCH RFT v7 0/9] fork: Support shadow stacks in clone3(), Shuah Khan
• [PATCH] nsfs: fix ioctl declaration, Christian Brauner
• [PATCH net-next v8 0/3] net: A lightweight zero-copy notification mechanism for MSG_ZEROCOPY, zijianzhang
  • [PATCH net-next v8 1/3] sock: support copying cmsgs to the user space in sendmsg, zijianzhang
  • [PATCH net-next v8 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control, zijianzhang
    • Re: [PATCH net-next v8 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control, Willem de Bruijn
      • Re: [PATCH net-next v8 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control, Jakub Kicinski
        • Re: [PATCH net-next v8 2/3] sock: add MSG_ZEROCOPY notification mechanism based on msg_control, Willem de Bruijn
  • [PATCH net-next v8 3/3] selftests: add MSG_ZEROCOPY msg_control notification test, zijianzhang
    • Re: [PATCH net-next v8 3/3] selftests: add MSG_ZEROCOPY msg_control notification test, Willem de Bruijn
      • Re: [PATCH net-next v8 3/3] selftests: add MSG_ZEROCOPY msg_control notification test, Zijian Zhang
        • Re: [PATCH net-next v8 3/3] selftests: add MSG_ZEROCOPY msg_control notification test, Willem de Bruijn
          • Re: [PATCH net-next v8 3/3] selftests: add MSG_ZEROCOPY msg_control notification test, Zijian Zhang
• Re: [PATCH 7/8] fs: add an ioctl to get the mnt ns id from nsfs, Dmitry V. Levin
  • Re: [PATCH 7/8] fs: add an ioctl to get the mnt ns id from nsfs, Christian Brauner
• [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, Andy Pan via B4 Relay
  • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
    • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
      • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
        • Message not available
          • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
            • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
              • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
        • Re: [PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
  • <Possible follow-ups>
  • Re:[PATCH v3] epoll.7: clarify the event distribution under edge-triggered mode, 潘少
• Testing if two open descriptors refer to the same inode, Florian Weimer
  • Re: Testing if two open descriptors refer to the same inode, Aleksa Sarai
    • Re: Testing if two open descriptors refer to the same inode, Florian Weimer
  • Re: Testing if two open descriptors refer to the same inode, Mateusz Guzik
    • Re: Testing if two open descriptors refer to the same inode, Florian Weimer
      • Re: Testing if two open descriptors refer to the same inode, Mateusz Guzik
        • Re: Testing if two open descriptors refer to the same inode, Mateusz Guzik
        • Re: Testing if two open descriptors refer to the same inode, Florian Weimer
          • Re: Testing if two open descriptors refer to the same inode, Mateusz Guzik
            • Re: Testing if two open descriptors refer to the same inode, Florian Weimer
              • Re: Testing if two open descriptors refer to the same inode, Mateusz Guzik
            • Re: Testing if two open descriptors refer to the same inode, Aleksa Sarai
              • Re: Testing if two open descriptors refer to the same inode, David Sterba
            • Re: Testing if two open descriptors refer to the same inode, Aleksa Sarai
              • Re: Testing if two open descriptors refer to the same inode, Mateusz Guzik
                • Re: Testing if two open descriptors refer to the same inode, Dave Chinner
          • Re: Testing if two open descriptors refer to the same inode, Dave Chinner
    • Re: Testing if two open descriptors refer to the same inode, Christian Brauner
    • Re: Testing if two open descriptors refer to the same inode, Theodore Ts'o
      • Re: Testing if two open descriptors refer to the same inode, Dave Chinner
        • Re: Testing if two open descriptors refer to the same inode, Theodore Ts'o
        • Re: Testing if two open descriptors refer to the same inode, Christoph Hellwig
  • Re: Testing if two open descriptors refer to the same inode, Jeff Layton
    • Re: Testing if two open descriptors refer to the same inode, Florian Weimer
• [PATCH v2] epoll.7: clarify the event distribution under edge-triggered mode, Andy Pan via B4 Relay
• Re: [PATCH] epoll.7: clarify the event distribution under edge-triggered mode, Alejandro Colomar
• [no subject], Unknown
• [no subject], Unknown
• [question] about NFS4 ACLs, Mathias Dufresne
• [PATCH 0/2] uprobe: Fix uretprobe syscall wiring, Jiri Olsa
  • [PATCH 1/2] uprobe: Change uretprobe syscall scope and number, Jiri Olsa
    • Re: [PATCH 1/2] uprobe: Change uretprobe syscall scope and number, Andrii Nakryiko
    • Re: [PATCH 1/2] uprobe: Change uretprobe syscall scope and number, Dmitry V. Levin
      • Re: [PATCH 1/2] uprobe: Change uretprobe syscall scope and number, Arnd Bergmann
  • [PATCH 2/2] selftests/bpf: Change uretprobe syscall number in uprobe_syscall test, Jiri Olsa
    • Re: [PATCH 2/2] selftests/bpf: Change uretprobe syscall number in uprobe_syscall test, Andrii Nakryiko
      • Re: [PATCH 2/2] selftests/bpf: Change uretprobe syscall number in uprobe_syscall test, Google
        • Re: [PATCH 2/2] selftests/bpf: Change uretprobe syscall number in uprobe_syscall test, Jiri Olsa
• [PATCH v23 0/4] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v23 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v23 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Miaohe Lin
  • [PATCH v23 2/4] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • [PATCH] random: vDSO getrandom() must reject invalid flag, Yann Droneaud
      • Re: [PATCH] random: vDSO getrandom() must reject invalid flag, Jason A. Donenfeld
  • [PATCH v23 3/4] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
  • [PATCH v23 4/4] selftests/vDSO: add tests for vgetrandom, Jason A. Donenfeld
• mprotect PROT_SIGNAL, Soni "They/Them" L.
  • Re: mprotect PROT_SIGNAL, Florian Weimer
    • Re: mprotect PROT_SIGNAL, Soni "They/Them" L.
• [PATCH v22 0/4] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
      • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
        • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
          • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
            • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
              • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Linus Torvalds
                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                  • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                    • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                      • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                        • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                          • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                            • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                              • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Yu Zhao
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Yu Zhao
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Yu Zhao
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                                • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                      • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                  • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Linus Torvalds
                    • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                      • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Linus Torvalds
                        • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                    • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                      • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
      • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
        • Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
  • [PATCH v22 2/4] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
  • [PATCH v22 3/4] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
  • [PATCH v22 4/4] selftests/vDSO: add tests for vgetrandom, Jason A. Donenfeld
• [PATCH v21 0/4] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
      • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Linus Torvalds
        • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
          • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Linus Torvalds
            • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
              • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Linus Torvalds
                • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                  • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                    • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                      • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                  • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                    • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                      • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                        • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                        • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                          • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                            • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
                              • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                    • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
                • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
        • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
      • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
        • Re: [PATCH v21 1/4] mm: add VM_DROPPABLE for designating always lazily freeable mappings, David Hildenbrand
  • [PATCH v21 2/4] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
  • [PATCH v21 3/4] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
  • [PATCH v21 4/4] selftests/vDSO: add tests for vgetrandom, Jason A. Donenfeld
• [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
  • [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
    • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Kees Cook
      • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
        • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Kees Cook
          • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jarkko Sakkinen
            • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
              • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jarkko Sakkinen
          • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
            • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Roberto Sassu
              • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
    • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
      • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
        • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
          • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
            • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Steve Dower
              • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
                • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
                  • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
                    • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
                      • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Kees Cook
                        • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
                          • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
                            • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Steve Dower
                            • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
                              • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Jeff Xu
                      • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Steve Dower
    • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Andy Lutomirski
      • Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits, Mickaël Salaün
  • [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Kees Cook
      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
        • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Kees Cook
    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Florian Weimer
      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
        • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Florian Weimer
          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
            • [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC (was: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)), Florian Weimer
              • Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC, Eric W. Biederman
                • Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC, Florian Weimer
              • Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC (was: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)), Mickaël Salaün
      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
        • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Florian Weimer
          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Florian Weimer
              • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
                • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                  • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Florian Weimer
                    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                  • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
                    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Andy Lutomirski
      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Steve Dower
        • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Andy Lutomirski
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
              • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Andy Lutomirski
                • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jarkko Sakkinen
                  • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
              • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
        • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), James Bottomley
              • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
              • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
                  • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                    • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
                      • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                        • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
                          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
              • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
                • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Jeff Xu
                  • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
          • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), enh
            • Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2), Mickaël Salaün
  • [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec, Mickaël Salaün
    • Re: [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec, Mimi Zohar
      • Re: [RFC PATCH v19 5/5] samples/should-exec: Add set-should-exec, Mickaël Salaün
  • [RFC PATCH v19 4/5] selftests/landlock: Add tests for execveat + AT_CHECK, Mickaël Salaün
  • [RFC PATCH v19 3/5] selftests/exec: Add tests for AT_CHECK and related securebits, Mickaël Salaün
  • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mimi Zohar
    • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
      • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Roberto Sassu
        • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), James Bottomley
          • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
            • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
          • Message not available
            • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
              • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Boris Lukashev
                • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
  • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Jonathan Corbet
    • Re: [RFC PATCH v19 0/5] Script execution control (was O_MAYEXEC), Mickaël Salaün
• [PATCH v20 0/5] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v20 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
  • [PATCH v20 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
  • [PATCH v20 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
    • Re: [PATCH v20 3/5] arch: allocate vgetrandom_alloc() syscall number, Arnd Bergmann
      • Re: [PATCH v20 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
  • [PATCH v20 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
  • [PATCH v20 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
• [PATCH v19 0/5] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v19 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v19 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Andrew Morton
      • Re: [PATCH v19 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
  • [PATCH v19 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
  • [PATCH v19 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
  • [PATCH v19 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
  • [PATCH v19 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
• [PATCH] uapi: change TRACE_MMAP_IOCTL_GET_READER to avoid collision with TCGETS, Dmitry V. Levin
• Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Dmitry V. Levin
  • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Steven Rostedt
    • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Mathieu Desnoyers
      • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Steven Rostedt
        • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Mathieu Desnoyers
          • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Dmitry V. Levin
          • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Steven Rostedt
            • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Mathieu Desnoyers
            • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Beau Belgrave
        • Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer, Dmitry V. Levin
• [PATCH] syscalls: fix sys_fanotify_mark prototype, Arnd Bergmann
  • Re: [PATCH] syscalls: fix sys_fanotify_mark prototype, Helge Deller
• [PATCH v3] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Devin Bayer
  • Re: [PATCH v3] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Ilpo Järvinen
• [PATCH RFT v6 0/9] fork: Support shadow stacks in clone3(), Mark Brown
  • [PATCH RFT v6 1/9] Documentation: userspace-api: Add shadow stack API documentation, Mark Brown
    • Re: [PATCH RFT v6 1/9] Documentation: userspace-api: Add shadow stack API documentation, Randy Dunlap
  • [PATCH RFT v6 2/9] selftests: Provide helper header for shadow stack testing, Mark Brown
  • [PATCH RFT v6 3/9] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Mark Brown
    • Re: [PATCH RFT v6 3/9] mm: Introduce ARCH_HAS_USER_SHADOW_STACK, Thiago Jung Bauermann
  • [PATCH RFT v6 4/9] fork: Add shadow stack support to clone3(), Mark Brown
  • [PATCH RFT v6 5/9] selftests/clone3: Remove redundant flushes of output streams, Mark Brown
  • [PATCH RFT v6 6/9] selftests/clone3: Factor more of main loop into test_clone3(), Mark Brown
  • [PATCH RFT v6 7/9] selftests/clone3: Explicitly handle child exits due to signals, Mark Brown
  • [PATCH RFT v6 8/9] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code, Mark Brown
  • [PATCH RFT v6 9/9] selftests/clone3: Test shadow stack support, Mark Brown
• [PATCH v2] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Devin Bayer
  • Re: [PATCH v2] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Luke Jones
    • Re: [PATCH v2] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Ilpo Järvinen
      • Re: [PATCH v2] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Luke Jones
  • Re: [PATCH v2] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Ilpo Järvinen
    • Re: [PATCH v2] platform/x86: asus-wmi: support the disable camera LED on F10 of Zenbook 2023, Devin Bayer
• [PATCH 0/2] platform/x86: asus-wmi: support a couple Zenbook 2023 features, Devin Bayer
  • [PATCH 2/2] platform/x86: asus-wmi: support newer fan_boost_mode dev_id, Devin Bayer
    • Re: [PATCH 2/2] platform/x86: asus-wmi: support newer fan_boost_mode dev_id, Luke Jones
      • Re: [PATCH 2/2] platform/x86: asus-wmi: support newer fan_boost_mode dev_id, Devin Bayer
  • [PATCH 1/2] platform/x86: asus-wmi: support camera disable LED, Devin Bayer
    • Re: [PATCH 1/2] platform/x86: asus-wmi: support camera disable LED, Luke Jones
      • Re: [PATCH 1/2] platform/x86: asus-wmi: support camera disable LED, Devin Bayer
        • Re: [PATCH 1/2] platform/x86: asus-wmi: support camera disable LED, Luke Jones
• [PATCH v18 0/5] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v18 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
  • [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
    • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Aleksa Sarai
      • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
        • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Thomas Gleixner
          • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
            • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
            • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
              • Re: [PATCH v18 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
  • [PATCH v18 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
  • [PATCH v18 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • Re: [PATCH v18 4/5] random: introduce generic vDSO getrandom() implementation, Thomas Gleixner
  • [PATCH v18 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
    • Re: [PATCH v18 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Thomas Gleixner
• [PATCH v17 0/5] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v17 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v17 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, John Hubbard
  • [PATCH v17 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
  • [PATCH v17 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
  • [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Andy Lutomirski
      • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
        • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
        • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Peter Zijlstra
          • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
        • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Andy Lutomirski
          • Re: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
            • RE: [PATCH v17 4/5] random: introduce generic vDSO getrandom() implementation, David Laight
  • [PATCH v17 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
    • Re: [PATCH v17 5/5] x86: vdso: Wire up getrandom() vDSO implementation, John Hubbard
      • Re: [PATCH v17 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
• termios constants should be unsigned, Alejandro Colomar
  • Re: termios constants should be unsigned, Greg KH
    • [PATCH] uapi/asm/termbits: Use the U integer suffix for bit fields, Alejandro Colomar
      • Re: [PATCH] uapi/asm/termbits: Use the U integer suffix for bit fields, Greg KH
        • Re: [PATCH] uapi/asm/termbits: Use the U integer suffix for bit fields, Alejandro Colomar
          • Re: [PATCH] uapi/asm/termbits: Use the U integer suffix for bit fields, Greg KH
            • Re: [PATCH] uapi/asm/termbits: Use the U integer suffix for bit fields, Alejandro Colomar
  • Re: termios constants should be unsigned, Paul Eggert
    • Re: termios constants should be unsigned, Alejandro Colomar
      • Re: termios constants should be unsigned, enh
        • Re: termios constants should be unsigned, Alejandro Colomar
        • Re: termios constants should be unsigned, Alejandro Colomar
          • Re: termios constants should be unsigned, enh
            • Re: termios constants should be unsigned, Alejandro Colomar
      • Re: termios constants should be unsigned, Paul Eggert
    • Re: termios constants should be unsigned, Zack Weinberg
      • Re: termios constants should be unsigned, Paul Eggert
        • Re: termios constants should be unsigned, Alejandro Colomar
• [PATCHv8 bpf-next 0/9] uprobe: uretprobe speed up, Jiri Olsa
  • [PATCHv8 bpf-next 1/9] x86/shstk: Make return uprobe work with shadow stack, Jiri Olsa
  • [PATCHv8 bpf-next 2/9] uprobe: Wire up uretprobe system call, Jiri Olsa
  • [PATCHv8 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe, Jiri Olsa
    • Re: [PATCHv8 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe, Nathan Chancellor
      • Re: [PATCHv8 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe, Jiri Olsa
        • Re: [PATCHv8 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe, Nathan Chancellor
    • Re: [PATCHv8 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe, Guenter Roeck
      • Re: [PATCHv8 bpf-next 3/9] uprobe: Add uretprobe syscall to speed up return probe, Oleg Nesterov
  • [PATCHv8 bpf-next 4/9] selftests/x86: Add return uprobe shadow stack test, Jiri Olsa
  • [PATCHv8 bpf-next 5/9] selftests/bpf: Add uretprobe syscall test for regs integrity, Jiri Olsa
  • [PATCHv8 bpf-next 6/9] selftests/bpf: Add uretprobe syscall test for regs changes, Jiri Olsa
  • [PATCHv8 bpf-next 7/9] selftests/bpf: Add uretprobe syscall call from user space test, Jiri Olsa
  • [PATCHv8 bpf-next 8/9] selftests/bpf: Add uretprobe shadow stack test, Jiri Olsa
  • [PATCHv8 9/9] man2: Add uretprobe syscall page, Jiri Olsa
    • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Google
      • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Alejandro Colomar
        • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Steven Rostedt
          • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Alejandro Colomar
            • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Jiri Olsa
              • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Alejandro Colomar
                • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Alejandro Colomar
                  • Re: [PATCHv8 9/9] man2: Add uretprobe syscall page, Jiri Olsa
  • Re: [PATCHv8 bpf-next 0/9] uprobe: uretprobe speed up, Google
    • Re: [PATCHv8 bpf-next 0/9] uprobe: uretprobe speed up, Andrii Nakryiko
• [no subject], Unknown
• Header conflicts with shmget() and SHM_HUGE_2MB, Carlos Llamas
  • Re: Header conflicts with shmget() and SHM_HUGE_2MB, Andi Kleen
• [PATCH v16 0/5] implement getrandom() in vDSO, Jason A. Donenfeld
  • [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Frank van der Linden
      • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jann Horn
      • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
        • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jann Horn
          • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
            • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jann Horn
              • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jann Horn
                • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Michal Hocko
                  • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Jason A. Donenfeld
    • Re: [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings, Andy Lutomirski
  • [PATCH v16 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
    • Re: [PATCH v16 2/5] random: add vgetrandom_alloc() syscall, Eric Biggers
      • Re: [PATCH v16 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
        • Re: [PATCH v16 2/5] random: add vgetrandom_alloc() syscall, Eric Biggers
          • Re: [PATCH v16 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
            • Re: [PATCH v16 2/5] random: add vgetrandom_alloc() syscall, Jason A. Donenfeld
  • [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
    • Re: [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number, Geert Uytterhoeven
      • Re: [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
        • Re: [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
          • Re: [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number, Eric Biggers
            • Re: [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number, Jason A. Donenfeld
  • [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Randy Dunlap
    • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Randy Dunlap
      • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Andy Lutomirski
      • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Thomas Gleixner
      • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Thomas Gleixner
        • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
      • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Jason A. Donenfeld
    • Re: [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation, Andy Lutomirski
  • [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
    • Re: [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Eric Biggers
      • Re: [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
    • Re: [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Randy Dunlap
      • Re: [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
    • Re: [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Thomas Gleixner
      • Re: [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation, Jason A. Donenfeld
  • Re: [PATCH v16 0/5] implement getrandom() in vDSO, Jason A. Donenfeld
• Re: Correct way of calling prctl(2) (was: Sashimi of prctl(2)), Alejandro Colomar
  • [PATCH v1 0/2] uapi/linux/prctl: Use the L and UL integer suffixes for certain constants, Alejandro Colomar
    • [PATCH v1 1/2] uapi/linux/prctl: Use the L integer suffix for enumerations of width long, Alejandro Colomar
    • [PATCH v1 2/2] uapi/linux/prctl: Use the UL integer suffix for bit fields of width long, Alejandro Colomar
    • Re: [PATCH v1 0/2] uapi/linux/prctl: Use the L and UL integer suffixes for certain constants, Alejandro Colomar
• Re: [PATCH v2] xfs_io: make MADV_SOFT_OFFLINE conditional, Christoph Hellwig
  • Re: [PATCH v2] xfs_io: make MADV_SOFT_OFFLINE conditional, Bastian Germann
• [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Aleksa Sarai
  • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Amir Goldstein
  • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
    • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Aleksa Sarai
      • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
        • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Trond Myklebust
              • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
        • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Jan Kara
          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
              • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
                • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
                  • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
                    • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
                      • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
                        • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Miklos Szeredi
                          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
                          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Aleksa Sarai
                            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Jan Kara
                            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
                        • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
                          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christoph Hellwig
                            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
    • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Trond Myklebust
      • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), hch@xxxxxxxxxxxxx
        • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Trond Myklebust
          • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), hch@xxxxxxxxxxxxx
            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
              • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), hch@xxxxxxxxxxxxx
            • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Jan Kara
              • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), hch@xxxxxxxxxxxxx
                • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Dave Chinner
                  • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), hch@xxxxxxxxxxxxx
                    • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Amir Goldstein
    • Re: [PATCH RFC v2] fhandle: expose u64 mount id to name_to_handle_at(2), Christian Brauner
• [PATCH v2 0/1] Add FUTEX_SPIN operation, André Almeida
  • [PATCH v2 1/1] futex: Add FUTEX_SPIN operation, André Almeida
    • Re: [PATCH v2 1/1] futex: Add FUTEX_SPIN operation, Mathieu Desnoyers