Linux Arch

• Thread Index

• [PATCH 0/8] 5-level paging enabling for v4.14
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 2/8] x86/dump_pagetables: Fix printout of p4d level
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 1/8] x86/dump_pagetables: Generalize address normalization
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 4/8] x86/mm: Rename tasksize_32bit/64bit to task_size_32bit/64bit
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 5/8] x86/mpx: Do not allow MPX if we have mappings above 47-bit
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 7/8] x86/mm: Allow userspace have mapping above 47-bit
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 6/8] x86/mm: Prepare to expose larger address space to userspace
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 8/8] x86: Enable 5-level paging support
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [PATCH 3/8] x86/xen: Redefine XEN_ELFNOTE_INIT_P2M using PUD_SIZE * PTRS_PER_PUD
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• [RFC v6 01/62] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 03/62] powerpc: introduce pte_set_hash_slot() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 02/62] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 04/62] powerpc: introduce pte_get_hash_gslot() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 05/62] powerpc: capture the PTE format changes in the dump pte report
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 07/62] powerpc: use helper functions in __hash_page_huge() for 64K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 08/62] powerpc: use helper functions in __hash_page_4K() for 64K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 06/62] powerpc: use helper functions in __hash_page_64K() for 64K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 09/62] powerpc: use helper functions in __hash_page_4K() for 4K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 10/62] powerpc: use helper functions in flush_hash_page()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 12/62] mm: introduce an additional vma bit for powerpc pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 11/62] powerpc: initial pkey plumbing
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 14/62] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 13/62] powerpc: track allocation status of all pkeys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 16/62] powerpc: cleaup AMR,iAMR when a key is allocated or freed
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 18/62] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 17/62] powerpc: implementation for arch_set_user_pkey_access()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 20/62] powerpc: store and restore the pkey state across context switches
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 19/62] powerpc: ability to create execute-disabled pkeys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 21/62] powerpc: introduce execute-only pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 23/62] powerpc: implementation for arch_override_mprotect_pkey()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 25/62] powerpc: sys_pkey_mprotect() system call
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 24/62] powerpc: map vma key-protection bits to pte key bits.
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 26/62] powerpc: Program HPTE key protection bits
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 28/62] powerpc: check key protection for user page access
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 30/62] powerpc: implementation for arch_vma_access_permitted()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 29/62] powerpc: Macro the mask used for checking DSI exception
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 31/62] powerpc: Handle exceptions caused by pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 32/62] powerpc: capture AMR register content on pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 34/62] powerpc: capture the violated protection key on fault
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 33/62] powerpc: introduce get_pte_pkey() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 37/62] x86: implementation for arch_pkeys_enabled()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 38/62] powerpc: implementation for arch_pkeys_enabled()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 39/62] mm: display pkey in smaps if arch_pkeys_enabled() is true
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 36/62] mm: introduce arch_pkeys_enabled()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 35/62] powerpc: Deliver SEGV signal on pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 40/62] x86: delete arch_show_smap()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 41/62] selftest/x86: Move protecton key selftest to arch neutral directory
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 44/62] selftest/vm: typecast the pkey register
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 42/62] selftest/vm: rename all references to pkru to a generic name
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 43/62] selftest/vm: move generic definitions to header file
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 45/62] selftest/vm: generics function to handle shadow key register
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 46/62] selftest/vm: fix the wrong assert in pkey_disable_set()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 48/62] selftest/vm: clear the bits in shadow reg when a pkey is freed.
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 47/62] selftest/vm: fixed bugs in pkey_disable_clear()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 50/62] selftest/vm: introduce two arch independent abstraction
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 49/62] selftest/vm: fix alloc_random_pkey() to make it really random
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 52/62] selftest/vm: generic cleanup
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 55/62] selftest/vm: associate key on a mapped page and detect access violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 54/62] selftest/vm: fix an assertion in test_pkey_alloc_exhaust()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 57/62] selftest/vm: associate key on a mapped page and detect write violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 56/62] selftest/vm: detect no key violation on a freed key
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 58/62] selftest/vm: detect no write key-violation on a freed key
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 59/62] selftest/vm: detect write violation on a mapped access-denied-key page
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 60/62] selftest/vm: sub-page allocator
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 62/62] Documentation/vm: PowerPC specific updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 61/62] Documentation/x86: Move protecton key documentation to arch neutral directory
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 53/62] selftest/vm: powerpc implementation for generic abstraction
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 51/62] selftest/vm: pkey register should match shadow pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 22/62] powerpc: ability to associate pkey to a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 15/62] powerpc: helper functions to initialize AMR, IAMR and UMOR registers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v6 00/62] powerpc: Memory Protection Keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• semantics of dma_map_single()
  • From: Vineet Gupta <Vineet.Gupta1@xxxxxxxxxxxx>
• Re: [PATCH 1/8] signal/alpha: Document a conflict with SI_USER for SIGTRAP
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 14/38] powerpc: initial plumbing for key management
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v5 14/38] powerpc: initial plumbing for key management
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
• Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 14/38] powerpc: initial plumbing for key management
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 8/8] signal: Remove kernel interal si_code magic
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 8/8] signal: Remove kernel interal si_code magic
  • From: Andrei Vagin <avagin@xxxxxxxxxxxxx>
• Re: [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal
  • From: James Morse <james.morse@xxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v5 14/38] powerpc: initial plumbing for key management
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 13/38] x86: disallow pkey creation with PKEY_DISABLE_EXECUTE
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [RFC v5 36/38] selftest: PowerPC specific test updates to memory protection keys
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
• Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [PATCH 0/2] Fatal signal handing within uaccess faults
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH 0/2] Fatal signal handing within uaccess faults
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Aleksa Sarai <asarai@xxxxxxx>
• RE: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: David Laight <David.Laight@xxxxxxxxxx>
• [PATCH 2/2] arm: mm: abort uaccess retries upon fatal signal
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [PATCH 0/2] Fatal signal handing within uaccess faults
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH 0/2] Fatal signal handing within uaccess faults
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [PATCH 2/2] arm: mm: abort uaccess retries upon fatal signal
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• [PATCH 0/2] Fatal signal handing within uaccess faults
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH v2 18/28] nios2: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Tobias Klauser <tklauser@xxxxxxxxxx>
• Re: [PATCH v2 17/28] nios2: remove unneeded arch/nios2/include/(generated/)asm/signal.h
  • From: Tobias Klauser <tklauser@xxxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Aleksa Sarai <asarai@xxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Gleb Fotengauer-Malinovskiy <glebfm@xxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [patches] [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH v2 19/28] openrisc: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Stafford Horne <shorne@xxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH v9 00/38] x86: Secure Memory Encryption (AMD)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
• Re: KASAN vs. boot-time switching between 4- and 5-level paging
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH v2 00/28] kbuild: complete UAPI de-coupling and cleanup scripts/Makefile.headersinst
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: [PATCH v2 00/28] kbuild: complete UAPI de-coupling and cleanup scripts/Makefile.headersinst
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 32/38] powerpc: capture the violated protection key on fault
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 33/38] powerpc: Deliver SEGV signal on pkey violation
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 32/38] powerpc: capture the violated protection key on fault
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys
  • From: Anshuman Khandual <khandual@xxxxxxxxxxxxxxxxxx>
• Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• [PATCH v2 12/28] ia64: remove redundant generic-y += kvm_para.h from asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 07/28] blackfin: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 01/28] kbuild: remove useless $(gen) variable in Makefile.headersinst
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 05/28] ARM: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 06/28] arc: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 13/28] m32r: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 03/28] kbuild: pass dst= to Makefile.headersinst from top Makefile
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 09/28] cris: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 04/28] arm64: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 00/28] kbuild: complete UAPI de-coupling and cleanup scripts/Makefile.headersinst
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 11/28] hexagon: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 08/28] c6x: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 10/28] h8300: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 21/28] sh: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 16/28] microblaze: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 17/28] nios2: remove unneeded arch/nios2/include/(generated/)asm/signal.h
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 20/28] parisc: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 26/28] kbuild: do not include old-kbuild-file from Makefile.headersinst
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 18/28] nios2: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 22/28] sparc: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 24/28] unicore32: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 15/28] metag: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 25/28] xtensa: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 23/28] tile: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 28/28] kbuild: remove wrapper files handling from Makefile.headersinst
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 27/28] kbuild: split exported generic header creation into uapi-asm-generic
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 19/28] openrisc: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 14/28] m68k: move generic-y of exported headers to uapi/asm/Kbuild
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• [PATCH v2 02/28] kbuild: fix comment about dst of headers_{install,check}_all
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [RFC PATCH] x86: enable dead code and data elimination (LTO)
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v9 00/38] x86: Secure Memory Encryption (AMD)
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH v3 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 3/9] sched: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 6/9] ipc: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 8/9] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 2/9] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 5/9] exit: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 7/9] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 9/9] arch: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v3 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v9 00/38] x86: Secure Memory Encryption (AMD)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 01/38] x86: Document AMD Secure Memory Encryption (SME)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 02/38] x86/mm/pat: Set write-protect cache mode for full PAT support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 05/38] x86/CPU/AMD: Handle SME reduction in physical address size
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 08/38] x86/mm: Add support to enable SME in early boot processing
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 06/38] x86/mm: Add Secure Memory Encryption (SME) support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 11/38] x86/mm: Add SME support for read_cr3_pa()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 10/38] x86/mm: Provide general kernel support for memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 15/38] x86/boot/e820: Add support to determine the E820 type of an address
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 14/38] x86/mm: Insure that boot memory areas are mapped properly
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 19/38] x86/mm: Add support to access boot related data in the clear
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 17/38] efi: Update efi_mem_type() to return an error rather than 0
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 22/38] x86/mm: Add support for changing the memory encryption attribute
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 21/38] x86/mm: Add support to access persistent memory in the clear
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 20/38] x86, mpparse: Use memremap to map the mpf and mpc data
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 26/38] x86/CPU/AMD: Make the microcode level available earlier in the boot
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 24/38] x86, swiotlb: Add memory encryption support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 30/38] kvm: x86: svm: Support Secure Memory Encryption within KVM
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 28/38] x86, realmode: Check for memory encryption on the APs
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 33/38] x86/mm: Use proper encryption attributes with /dev/mem
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 31/38] x86/mm, kexec: Allow kexec to be used with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 29/38] x86, drm, fbdev: Do not specify encrypted memory for video mappings
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 36/38] x86/boot: Add early cmdline parsing for options with arguments
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 35/38] x86/mm: Add support to encrypt the kernel in-place
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 38/38] x86/mm: Add support to make use of Secure Memory Encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 37/38] compiler-gcc.h: Introduce __nostackp function attribute
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 34/38] x86/mm: Create native_make_p4d() for PGTABLE_LEVELS <= 4
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 32/38] xen/x86: Remove SME feature in PV guests
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 25/38] swiotlb: Add warnings for use of bounce buffers with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 23/38] x86/realmode: Decrypt trampoline area if memory encryption is active
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 18/38] x86/efi: Update EFI pagetable creation to work with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 16/38] efi: Add an EFI table address match function
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 13/38] x86/mm: Add support for early encrypt/decrypt of memory
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 12/38] x86/mm: Extend early_memremap() support with additional attrs
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v9 09/38] x86/mm: Simplify p[g4um]d_page() macros
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [patches] [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [RFC v5 01/38] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH v2 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock()
  • From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Dave P Martin <Dave.Martin@xxxxxxx>
• Re: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• RE: [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [PATCH 2/7] rwsem-spinlock: Add killable versions of rwsem_down_read_failed()
  • From: Kirill Tkhai <ktkhai@xxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 2/7] rwsem-spinlock: Add killable versions of rwsem_down_read_failed()
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 8/9] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 9/9] arch: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 7/9] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 4/9] completion: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 5/9] exit: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 1/9] net/netfilter/nf_conntrack_core: Fix net_conntrack_lock()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 6/9] ipc: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 3/9] sched: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 2/9] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH v2 0/9] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [RFC v5 00/38] powerpc: Memory Protection Keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 01/38] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 02/38] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 03/38] powerpc: introduce pte_set_hash_slot() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 05/38] powerpc: capture the PTE format changes in the dump pte report
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 10/38] powerpc: use helper functions in flush_hash_page()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 08/38] powerpc: use helper functions in __hash_page_4K() for 64K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 07/38] powerpc: use helper functions in __hash_page_huge() for 64K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 06/38] powerpc: use helper functions in __hash_page_64K() for 64K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 13/38] x86: disallow pkey creation with PKEY_DISABLE_EXECUTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 09/38] powerpc: use helper functions in __hash_page_4K() for 4K PTE
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 15/38] powerpc: helper function to read,write AMR,IAMR,UAMOR registers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 17/38] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 11/38] mm: introduce an additional vma bit for powerpc pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 14/38] powerpc: initial plumbing for key management
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 18/38] powerpc: store and restore the pkey state across context switches
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 16/38] powerpc: implementation for arch_set_user_pkey_access()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 22/38] powerpc: map vma key-protection bits to pte key bits.
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 21/38] powerpc: implementation for arch_override_mprotect_pkey()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 19/38] powerpc: introduce execute-only pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 23/38] powerpc: sys_pkey_mprotect() system call
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 20/38] powerpc: ability to associate pkey to a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 24/38] powerpc: Program HPTE key protection bits
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 25/38] powerpc: helper to validate key-access permissions of a pte
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 27/38] powerpc: Macro the mask used for checking DSI exception
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 26/38] powerpc: check key protection for user page access
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 29/38] powerpc: Handle exceptions caused by pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 33/38] powerpc: Deliver SEGV signal on pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 31/38] powerpc: introduce get_pte_pkey() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 28/38] powerpc: implementation for arch_vma_access_permitted()
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 36/38] selftest: PowerPC specific test updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 32/38] powerpc: capture the violated protection key on fault
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 34/38] procfs: display the protection-key number associated with a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 37/38] Documentation: Move protecton key documentation to arch neutral directory
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 38/38] Documentation: PowerPC specific updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 35/38] selftest: Move protecton key selftest to arch neutral directory
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 30/38] powerpc: capture AMR register content on pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 12/38] mm: ability to disable execute permission on a key at creation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v5 04/38] powerpc: introduce pte_get_hash_gslot() helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [patches] Re: [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Jonathan Neuschäfer <j.neuschaefer@xxxxxxx>
• Re: [patches] Re: [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Karsten Merker <merker@xxxxxxxxxx>
• [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 4/9] RISC-V: ELF and module implementation
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 7/9] RISC-V: Paging and MMU
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 9/9] RISC-V: Build Infastructure
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 3/9] RISC-V: Generic library routines and assembly
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 5/9] RISC-V: Task implementation
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• RISC-V Linux Port v4
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 1/1] futex: remove duplicated code and fix UB
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [PATCH 1/8] signal/alpha: Document a conflict with SI_USER for SIGTRAP
  • From: Helge Deller <deller@xxxxxx>
• Re: [v2] spin loop primitives for busy waiting
  • From: Michael Ellerman <patch-notifications@xxxxxxxxxxxxxx>
• Re: [PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [PATCH RFC 06/26] ipc: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 06/26] ipc: Replace spin_unlock_wait() with lock/unlock pair
  • From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH RFC 12/26] arm64: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3 4/4] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 5/8] signal/testing: Don't look for __SI_FAULT in userspace
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 8/8] signal: Remove kernel interal si_code magic
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 6/8] signal/x86: Fix SIGSYS handling in copy_siginfo_to_user32
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 7/8] fcntl: Don't use ambiguous SIG_POLL si_codes
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 4/8] signal/mips: Document a conflict with SI_USER with SIGFPE
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 2/8] signal/ia64: Document a conflict with SI_USER with SIGFPE
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 1/8] signal/alpha: Document a conflict with SI_USER for SIGTRAP
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• [PATCH 0/8] signal: Fix sending signals with siginfo
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: [PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH RFC 12/26] arm64: Remove spin_unlock_wait() arch-specific definitions
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI
  • From: Tobias Klauser <tklauser@xxxxxxxxxx>
• Re: [PATCH 0/5] Last bits for initial 5-level paging enabling
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [PATCH v3 4/4] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Horia Geantă <horia.geanta@xxxxxxx>
• Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection
  • From: Li Kun <hw.likun@xxxxxxxxxx>
• Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 02/26] task_work: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 12/26] arm64: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 10/26] arc: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 11/26] arm: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 08/26] locking: Remove spin_unlock_wait() generic definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 05/26] exit: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 03/26] sched: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 07/26] drivers/ata: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 21/26] powerpc: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• [PATCH RFC 24/26] sparc: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 01/26] netfilter: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 17/26] metag: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 26/26] xtensa: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 19/26] mn10300: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 18/26] mips: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 06/26] ipc: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 13/26] blackfin: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 14/26] hexagon: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 04/26] completion: Replace spin_unlock_wait() with lock/unlock pair
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 20/26] parisc: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 09/26] alpha: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 23/26] sh: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 22/26] s390: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 25/26] tile: Remove spin_unlock_wait() arch-specific definitions
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH RFC 0/26] Remove spin_unlock_wait()
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 5/9] RISC-V: Task implementation
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 5/9] RISC-V: Task implementation
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 9/9] RISC-V: Build Infastructure
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 7/9] RISC-V: Paging and MMU
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 9/9] RISC-V: Build Infastructure
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH v3 1/4] iomap: introduce io{read|write}64_{lo_hi|hi_lo}
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v3 0/4] make io{read|write}64 more globally usable
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v3 2/4] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v3 4/4] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v3 3/4] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH 0/5] Last bits for initial 5-level paging enabling
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI
  • From: Tobias Klauser <tklauser@xxxxxxxxxx>
• Re: [PATCH 5/9] RISC-V: Task implementation
  • From: Tobias Klauser <tklauser@xxxxxxxxxx>
• Re: [PATCH v2 3/3] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Horia Geantă <horia.geanta@xxxxxxx>
• Re: [kernel-hardening] [PATCH v5 3/3] x86/refcount: Implement fast refcount overflow protection
  • From: Li Kun <hw.likun@xxxxxxxxxx>
• Re: [PATCH 5/9] RISC-V: Task implementation
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH] arch: remove unused macro/function thread_saved_pc()
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 7/9] RISC-V: Paging and MMU
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH 9/9] RISC-V: Build Infastructure
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [PATCH 8/9] RISC-V: User-facing API
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: [PATCH 9/9] RISC-V: Build Infastructure
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH 9/9] RISC-V: Build Infastructure
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 9/9] RISC-V: Build Infastructure
  • From: Karsten Merker <merker@xxxxxxxxxx>
• [PATCH 7/9] RISC-V: Paging and MMU
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 9/9] RISC-V: Build Infastructure
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 8/9] RISC-V: User-facing API
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 2/9] RISC-V: Atomic and Locking Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 3/9] RISC-V: Generic library routines and assembly
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 4/9] RISC-V: ELF and module implementation
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 5/9] RISC-V: Task implementation
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 6/9] RISC-V: Device, timer, IRQs, and the SBI
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [PATCH 1/9] RISC-V: Init and Halt Code
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• RISC-V Linux Port v3
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• [tip:locking/core] locking/refcount: Create unchecked atomic_t implementation
  • From: tip-bot for Kees Cook <tipbot@xxxxxxxxx>
• Re: [PATCH v2 3/3] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH 6/5] x86/KASLR: Fix detection 32/64 bit bootloaders for 5-level paging
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v2 1/3] io-64-nonatomic: add io{read|write}64[be] macros
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH v3 4/4] misc: sram: Allow ARM64 to select SRAM_EXEC
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [PATCH] arch: remove unused macro/function thread_saved_pc()
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v8 RESEND 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH] arch: remove unused macro/function thread_saved_pc()
  • From: Tobias Klauser <tklauser@xxxxxxxxxx>
• [PATCH 6/5] x86/KASLR: Fix detection 32/64 bit bootloaders for 5-level paging
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/3] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH v2 1/3] io-64-nonatomic: add io{read|write}64[be] macros
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH v8 RESEND 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption
  • From: Joerg Roedel <joro@xxxxxxxxxx>
• Re: [RFC v4 09/17] powerpc: call the hash functions with the correct pkey value
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH v2] spin loop primitives for busy waiting
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [RFC v4 17/17] procfs: display the protection-key number associated with a vma
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• [PATCH v2 3/3] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v2 1/3] io-64-nonatomic: add io{read|write}64[be] macros
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v2 2/3] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• [PATCH v2 0/3] make io{read|write}64 more globally usable
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 1/5] kbuild: thin archives final link close --whole-archives option
  • From: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
• [PATCH v8 RESEND 38/38] x86/mm: Add support to make use of Secure Memory Encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 32/38] xen/x86: Remove SME feature in PV guests
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 34/38] x86/mm: Create native_make_p4d() for PGTABLE_LEVELS <= 4
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 35/38] x86/mm: Add support to encrypt the kernel in-place
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 36/38] x86/boot: Add early cmdline parsing for options with arguments
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 37/38] compiler-gcc.h: Introduce __nostackp function attribute
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [RFC v4 09/17] powerpc: call the hash functions with the correct pkey value
  • From: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
• [PATCH v8 RESEND 33/38] x86/mm: Use proper encryption attributes with /dev/mem
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 31/38] x86/mm, kexec: Allow kexec to be used with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 30/38] kvm: x86: svm: Support Secure Memory Encryption within KVM
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 29/38] x86, drm, fbdev: Do not specify encrypted memory for video mappings
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 28/38] x86, realmode: Check for memory encryption on the APs
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 23/38] x86/realmode: Decrypt trampoline area if memory encryption is active
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 21/38] x86/mm: Add support to access persistent memory in the clear
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 25/38] swiotlb: Add warnings for use of bounce buffers with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 26/38] x86/CPU/AMD: Make the microcode level available earlier in the boot
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 27/38] iommu/amd: Allow the AMD IOMMU to work with memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 28/38] x86, realmode: Check for memory encryption on the APs
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 29/38] x86, drm, fbdev: Do not specify encrypted memory for video mappings
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 30/38] kvm: x86: svm: Support Secure Memory Encryption within KVM
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 26/38] x86/CPU/AMD: Make the microcode level available earlier in the boot
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 24/38] x86, swiotlb: Add memory encryption support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 25/38] swiotlb: Add warnings for use of bounce buffers with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 06/38] x86/mm: Add Secure Memory Encryption (SME) support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 08/38] x86/mm: Add support to enable SME in early boot processing
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 09/38] x86/mm: Simplify p[g4um]d_page() macros
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 21/38] x86/mm: Add support to access persistent memory in the clear
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 23/38] x86/realmode: Decrypt trampoline area if memory encryption is active
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 12/38] x86/mm: Extend early_memremap() support with additional attrs
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 22/38] x86/mm: Add support for changing the memory encryption attribute
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 13/38] x86/mm: Add support for early encrypt/decrypt of memory
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 14/38] x86/mm: Insure that boot memory areas are mapped properly
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 15/38] x86/boot/e820: Add support to determine the E820 type of an address
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 19/38] x86/mm: Add support to access boot related data in the clear
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 01/38] x86: Document AMD Secure Memory Encryption (SME)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 20/38] x86, mpparse: Use memremap to map the mpf and mpc data
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 17/38] efi: Update efi_mem_type() to return an error rather than 0
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 18/38] x86/efi: Update EFI pagetable creation to work with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 16/38] efi: Add an EFI table address match function
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 11/38] x86/mm: Add SME support for read_cr3_pa()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 10/38] x86/mm: Provide general kernel support for memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 05/38] x86/CPU/AMD: Handle SME reduction in physical address size
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 00/38] x86: Secure Memory Encryption (AMD)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 02/38] x86/mm/pat: Set write-protect cache mode for full PAT support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 RESEND 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 24/38] x86, swiotlb: Add memory encryption support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 22/38] x86/mm: Add support for changing the memory encryption attribute
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 20/38] x86, mpparse: Use memremap to map the mpf and mpc data
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 16/38] efi: Add an EFI table address match function
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 19/38] x86/mm: Add support to access boot related data in the clear
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 18/38] x86/efi: Update EFI pagetable creation to work with SME
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 17/38] efi: Update efi_mem_type() to return an error rather than 0
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 10/38] x86/mm: Provide general kernel support for memory encryption
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 11/38] x86/mm: Add SME support for read_cr3_pa()
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 12/38] x86/mm: Extend early_memremap() support with additional attrs
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 13/38] x86/mm: Add support for early encrypt/decrypt of memory
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 15/38] x86/boot/e820: Add support to determine the E820 type of an address
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 00/38] x86: Secure Memory Encryption (AMD)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 14/38] x86/mm: Insure that boot memory areas are mapped properly
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 08/38] x86/mm: Add support to enable SME in early boot processing
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 09/38] x86/mm: Simplify p[g4um]d_page() macros
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 06/38] x86/mm: Add Secure Memory Encryption (SME) support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 02/38] x86/mm/pat: Set write-protect cache mode for full PAT support
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 05/38] x86/CPU/AMD: Handle SME reduction in physical address size
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 01/38] x86: Document AMD Secure Memory Encryption (SME)
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• [PATCH v8 03/38] x86, mpparse, x86/acpi, x86/PCI, x86/dmi, SFI: Use memremap for RAM mappings
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [RFC v4 02/17] mm: ability to disable execute permission on a key at creation
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v4 03/17] x86: key creation with PKEY_DISABLE_EXECUTE disallowed
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v4 01/17] mm: introduce an additional vma bit for powerpc pkey
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [RFC v4 00/17] powerpc: Memory Protection Keys
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• [RFC v4 01/17] mm: introduce an additional vma bit for powerpc pkey
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 02/17] mm: ability to disable execute permission on a key at creation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 07/17] powerpc: make the hash functions protection-key aware
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 04/17] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 06/17] powerpc: Implementation for sys_mprotect_pkey() system call
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 05/17] powerpc: store and restore the pkey state across context switches
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 09/17] powerpc: call the hash functions with the correct pkey value
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 12/17] powerpc: Deliver SEGV signal on pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 10/17] powerpc: Macro the mask used for checking DSI exception
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 08/17] powerpc: Program HPTE key protection bits
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 03/17] x86: key creation with PKEY_DISABLE_EXECUTE disallowed
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 11/17] powerpc: Handle exceptions caused by pkey violation
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 13/17] selftest: Move protecton key selftest to arch neutral directory
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 15/17] Documentation: Move protecton key documentation to arch neutral directory
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 14/17] selftest: PowerPC specific test updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 17/17] procfs: display the protection-key number associated with a vma
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 16/17] Documentation: PowerPC specific updates to memory protection keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• [RFC v4 00/17] powerpc: Memory Protection Keys
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH 13/17] RISC-V: Add include subdirectory
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 10/17] irqchip: New RISC-V PLIC Driver
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 09/17] clocksource/timer-riscv: New RISC-V Clocksource
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• RE: [PATCH 13/17] RISC-V: Add include subdirectory
  • From: Daniel Lustig <dlustig@xxxxxxxxxx>
• Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: [PATCH 13/17] RISC-V: Add include subdirectory
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 13/17] RISC-V: Add include subdirectory
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 13/17] RISC-V: Add include subdirectory
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [RFC PATCH] arm64: signal: Make parse_user_sigframe() independent of rt_sigframe layout
  • From: Dave Martin <Dave.Martin@xxxxxxx>
• Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place
  • From: Tom Lendacky <thomas.lendacky@xxxxxxx>
• Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64
  • From: Logan Gunthorpe <logang@xxxxxxxxxxxx>
• Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [RFC PATCH] arm64: signal: Make parse_user_sigframe() independent of rt_sigframe layout
  • From: Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH 3/4] powerpc: Reduce ELF_ET_DYN_BASE
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [PATCH 1/1] futex: remove duplicated code and fix UB
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [PATCH 1/1] futex: remove duplicated code and fix UB
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: [RFC PATCH] arm64: signal: Make parse_user_sigframe() independent of rt_sigframe layout
  • From: Dave Martin <Dave.Martin@xxxxxxx>
• [RFC PATCH v2] arm64: signal: Make parse_user_sigframe() independent of rt_sigframe layout
  • From: Dave Martin <Dave.Martin@xxxxxxx>
• Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64
  • From: Jyri Sarha <jsarha@xxxxxx>
• Re: [PATCH 1/7] drm/tilcdc: don't use volatile with iowrite64
  • From: Jyri Sarha <jsarha@xxxxxx>
• Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: [RFC v3 02/23] powerpc: introduce set_hidx_slot helper
  • From: Balbir Singh <bsingharora@xxxxxxxxx>
• Re: [PATCH 10/17] irqchip: New RISC-V PLIC Driver
  • From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
• Re: [RFC PATCH] arm64: signal: Make parse_user_sigframe() independent of rt_sigframe layout
  • From: Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx>