Linux API

• Date Index

• [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), (continued)
  • [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
  • [PATCH RESEND 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
  • [PATCH RESEND 1/4] scsi: sg: fix BLKSECTGET ioctl, Tom Yan
    • [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
      • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Christoph Hellwig
        • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
          • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Christoph Hellwig
            • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
              • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Christoph Hellwig
                • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
                  • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Christoph Hellwig
                    • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Douglas Gilbert
                      • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Alan Stern
                    • Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
    • [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
      • Re: [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), Greg KH
        • Re: [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
          • [PATCH v2 1/4] scsi: sg: fix BLKSECTGET ioctl, Tom Yan
            • [PATCH v2 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
            • [PATCH v2 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
            • [PATCH v2 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
          • [PATCH v3 1/4] scsi: sg: fix BLKSECTGET ioctl, Tom Yan
            • [PATCH v3 2/4] scsi: sg: implement BLKSSZGET, Tom Yan
            • [PATCH v3 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
            • [PATCH v3 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
    • [PATCH RESEND 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes(), Tom Yan
• [PATCH v6 0/9] Syscall User Dispatch, Gabriel Krisman Bertazi
  • [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
    • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Christian Brauner
      • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
        • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Kees Cook
          • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
    • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, peterz
      • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
        • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Peter Zijlstra
    • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Kees Cook
      • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
        • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Kees Cook
          • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Thomas Gleixner
            • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
              • Re: [PATCH v6 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Kees Cook
  • [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, Gabriel Krisman Bertazi
    • Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, Christian Brauner
      • Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, Andy Lutomirski
        • Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, Christian Brauner
          • Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, Andy Lutomirski
    • Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, peterz
  • [PATCH v6 7/9] x86: Enable Syscall User Dispatch, Gabriel Krisman Bertazi
    • Re: [PATCH v6 7/9] x86: Enable Syscall User Dispatch, Kees Cook
      • Re: [PATCH v6 7/9] x86: Enable Syscall User Dispatch, Gabriel Krisman Bertazi
  • [PATCH v6 8/9] selftests: Add kselftest for syscall user dispatch, Gabriel Krisman Bertazi
    • Re: [PATCH v6 8/9] selftests: Add kselftest for syscall user dispatch, Kees Cook
  • [PATCH v6 9/9] doc: Document Syscall User Dispatch, Gabriel Krisman Bertazi
    • Re: [PATCH v6 9/9] doc: Document Syscall User Dispatch, Kees Cook
  • [PATCH v6 3/9] x86: vdso: Expose sigreturn address on vdso to the kernel, Gabriel Krisman Bertazi
    • Re: [PATCH v6 3/9] x86: vdso: Expose sigreturn address on vdso to the kernel, Kees Cook
  • [PATCH v6 5/9] kernel: Implement selective syscall userspace redirection, Gabriel Krisman Bertazi
    • Re: [PATCH v6 5/9] kernel: Implement selective syscall userspace redirection, Matthew Wilcox
    • Re: [PATCH v6 5/9] kernel: Implement selective syscall userspace redirection, peterz
  • [PATCH v6 2/9] kernel: entry: Support TIF_SYSCAL_INTERCEPT on common entry code, Gabriel Krisman Bertazi
    • Re: [PATCH v6 2/9] kernel: entry: Support TIF_SYSCAL_INTERCEPT on common entry code, Christian Brauner
    • Re: [PATCH v6 2/9] kernel: entry: Support TIF_SYSCAL_INTERCEPT on common entry code, peterz
      • Re: [PATCH v6 2/9] kernel: entry: Support TIF_SYSCAL_INTERCEPT on common entry code, Gabriel Krisman Bertazi
  • [PATCH v6 4/9] signal: Expose SYS_USER_DISPATCH si_code type, Gabriel Krisman Bertazi
    • Re: [PATCH v6 4/9] signal: Expose SYS_USER_DISPATCH si_code type, Christian Brauner
    • Re: [PATCH v6 4/9] signal: Expose SYS_USER_DISPATCH si_code type, Kees Cook
• [RESEND RFC PATCH 0/5] Remote mapping, Adalbert Lazăr
  • [RESEND RFC PATCH 5/5] pidfd_mem: implemented remote memory mapping system call, Adalbert Lazăr
    • Re: [RESEND RFC PATCH 5/5] pidfd_mem: implemented remote memory mapping system call, Florian Weimer
    • Re: [RESEND RFC PATCH 5/5] pidfd_mem: implemented remote memory mapping system call, Christian Brauner
  • [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Adalbert Lazăr
    • Re: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Oleg Nesterov
    • Re: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Oleg Nesterov
      • Re: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Adalbert Lazăr
      • RE: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Mircea CIRJALIU - MELIU
        • Re: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Oleg Nesterov
    • Re: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Christian Brauner
      • RE: [RESEND RFC PATCH 4/5] mm/remote_mapping: use a pidfd to access memory belonging to unrelated process, Mircea CIRJALIU - MELIU
  • [RESEND RFC PATCH 3/5] mm/mmu_notifier: remove lockdep map, allow mmu notifier to be used in nested scenarios, Adalbert Lazăr
    • Re: [RESEND RFC PATCH 3/5] mm/mmu_notifier: remove lockdep map, allow mmu notifier to be used in nested scenarios, Jason Gunthorpe
  • [RESEND RFC PATCH 2/5] mm: let the VMA decide how zap_pte_range() acts on mapped pages, Adalbert Lazăr
  • [RESEND RFC PATCH 1/5] mm: add atomic capability to zap_details, Adalbert Lazăr
  • Re: [RESEND RFC PATCH 0/5] Remote mapping, Jason Gunthorpe
    • RE: [RESEND RFC PATCH 0/5] Remote mapping, Mircea CIRJALIU - MELIU
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Jason Gunthorpe
        • RE: [RESEND RFC PATCH 0/5] Remote mapping, Mircea CIRJALIU - MELIU
          • Re: [RESEND RFC PATCH 0/5] Remote mapping, Jason Gunthorpe
            • RE: [RESEND RFC PATCH 0/5] Remote mapping, Mircea CIRJALIU - MELIU
              • Re: [RESEND RFC PATCH 0/5] Remote mapping, Jason Gunthorpe
    • Re: [RESEND RFC PATCH 0/5] Remote mapping, Matthew Wilcox
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Jason Gunthorpe
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Paolo Bonzini
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Jason Gunthorpe
  • Re: [RESEND RFC PATCH 0/5] Remote mapping, Florian Weimer
    • Re: [RESEND RFC PATCH 0/5] Remote mapping, Paolo Bonzini
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Christian Brauner
  • Re: [RESEND RFC PATCH 0/5] Remote mapping, Andy Lutomirski
    • Re: [RESEND RFC PATCH 0/5] Remote mapping, Paolo Bonzini
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Andy Lutomirski
        • Re: [RESEND RFC PATCH 0/5] Remote mapping, Paolo Bonzini
          • Re: [RESEND RFC PATCH 0/5] Remote mapping, Andy Lutomirski
            • Re: [RESEND RFC PATCH 0/5] Remote mapping, Paolo Bonzini
              • Re: [RESEND RFC PATCH 0/5] Remote mapping, Christian Brauner
            • RE: [RESEND RFC PATCH 0/5] Remote mapping, Mircea CIRJALIU - MELIU
          • Re: [RESEND RFC PATCH 0/5] Remote mapping, Christoph Hellwig
            • Re: [RESEND RFC PATCH 0/5] Remote mapping, Paolo Bonzini
    • RE: [RESEND RFC PATCH 0/5] Remote mapping, Mircea CIRJALIU - MELIU
  • Re: [RESEND RFC PATCH 0/5] Remote mapping, Christian Brauner
    • Re: [RESEND RFC PATCH 0/5] Remote mapping, Andy Lutomirski
      • Re: [RESEND RFC PATCH 0/5] Remote mapping, Stefan Hajnoczi
• Re: [RFC PATCH 0/5] Remote mapping, Christian Brauner
  • Re: [RFC PATCH 0/5] Remote mapping, Adalbert Lazăr
• [PATCH v2 0/4] Support non-blocking pidfds, Christian Brauner
  • [PATCH v2 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Christian Brauner
    • Re: [PATCH v2 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Oleg Nesterov
    • Re: [PATCH v2 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Oleg Nesterov
      • Re: [PATCH v2 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Christian Brauner
    • Re: [PATCH v2 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Josh Triplett
  • [PATCH v2 2/4] exit: support non-blocking pidfds, Christian Brauner
    • Re: [PATCH v2 2/4] exit: support non-blocking pidfds, Oleg Nesterov
      • Re: [PATCH v2 2/4] exit: support non-blocking pidfds, Christian Brauner
        • Re: [PATCH v2 2/4] exit: support non-blocking pidfds, Josh Triplett
    • Re: [PATCH v2 2/4] exit: support non-blocking pidfds, Josh Triplett
      • Re: [PATCH v2 2/4] exit: support non-blocking pidfds, Christian Brauner
  • [PATCH v2 4/4] tests: add waitid() tests for non-blocking pidfds, Christian Brauner
  • [PATCH v2 3/4] tests: port pidfd_wait to kselftest harness, Christian Brauner
  • Re: [PATCH v2 0/4] Support non-blocking pidfds, Josh Triplett
    • Re: [PATCH v2 0/4] Support non-blocking pidfds, Christian Brauner
• [PATCH v9 0/3] introduce memory hinting API for external process, Minchan Kim
  • [PATCH v9 2/3] pid: move pidfd_get_pid() to pid.c, Minchan Kim
  • [PATCH v9 1/3] mm/madvise: pass mm to do_madvise, Minchan Kim
  • [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Minchan Kim
    • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Florian Weimer
      • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Minchan Kim
        • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Florian Weimer
          • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Minchan Kim
            • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Christian Brauner
    • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Christoph Hellwig
      • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Michal Hocko
      • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Minchan Kim
        • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Eric Dumazet
          • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Minchan Kim
            • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Linus Torvalds
              • Re: [PATCH v9 3/3] mm/madvise: introduce process_madvise() syscall: an external memory hinting API, Minchan Kim
• Re: [Question] About SECCOMP issue for ILP32, Yury Norov
  • Re: [Question] About SECCOMP issue for ILP32, Xiongfeng Wang
    • Re: [Question] About SECCOMP issue for ILP32, Xiongfeng Wang
  • Re: [Question] About SECCOMP issue for ILP32, Yury Norov
• [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
  • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
    • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Jens Axboe
      • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
        • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Jens Axboe
  • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Christian Brauner
    • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
  • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, John Garry
    • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, Alejandro Colomar
      • Re: [PATCH v2] vfs: add RWF_NOAPPEND flag for pwritev2, John Garry
• [PATCH 0/4] Support non-blocking pidfds, Christian Brauner
  • [PATCH 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Christian Brauner
    • Re: [PATCH 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Oleg Nesterov
      • Re: [PATCH 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Christian Brauner
        • Re: [PATCH 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open(), Oleg Nesterov
  • [PATCH 4/4] tests: add waitid() tests for non-blocking pidfds, Christian Brauner
  • [PATCH 3/4] tests: port pidfd_wait to kselftest harness, Christian Brauner
  • [PATCH 2/4] exit: support non-blocking pidfds, Christian Brauner
    • Re: [PATCH 2/4] exit: support non-blocking pidfds, Oleg Nesterov
      • Re: [PATCH 2/4] exit: support non-blocking pidfds, Christian Brauner
• Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE, Bart Van Assche
  • Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE, Khazhismel Kumykov
    • Re: [PATCH v2] block: grant IOPRIO_CLASS_RT to CAP_SYS_NICE, Jens Axboe
• [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
  • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
    • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
      • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
        • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
          • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
            • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
              • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
                • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
                  • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
                    • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Rich Felker
                      • Re: [RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2, Jann Horn
• [PATCH] x86: Extend arch_prctl (int, ...) to 5 arguments, H.J. Lu
• [PATCH v20 22/23] LSM: Add /proc attr entry for full LSM context, Casey Schaufler
  • Re: [PATCH v20 22/23] LSM: Add /proc attr entry for full LSM context, Randy Dunlap
• [PATCH v11 00/25] Control-flow Enforcement: Shadow Stack, Yu-cheng Yu
  • [PATCH v11 01/25] Documentation/x86: Add CET description, Yu-cheng Yu
  • [PATCH v11 05/25] x86/cet/shstk: Add Kconfig option for user-mode Shadow Stack, Yu-cheng Yu
  • [PATCH v11 06/25] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW, Yu-cheng Yu
  • [PATCH v11 07/25] x86/mm: Remove _PAGE_DIRTY_HW from kernel RO pages, Yu-cheng Yu
  • [PATCH v11 10/25] x86/mm: Update pte_modify for _PAGE_COW, Yu-cheng Yu
  • [PATCH v11 15/25] mm: Fixup places that call pte_mkwrite() directly, Yu-cheng Yu
  • [PATCH v11 18/25] mm: Update can_follow_write_pte() for shadow stack, Yu-cheng Yu
  • [PATCH v11 22/25] binfmt_elf: Define GNU_PROPERTY_X86_FEATURE_1_AND properties, Yu-cheng Yu
  • [PATCH v11 20/25] x86/cet/shstk: User-mode shadow stack support, Yu-cheng Yu
  • [PATCH v11 23/25] ELF: Introduce arch_setup_elf_property(), Yu-cheng Yu
  • [PATCH v11 24/25] x86/cet/shstk: Handle thread shadow stack, Yu-cheng Yu
  • [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu-cheng Yu
    • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
      • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
        • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
          • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
            • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
              • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Martin
                  • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Florian Weimer
                    • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                      • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                        • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                        • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                          • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                            • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Martin
                              • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Martin
                                • Message not available
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu-cheng Yu
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Edgecombe, Rick P
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Borislav Petkov
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Edgecombe, Rick P
                                • Message not available
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu-cheng Yu
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Hansen
                                • Re: [NEEDS-REVIEW] Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                    • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Dave Martin
                      • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Florian Weimer
                        • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                          • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Florian Weimer
                            • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                              • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Florian Weimer
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Florian Weimer
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                            • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                              • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Yu, Yu-cheng
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Florian Weimer
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, Andy Lutomirski
                                • Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack, H.J. Lu
  • [PATCH v11 21/25] x86/cet/shstk: Handle signals for shadow stack, Yu-cheng Yu
  • [PATCH v11 17/25] mm/mmap: Add shadow stack pages to memory accounting, Yu-cheng Yu
  • [PATCH v11 08/25] x86/mm: Introduce _PAGE_COW, Yu-cheng Yu
  • [PATCH v11 16/25] mm: Add guard pages around a shadow stack., Yu-cheng Yu
  • [PATCH v11 19/25] mm: Re-introduce do_mmap_pgoff(), Yu-cheng Yu
  • [PATCH v11 12/25] mm: Introduce VM_SHSTK for shadow stack memory, Yu-cheng Yu
  • [PATCH v11 13/25] x86/mm: Shadow Stack page fault error checking, Yu-cheng Yu
  • [PATCH v11 14/25] x86/mm: Update maybe_mkwrite() for shadow stack, Yu-cheng Yu
  • [PATCH v11 11/25] x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for transition from _PAGE_DIRTY_HW to _PAGE_COW, Yu-cheng Yu
  • [PATCH v11 09/25] drm/i915/gvt: Change _PAGE_DIRTY to _PAGE_DIRTY_BITS, Yu-cheng Yu
  • [PATCH v11 04/25] x86/cet: Add control-protection fault handler, Yu-cheng Yu
  • [PATCH v11 03/25] x86/fpu/xstate: Introduce CET MSR XSAVES supervisor states, Yu-cheng Yu
  • [PATCH v11 02/25] x86/cpufeatures: Add CET CPU feature flags for Control-flow Enforcement Technology (CET), Yu-cheng Yu
• [PATCH v11 0/9] Control-flow Enforcement: Indirect Branch Tracking, PTRACE, Yu-cheng Yu
  • [PATCH v11 3/9] x86/cet/ibt: Handle signals for Indirect Branch Tracking, Yu-cheng Yu
  • [PATCH v11 9/9] x86: Disallow vsyscall emulation when CET is enabled, Yu-cheng Yu
    • Re: [PATCH v11 9/9] x86: Disallow vsyscall emulation when CET is enabled, Andy Lutomirski
      • Re: [PATCH v11 9/9] x86: Disallow vsyscall emulation when CET is enabled, Florian Weimer
        • Re: [PATCH v11 9/9] x86: Disallow vsyscall emulation when CET is enabled, Yu, Yu-cheng
  • [PATCH v11 2/9] x86/cet/ibt: User-mode Indirect Branch Tracking support, Yu-cheng Yu
  • [PATCH v11 7/9] x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point, Yu-cheng Yu
  • [PATCH v11 8/9] x86/vdso: Insert endbr32/endbr64 to vDSO, Yu-cheng Yu
    • Re: [PATCH v11 8/9] x86/vdso: Insert endbr32/endbr64 to vDSO, Andy Lutomirski
      • Re: [PATCH v11 8/9] x86/vdso: Insert endbr32/endbr64 to vDSO, Yu, Yu-cheng
  • [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu-cheng Yu
    • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Jann Horn
      • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu, Yu-cheng
        • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Andy Lutomirski
          • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu, Yu-cheng
            • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Andy Lutomirski
              • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Dave Hansen
                • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Andy Lutomirski
                • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu, Yu-cheng
                  • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Dave Hansen
                    • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Andy Lutomirski
                      • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Dave Hansen
                        • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Andy Lutomirski
                          • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Dave Hansen
                            • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu, Yu-cheng
                    • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu, Yu-cheng
                      • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Andy Lutomirski
        • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Jann Horn
          • Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET, Yu, Yu-cheng
  • [PATCH v11 1/9] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking, Yu-cheng Yu
  • [PATCH v11 5/9] x86/cet/ibt: Update arch_prctl functions for Indirect Branch Tracking, Yu-cheng Yu
  • [PATCH v11 4/9] x86/cet/ibt: ELF header parsing for Indirect Branch Tracking, Yu-cheng Yu
• [PATCH v5 0/9] fs: interface for directly reading/writing compressed data, Omar Sandoval
  • [PATCH man-pages v5] Document encoded I/O, Omar Sandoval
    • Re: [PATCH man-pages v5] Document encoded I/O, Amir Goldstein
      • Re: [PATCH man-pages v5] Document encoded I/O, Omar Sandoval
  • [PATCH v5 1/9] iov_iter: add copy_struct_from_iter(), Omar Sandoval
    • Re: [PATCH v5 1/9] iov_iter: add copy_struct_from_iter(), Josef Bacik
      • Re: [PATCH v5 1/9] iov_iter: add copy_struct_from_iter(), Omar Sandoval
  • [PATCH v5 2/9] fs: add O_ALLOW_ENCODED open flag, Omar Sandoval
    • Re: [PATCH v5 2/9] fs: add O_ALLOW_ENCODED open flag, Josef Bacik
      • Re: [PATCH v5 2/9] fs: add O_ALLOW_ENCODED open flag, Omar Sandoval
  • [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data, Omar Sandoval
    • Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data, Amir Goldstein
      • Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data, Omar Sandoval
        • Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data, Amir Goldstein
          • Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data, Omar Sandoval
    • Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data, Josef Bacik
  • [PATCH v5 5/9] btrfs: add ram_bytes and offset to btrfs_ordered_extent, Omar Sandoval
    • Re: [PATCH v5 5/9] btrfs: add ram_bytes and offset to btrfs_ordered_extent, Josef Bacik
  • [PATCH v5 4/9] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio(), Omar Sandoval
    • Re: [PATCH v5 4/9] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio(), Josef Bacik
  • [PATCH v5 6/9] btrfs: support different disk extent size for delalloc, Omar Sandoval
    • Re: [PATCH v5 6/9] btrfs: support different disk extent size for delalloc, Josef Bacik
  • [PATCH v5 7/9] btrfs: optionally extend i_size in cow_file_range_inline(), Omar Sandoval
    • Re: [PATCH v5 7/9] btrfs: optionally extend i_size in cow_file_range_inline(), Josef Bacik
  • [PATCH v5 8/9] btrfs: implement RWF_ENCODED reads, Omar Sandoval
    • Re: [PATCH v5 8/9] btrfs: implement RWF_ENCODED reads, Josef Bacik
      • Re: [PATCH v5 8/9] btrfs: implement RWF_ENCODED reads, Omar Sandoval
  • [PATCH v5 9/9] btrfs: implement RWF_ENCODED writes, Omar Sandoval
    • Re: [PATCH v5 9/9] btrfs: implement RWF_ENCODED writes, Josef Bacik
      • Re: [PATCH v5 9/9] btrfs: implement RWF_ENCODED writes, Omar Sandoval
• [PATCH v32 00/12] /dev/random - a new approach with full SP800-90B compliance, Stephan Müller
  • [PATCH v32 12/12] LRNG - add power-on and runtime self-tests, Stephan Müller
  • [PATCH v32 05/12] crypto: DRBG - externalize DRBG functions for LRNG, Stephan Müller
  • [PATCH v32 07/12] LRNG - add kernel crypto API PRNG extension, Stephan Müller
    • Re: [PATCH v32 07/12] LRNG - add kernel crypto API PRNG extension, kernel test robot
  • [PATCH v32 11/12] LRNG - add interface for gathering of raw entropy, Stephan Müller
    • Re: [PATCH v32 11/12] LRNG - add interface for gathering of raw entropy, kernel test robot
  • [PATCH v32 09/12] LRNG - add Jitter RNG fast noise source, Stephan Müller
  • [PATCH v32 08/12] crypto: provide access to a static Jitter RNG state, Stephan Müller
  • [PATCH v32 02/12] LRNG - allocate one DRNG instance per NUMA node, Stephan Müller
  • [PATCH v32 04/12] LRNG - add switchable DRNG support, Stephan Müller
  • [PATCH v32 06/12] LRNG - add SP800-90A DRBG extension, Stephan Müller
    • Re: [PATCH v32 06/12] LRNG - add SP800-90A DRBG extension, kernel test robot
      • Re: [PATCH v32 06/12] LRNG - add SP800-90A DRBG extension, Stephan Müller
  • [PATCH v32 01/12] Linux Random Number Generator, Stephan Müller
    • Re: [PATCH v32 01/12] Linux Random Number Generator, kernel test robot
      • Re: [PATCH v32 01/12] Linux Random Number Generator, Stephan Müller
  • [PATCH v32 10/12] LRNG - add SP800-90B compliant health tests, Stephan Müller
  • [PATCH v32 03/12] LRNG - sysctls and /proc interface, Stephan Müller
  • [PATCH v33 00/12] /dev/random - a new approach with full SP800-90B compliance, Stephan Müller
    • [PATCH v33 08/12] crypto: provide access to a static Jitter RNG state, Stephan Müller
    • [PATCH v33 07/12] LRNG - add kernel crypto API PRNG extension, Stephan Müller
    • [PATCH v33 12/12] LRNG - add power-on and runtime self-tests, Stephan Müller
      • Re: [PATCH v33 12/12] LRNG - add power-on and runtime self-tests, kernel test robot
    • [PATCH v33 11/12] LRNG - add interface for gathering of raw entropy, Stephan Müller
    • [PATCH v33 10/12] LRNG - add SP800-90B compliant health tests, Stephan Müller
    • [PATCH v33 05/12] crypto: DRBG - externalize DRBG functions for LRNG, Stephan Müller
    • [PATCH v33 09/12] LRNG - add Jitter RNG fast noise source, Stephan Müller
    • [PATCH v33 04/12] LRNG - add switchable DRNG support, Stephan Müller
    • [PATCH v33 02/12] LRNG - allocate one DRNG instance per NUMA node, Stephan Müller
    • [PATCH v33 03/12] LRNG - sysctls and /proc interface, Stephan Müller
      • Re: [PATCH v33 03/12] LRNG - sysctls and /proc interface, kernel test robot
    • [PATCH v33 01/12] Linux Random Number Generator, Stephan Müller
      • Re: [PATCH v33 01/12] Linux Random Number Generator, kernel test robot
        • Re: [PATCH v33 01/12] Linux Random Number Generator, Stephan Müller
      • Re: [PATCH v33 01/12] Linux Random Number Generator, kernel test robot
      • Re: [PATCH v33 01/12] Linux Random Number Generator, kernel test robot
        • Re: [PATCH v33 01/12] Linux Random Number Generator, Stephan Mueller
    • [PATCH v33 06/12] LRNG - add SP800-90A DRBG extension, Stephan Müller
    • [PATCH v34 00/12] /dev/random - a new approach with full SP800-90B compliance, Stephan Müller
      • [PATCH v34 04/12] LRNG - add switchable DRNG support, Stephan Müller
        • Re: [PATCH v34 04/12] LRNG - add switchable DRNG support, kernel test robot
      • [PATCH v34 02/12] LRNG - allocate one DRNG instance per NUMA node, Stephan Müller
      • [PATCH v34 01/12] Linux Random Number Generator, Stephan Müller
        • Re: [PATCH v34 01/12] Linux Random Number Generator, kernel test robot
          • Re: [PATCH v34 01/12] Linux Random Number Generator, Stephan Mueller
        • Re: [PATCH v34 01/12] Linux Random Number Generator, kernel test robot
      • [PATCH v34 11/12] LRNG - add interface for gathering of raw entropy, Stephan Müller
      • [PATCH v34 03/12] LRNG - sysctls and /proc interface, Stephan Müller
      • [PATCH v34 12/12] LRNG - add power-on and runtime self-tests, Stephan Müller
      • [PATCH v34 10/12] LRNG - add SP800-90B compliant health tests, Stephan Müller
      • [PATCH v34 05/12] crypto: DRBG - externalize DRBG functions for LRNG, Stephan Müller
      • [PATCH v34 07/12] LRNG - add kernel crypto API PRNG extension, Stephan Müller
      • [PATCH v34 06/12] LRNG - add SP800-90A DRBG extension, Stephan Müller
      • [PATCH v34 09/12] LRNG - add Jitter RNG fast noise source, Stephan Müller
      • [PATCH v34 08/12] crypto: provide access to a static Jitter RNG state, Stephan Müller
    • [PATCH v35 00/13] /dev/random - a new approach, Stephan Müller
      • [PATCH v35 13/13] LRNG - add power-on and runtime self-tests, Stephan Müller
      • [PATCH v35 09/13] crypto: provide access to a static Jitter RNG state, Stephan Müller
      • [PATCH v35 11/13] LRNG - add SP800-90B compliant health tests, Stephan Müller
      • [PATCH v35 12/13] LRNG - add interface for gathering of raw entropy, Stephan Müller
      • [PATCH v35 10/13] LRNG - add Jitter RNG fast noise source, Stephan Müller
      • [PATCH v35 07/13] LRNG - add SP800-90A DRBG extension, Stephan Müller
      • [PATCH v35 08/13] LRNG - add kernel crypto API PRNG extension, Stephan Müller
      • [PATCH v35 03/13] LRNG - sysctls and /proc interface, Stephan Müller
      • [PATCH v35 05/13] LRNG - add common generic hash support, Stephan Müller
      • [PATCH v35 06/13] crypto: DRBG - externalize DRBG functions for LRNG, Stephan Müller
      • [PATCH v35 04/13] LRNG - add switchable DRNG support, Stephan Müller
      • [PATCH v35 02/13] LRNG - allocate one DRNG instance per NUMA node, Stephan Müller
      • [PATCH v35 01/13] Linux Random Number Generator, Stephan Müller
        • Re: [PATCH v35 01/13] Linux Random Number Generator, kernel test robot
          • Re: [PATCH v35 01/13] Linux Random Number Generator, Stephan Mueller
• [PATCH v9 0/6] ACPI: Support Generic Initiator proximity domains, Jonathan Cameron
  • [PATCH v9 1/6] ACPI: Support Generic Initiator only domains, Jonathan Cameron
  • [PATCH v9 2/6] x86: Support Generic Initiator only proximity domains, Jonathan Cameron
    • Re: [PATCH v9 2/6] x86: Support Generic Initiator only proximity domains, Bjorn Helgaas
      • Re: [PATCH v9 2/6] x86: Support Generic Initiator only proximity domains, Jonathan Cameron
  • [PATCH v9 3/6] ACPI: Let ACPI know we support Generic Initiator Affinity Structures, Jonathan Cameron
  • [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Jonathan Cameron
    • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Bjorn Helgaas
      • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Jonathan Cameron
        • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Bjorn Helgaas
          • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Jonathan Cameron
            • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Bjorn Helgaas
              • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Bjorn Helgaas
                • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Jonathan Cameron
              • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Jonathan Cameron
                • Re: [PATCH v9 4/6] ACPI: HMAT: Fix handling of changes from ACPI 6.2 to ACPI 6.3, Bjorn Helgaas
  • [PATCH v9 5/6] node: Add access1 class to represent CPU to memory characteristics, Jonathan Cameron
  • [PATCH v9 6/6] docs: mm: numaperf.rst Add brief description for access class 1., Jonathan Cameron
• [PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
  • [PATCH v4 1/6] mm: add definition of PMD_PAGE_ORDER, Mike Rapoport
  • [PATCH v4 2/6] mmap: make mlock_future_check() global, Mike Rapoport
  • [PATCH v4 4/6] arch, mm: wire up memfd_secret system call were relevant, Mike Rapoport
  • [PATCH v4 3/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
  • [PATCH v4 5/6] mm: secretmem: use PMD-size pages to amortize direct map fragmentation, Mike Rapoport
  • [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, Mike Rapoport
    • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, David Hildenbrand
      • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, Mike Rapoport
        • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, David Hildenbrand
          • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, Mike Rapoport
            • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, David Hildenbrand
              • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, Mike Rapoport
                • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, David Hildenbrand
                  • Re: [PATCH v4 6/6] mm: secretmem: add ability to reserve memory at boot, Mike Rapoport
  • Re: [PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, David Hildenbrand
    • Re: [PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
      • Re: [PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, David Hildenbrand
  • Re: [PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
  • Re: [PATCH v4 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
• Re: [PATCH v3] mm: introduce reference pages, John Hubbard
  • Re: [PATCH v3] mm: introduce reference pages, Matthew Wilcox
    • Re: [PATCH v3] mm: introduce reference pages, John Hubbard
      • Re: [PATCH v3] mm: introduce reference pages, Peter Collingbourne
  • Re: [PATCH v3] mm: introduce reference pages, Peter Collingbourne
• [PATCH iproute2 v5 0/2] iplink: hsr: add support for creating PRP device, Murali Karicheri
  • [PATCH iproute2 v5 1/2] iplink: hsr: add support for creating PRP device similar to HSR, Murali Karicheri
  • [PATCH iproute2 v5 2/2] ip: iplink: prp: update man page for new parameter, Murali Karicheri
  • Re: [PATCH iproute2 v5 0/2] iplink: hsr: add support for creating PRP device, Murali Karicheri
    • Re: [PATCH iproute2 v5 0/2] iplink: hsr: add support for creating PRP device, Murali Karicheri
  • Re: [PATCH iproute2 v5 0/2] iplink: hsr: add support for creating PRP device, Stephen Hemminger
• [RFC PATCH 0/2] proc,socket: attach description to sockets, Pascal Bouchareine
  • [PATCH 1/2] mm: add GFP mask param to strndup_user, Pascal Bouchareine
    • Re: [PATCH 1/2] mm: add GFP mask param to strndup_user, Al Viro
      • Re: [PATCH 1/2] mm: add GFP mask param to strndup_user, Alexey Dobriyan
  • [PATCH 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
    • Re: [PATCH 2/2] net: socket: implement SO_DESCRIPTION, kernel test robot
    • [RFC PATCH] net: socket: sock_set_description() can be static, kernel test robot
    • Re: [PATCH 2/2] net: socket: implement SO_DESCRIPTION, kernel test robot
    • Re: [PATCH 2/2] net: socket: implement SO_DESCRIPTION, kernel test robot
    • Re: [PATCH 2/2] net: socket: implement SO_DESCRIPTION, Eric Dumazet
      • Re: [PATCH 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
  • [PATCH v2 1/2] mm: add GFP mask param to strndup_user, Pascal Bouchareine
    • [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
      • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, kernel test robot
      • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, David Miller
        • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
          • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
            • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
              • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, David Miller
                • Re: [PATCH v2 2/2] net: socket: implement SO_DESCRIPTION, Pascal Bouchareine
    • Re: [PATCH v2 1/2] mm: add GFP mask param to strndup_user, Andrew Morton
      • Re: [PATCH v2 1/2] mm: add GFP mask param to strndup_user, Pascal Bouchareine
• setsid2(sid) proposal - assign current process to existing session, Devin Bayer
  • Re: setsid2(sid) proposal - assign current process to existing session, Christian Brauner
• [PATCH v4 0/2] proc,fcntl: introduce F_SET_DESCRIPTION, Pascal Bouchareine
  • [PATCH v4 1/2] mm: add GFP mask param to strndup_user, Pascal Bouchareine
  • [PATCH v4 2/2] fcntl: introduce F_SET_DESCRIPTION, Pascal Bouchareine
    • Re: [PATCH v4 2/2] fcntl: introduce F_SET_DESCRIPTION, Christoph Hellwig
      • Re: [PATCH v4 2/2] fcntl: introduce F_SET_DESCRIPTION, Pascal Bouchareine
• Re: INFO: task hung in pipe_release (2), syzbot
• KASAN: use-after-free Read in path_init (2), syzbot
  • [PATCH] Re: KASAN: use-after-free Read in path_init (2), Al Viro
    • Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2), Linus Torvalds
      • Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2), Al Viro
        • Re: [PATCH] Re: KASAN: use-after-free Read in path_init (2), Linus Torvalds
  • Re: KASAN: use-after-free Read in path_init (2), syzbot
• [PATCH v5 0/9] Syscall User Dispatch, Gabriel Krisman Bertazi
  • [PATCH v5 1/9] kernel: Support TIF_SYSCALL_INTERCEPT flag, Gabriel Krisman Bertazi
  • [PATCH v5 2/9] kernel: entry: Support TIF_SYSCAL_INTERCEPT on common entry code, Gabriel Krisman Bertazi
  • [PATCH v5 3/9] x86: vdso: Expose sigreturn address on vdso to the kernel, Gabriel Krisman Bertazi
    • Re: [PATCH v5 3/9] x86: vdso: Expose sigreturn address on vdso to the kernel, Andy Lutomirski
  • [PATCH v5 4/9] signal: Expose SYS_USER_DISPATCH si_code type, Gabriel Krisman Bertazi
  • [PATCH v5 5/9] kernel: Implement selective syscall userspace redirection, Gabriel Krisman Bertazi
  • [PATCH v5 7/9] x86: Enable Syscall User Dispatch, Gabriel Krisman Bertazi
  • [PATCH v5 8/9] selftests: Add kselftest for syscall user dispatch, Gabriel Krisman Bertazi
  • [PATCH v5 9/9] doc: Document Syscall User Dispatch, Gabriel Krisman Bertazi
  • [PATCH v5 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry, Gabriel Krisman Bertazi
• [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Eugene Lubarsky
  • [RFC PATCH 1/5] fs/proc: Introduce /proc/all/stat, Eugene Lubarsky
  • [RFC PATCH 5/5] fs/proc: Introduce /proc/all/statx, Eugene Lubarsky
  • [RFC PATCH 3/5] fs/proc: Introduce /proc/all/status, Eugene Lubarsky
  • [RFC PATCH 2/5] fs/proc: Introduce /proc/all/statm, Eugene Lubarsky
  • [RFC PATCH 4/5] fs/proc: Introduce /proc/all/io, Eugene Lubarsky
  • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Greg KH
    • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Eugene Lubarsky
      • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Greg KH
        • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Eugene Lubarsky
  • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Andrei Vagin
    • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, David Ahern
      • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Andrei Vagin
    • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Eugene Lubarsky
      • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Andrei Vagin
        • Re: [RFC PATCH 0/5] Introduce /proc/all/ to gather stats from all processes, Eugene Lubarsky
• [PATCH v3] fcntl: Add 32bit filesystem mode, Linus Walleij
• [PATCH 1/2] Add a manpage for watch_queue(7), David Howells
  • [PATCH 2/2] Modify the pipe(2) manpage for notification queues, David Howells
  • Re: [PATCH 1/2] Add a manpage for watch_queue(7), Ben Boeckel
  • Re: [PATCH 1/2] Add a manpage for watch_queue(7), David Howells
    • Re: [PATCH 1/2] Add a manpage for watch_queue(7), Ben Boeckel
    • Re: [PATCH 1/2] Add a manpage for watch_queue(7), David Howells
  • <Possible follow-ups>
  • [PATCH 1/2] Add a manpage for watch_queue(7), David Howells
    • [PATCH 2/2] Modify the pipe(2) manpage for notification queues, David Howells
    • Re: [PATCH 1/2] Add a manpage for watch_queue(7), Michael Kerrisk (man-pages)
• [PATCH 1/5] Add manpage for open_tree(2), David Howells
  • [PATCH 2/5] Add manpages for move_mount(2) and open_tree(2), David Howells
    • Re: [PATCH 2/5] Add manpages for move_mount(2) and open_tree(2), Michael Kerrisk (man-pages)
    • Re: [PATCH 2/5] Add manpages for move_mount(2) and open_tree(2), David Howells
      • Re: [PATCH 2/5] Add manpages for move_mount(2) and open_tree(2), Michael Kerrisk (man-pages)
  • [PATCH 3/5] Add manpage for fspick(2), David Howells
    • Re: [PATCH 3/5] Add manpage for fspick(2), Michael Kerrisk (man-pages)
  • [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), David Howells
    • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
  • [PATCH 5/5] Add manpage for fsconfig(2), David Howells
    • AW: [PATCH 5/5] Add manpage for fsconfig(2), Walter Harms
    • Re: AW: [PATCH 5/5] Add manpage for fsconfig(2), David Howells
      • AW: AW: [PATCH 5/5] Add manpage for fsconfig(2), Walter Harms
    • Re: [PATCH 5/5] Add manpage for fsconfig(2), Michael Kerrisk (man-pages)
  • Re: [PATCH 1/5] Add manpage for open_tree(2), Michael Kerrisk (man-pages)
  • <Possible follow-ups>
  • [PATCH 1/5] Add manpage for open_tree(2), David Howells
    • [PATCH 2/5] Add manpages for move_mount(2), David Howells
      • Re: [PATCH 2/5] Add manpages for move_mount(2), Michael Kerrisk (man-pages)
        • Re: [PATCH 2/5] Add manpages for move_mount(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 2/5] Add manpages for move_mount(2), Michael Kerrisk (man-pages)
    • [PATCH 5/5] Add manpage for fsconfig(2), David Howells
      • Re: [PATCH 5/5] Add manpage for fsconfig(2), Michael Kerrisk (man-pages)
        • Re: [PATCH 5/5] Add manpage for fsconfig(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 5/5] Add manpage for fsconfig(2), Michael Kerrisk (man-pages)
    • [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), David Howells
      • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
        • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), David Howells
        • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
          • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
            • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
              • Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2), Michael Kerrisk (man-pages)
    • [PATCH 3/5] Add manpage for fspick(2), David Howells
      • Re: [PATCH 3/5] Add manpage for fspick(2), Michael Kerrisk (man-pages)
        • Re: [PATCH 3/5] Add manpage for fspick(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 3/5] Add manpage for fspick(2), Michael Kerrisk (man-pages)
    • Re: [PATCH 1/5] Add manpage for open_tree(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 1/5] Add manpage for open_tree(2), Michael Kerrisk (man-pages)
      • Re: [PATCH 1/5] Add manpage for open_tree(2), Michael Kerrisk (man-pages)
    • Re: [PATCH 1/5] Add manpage for open_tree(2), Aurélien Aptel
• [net-next iproute2 PATCH v4 0/2] iplink: hsr: add support for creating PRP device, Murali Karicheri
  • [net-next iproute2 PATCH v4 1/2] iplink: hsr: add support for creating PRP device similar to HSR, Murali Karicheri
    • Re: [net-next iproute2 PATCH v4 1/2] iplink: hsr: add support for creating PRP device similar to HSR, Stephen Hemminger
      • Re: [net-next iproute2 PATCH v4 1/2] iplink: hsr: add support for creating PRP device similar to HSR, Murali Karicheri
  • [net-next iproute2 PATCH v4 2/2] ip: iplink: prp: update man page for new parameter, Murali Karicheri
  • Re: [net-next iproute2 PATCH v4 0/2] iplink: hsr: add support for creating PRP device, Murali Karicheri
• [LTP-FAIL][02/21] fs: refactor ksys_umount, Vikas Kumar
  • Re: [LTP-FAIL][02/21] fs: refactor ksys_umount, Christoph Hellwig
    • Re: [LTP-FAIL][02/21] fs: refactor ksys_umount, Al Viro
      • Re: [LTP-FAIL][02/21] fs: refactor ksys_umount, Christoph Hellwig
• [PATCH v3 0/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
  • [PATCH v3 1/6] mm: add definition of PMD_PAGE_ORDER, Mike Rapoport
    • Re: [PATCH v3 1/6] mm: add definition of PMD_PAGE_ORDER, Kirill A. Shutemov
      • Re: [PATCH v3 1/6] mm: add definition of PMD_PAGE_ORDER, Mike Rapoport
  • [PATCH v3 2/6] mmap: make mlock_future_check() global, Mike Rapoport
  • [PATCH v3 3/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
    • Re: [PATCH v3 3/6] mm: introduce memfd_secret system call to create "secret" memory areas, Randy Dunlap
      • Re: [PATCH v3 3/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
    • Re: [PATCH v3 3/6] mm: introduce memfd_secret system call to create "secret" memory areas, Kirill A. Shutemov
      • Re: [PATCH v3 3/6] mm: introduce memfd_secret system call to create "secret" memory areas, Mike Rapoport
  • [PATCH v3 4/6] arch, mm: wire up memfd_secret system call were relevant, Mike Rapoport
  • [PATCH v3 5/6] mm: secretmem: use PMD-size pages to amortize direct map fragmentation, Mike Rapoport
  • [PATCH v3 6/6] mm: secretmem: add ability to reserve memory at boot, Mike Rapoport
• [GIT PULL] Mount notifications, David Howells
  • [GIT PULL] Filesystem Information, David Howells
    • Re: [GIT PULL] Filesystem Information, Miklos Szeredi
      • Re: [GIT PULL] Filesystem Information, Ian Kent
        • Re: [GIT PULL] Filesystem Information, Miklos Szeredi
          • Re: [GIT PULL] Filesystem Information, Ian Kent
            • Re: [GIT PULL] Filesystem Information, Miklos Szeredi
              • Re: [GIT PULL] Filesystem Information, Ian Kent
          • file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
            • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
              • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                    • Message not available
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                        • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
              • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Linus Torvalds
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Linus Torvalds
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Lennart Poettering
                        • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Christian Brauner
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Christian Brauner
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Ian Kent
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Andy Lutomirski
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Casey Schaufler
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Linus Torvalds
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Jann Horn
                        • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                          • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Andy Lutomirski
                          • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Linus Torvalds
                            • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                              • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), David Howells
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                      • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Casey Schaufler
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Linus Torvalds
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Al Viro
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Karel Zak
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), David Howells
                    • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
              • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), David Howells
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), David Howells
                  • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Miklos Szeredi
                    • Re: file metadata via fs API, Steven Whitehouse
                      • Re: file metadata via fs API, Miklos Szeredi
                        • Re: file metadata via fs API, Karel Zak
                          • Re: file metadata via fs API, Miklos Szeredi
                            • Re: file metadata via fs API, Karel Zak
                          • Re: file metadata via fs API, David Howells
                            • Re: file metadata via fs API, Ian Kent
                • Re: file metadata via fs API (was: [GIT PULL] Filesystem Information), Linus Torvalds
                  • Re: file metadata via fs API, Steven Whitehouse
                    • Re: file metadata via fs API, Linus Torvalds
                      • Re: file metadata via fs API, Ian Kent