Linux filesystem development
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	 Shuah Khan <skhan@linuxfoundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	 Vlastimil Babka <vbabka@kernel.org>,
	Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
	 Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>, Peter Xu <peterx@redhat.com>,
	 Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Zi Yan <ziy@nvidia.com>,
	 Baolin Wang <baolin.wang@linux.alibaba.com>,
	Nico Pache <nico.pache@linux.dev>,
	 Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
	Barry Song <baohua@kernel.org>,
	 Lance Yang <lance.yang@linux.dev>,
	Usama Arif <usama.arif@linux.dev>,
	 Kiryl Shutsemau <kas@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	 linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-doc@vger.kernel.org,  linux-mm@kvack.org,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/userfaultfd: prevent poison marker loss
Date: Sat, 14 Nov 2026 18:40:50 +0000	[thread overview]
Message-ID: <avij463DZ_tSwgKy@gremlin> (raw)
In-Reply-To: <20261107-b4-uffd_marker_loss-v1-1-82926b22704c@kernel.org>

On Sat, Nov 07, 2026 at 12:51:05AM +0100, David Hildenbrand (Arm) wrote:
> Unregistering userfaultfd leaves poison markers in the page tables.
> However, once unregistered, hugetlb PMD tables can be shared again.
>
> Further, shmem page-table retraction can discard poison markers even
> while registered in missing mode, and fork() can skip copying page
> tables containing poison markers.
>
> To fix it, add VM_MAYBE_UFFD_POISON and set it before installing poison
> markers. Preserve it across unregistration, splits, merges and fork(),
> just like we do with guard markers.
>
> Use the new atomic VMA flag to disable PMD sharing and page-table
> retraction, and to force page-table copying during fork().
>
> Move VM_UFFD_WP to bit 44 and make HAVE_ARCH_USERFAULTFD_WP depend on
> 64BIT, freeing bit 12 for the new flag on both 32-bit and 64-bit systems.
> Expose the flag as "up" in smaps.
>
> Losing poison markers, while unpleasant, is not really fatal, and the
> use case is rather a niche thing. In addition, we rely on the atomic
> VMA flags infrastructure ... so let's not CC stable.
>
> Fixes: fc71884a5f59 ("mm: userfaultfd: add new UFFDIO_POISON ioctl")
> Fixes: 8a13897fb0da ("mm: userfaultfd: support UFFDIO_POISON for hugetlbfs")

Are we looking to cc: stable or this something for newer kernels only?

> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

Logic LGTM, some small nits below. Overall:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> ---
>  Documentation/filesystems/proc.rst |  1 +
>  fs/proc/task_mmu.c                 |  3 +++
>  include/linux/mm.h                 | 45 ++++++++++++++++++++++++--------------
>  include/linux/userfaultfd_k.h      |  7 ++++--
>  include/trace/events/mmflags.h     |  9 +++++++-
>  mm/Kconfig                         |  1 +
>  mm/khugepaged.c                    |  9 ++++----
>  mm/userfaultfd.c                   |  3 +++
>  tools/testing/vma/include/dup.h    | 20 ++++++++++++-----
>  9 files changed, 70 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> index fa7a468e8edf2..bcbcb41814d96 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -614,6 +614,7 @@ encoded manner. The codes are the following:
>      lf    lock on fault pages
>      dp    always lazily freeable mapping
>      gu    maybe contains guard regions (if not set, definitely doesn't)
> +    up    maybe contains poison markers installed by userfaultfd
>      ==    =============================================================
>
>  Note that there is no guarantee that every flag and associated mnemonic will
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index e3d894ed2b913..d7f9934d0e499 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1106,6 +1106,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
>  		[ilog2(VM_GROWSDOWN)]	= "gd",
>  		[ilog2(VM_PFNMAP)]	= "pf",
>  		[ilog2(VM_MAYBE_GUARD)]	= "gu",
> +		[ilog2(VM_MAYBE_UFFD_POISON)]	= "up",
>  		[ilog2(VM_LOCKED)]	= "lo",
>  		[ilog2(VM_IO)]		= "io",
>  		[ilog2(VM_SEQ_READ)]	= "sr",
> @@ -1131,7 +1132,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
>  		[ilog2(VM_NOHUGEPAGE)]	= "nh",
>  		[ilog2(VM_MERGEABLE)]	= "mg",
>  		[ilog2(VM_UFFD_MISSING)]= "um",
> +#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
>  		[ilog2(VM_UFFD_WP)]	= "uw",
> +#endif
>  #ifdef CONFIG_ARM64_MTE
>  		[ilog2(VM_MTE)]		= "mt",
>  		[ilog2(VM_MTE_ALLOWED)]	= "",
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6a34dd3800f56..6cd9d86f7adac 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -302,7 +302,7 @@ enum {
>  	/* Page-ranges managed without "struct page", just pure PFN */
>  	DECLARE_VMA_BIT(PFNMAP, 10),
>  	DECLARE_VMA_BIT(MAYBE_GUARD, 11),
> -	DECLARE_VMA_BIT(UFFD_WP, 12),	/* wrprotect pages tracking */
> +	DECLARE_VMA_BIT(MAYBE_UFFD_POISON, 12),
>  	DECLARE_VMA_BIT(LOCKED, 13),
>  	DECLARE_VMA_BIT(IO, 14),	/* Memory mapped I/O or similar */
>  	DECLARE_VMA_BIT(SEQ_READ, 15),	/* App will access data sequentially */
> @@ -346,6 +346,7 @@ enum {
>  	DECLARE_VMA_BIT(UFFD_MINOR, 41),
>  	DECLARE_VMA_BIT(SEALED, 42),
>  	DECLARE_VMA_BIT(UFFD_RWP, 43),
> +	DECLARE_VMA_BIT(UFFD_WP, 44),	/* wrprotect pages tracking */
>  	/* Flags that reuse flags above. */
>  	DECLARE_VMA_BIT_ALIAS(PKEY_BIT0, HIGH_ARCH_0),
>  	DECLARE_VMA_BIT_ALIAS(PKEY_BIT1, HIGH_ARCH_1),
> @@ -406,7 +407,12 @@ enum {
>  #endif
>  #define VM_PFNMAP	INIT_VM_FLAG(PFNMAP)
>  #define VM_MAYBE_GUARD	INIT_VM_FLAG(MAYBE_GUARD)
> +#define VM_MAYBE_UFFD_POISON	INIT_VM_FLAG(MAYBE_UFFD_POISON)
> +#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
>  #define VM_UFFD_WP	INIT_VM_FLAG(UFFD_WP)
> +#else
> +#define VM_UFFD_WP	VM_NONE
> +#endif

As per below, please move the VMA_UFFD_WP decls here.

Also, could you also do:

static inline bool userfaultfd_wp(struct vm_area_struct *vma)
{
-	return vma_test_any_mask(vma, VMA_UFFD_WP);
+	return vma_test_single_mask(vma, VMA_UFFD_WP);
}

To match convention for using vma_test_single_mask() for flags that aren't
always defined. Thanks! :)


>  #define VM_LOCKED	INIT_VM_FLAG(LOCKED)
>  #define VM_IO		INIT_VM_FLAG(IO)
>  #define VM_SEQ_READ	INIT_VM_FLAG(SEQ_READ)
> @@ -502,13 +508,17 @@ enum {
>  #endif
>
>  /*
> - * vma_flags_t masks for the userfaultfd VMA flags. The two high-bit modes are
> - * gated on the same configs as their VM_* flags above -- both of which imply
> + * vma_flags_t masks for the userfaultfd VMA flags. The three high-bit modes are
> + * gated on the same configs as their VM_* flags above -- all of which imply
>   * 64BIT -- so an out-of-range bit is never fed to mk_vma_flags() on a build
>   * whose bitmap cannot hold it.
>   */
>  #define VMA_UFFD_MISSING	mk_vma_flags(VMA_UFFD_MISSING_BIT)
> +#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
>  #define VMA_UFFD_WP		mk_vma_flags(VMA_UFFD_WP_BIT)
> +#else
> +#define VMA_UFFD_WP		EMPTY_VMA_FLAGS
> +#endif

Could you just move these up to the block above to match the convention here?

>  #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
>  #define VMA_UFFD_MINOR		mk_vma_flags(VMA_UFFD_MINOR_BIT)
>  #else
> @@ -602,7 +612,8 @@ enum {
>  #define VMA_LOCKED_MASK	mk_vma_flags(VMA_LOCKED_BIT, VMA_LOCKONFAULT_BIT)
>
>  /* These flags can be updated atomically via VMA/mmap read lock. */
> -#define VMA_ATOMIC_SET_ALLOWED mk_vma_flags(VMA_MAYBE_GUARD_BIT)
> +#define VMA_ATOMIC_SET_ALLOWED mk_vma_flags(VMA_MAYBE_GUARD_BIT, \
> +					    VMA_MAYBE_UFFD_POISON_BIT)
>
>  /* Arch-specific flags to clear when updating VM flags on protection change */
>  #ifndef VM_ARCH_CLEAR
> @@ -620,16 +631,16 @@ enum {
>   *                       merged VMA should be considered soft-dirty also as it
>   *                       operates at a VMA granularity.
>   *
> - * VMA_MAYBE_GUARD_BIT - If a VMA may have guard regions in place it implies
> - *                       that mapped page tables may contain metadata not
> - *                       described by the VMA and thus any merged VMA may also
> - *                       contain this metadata, and thus we must make this flag
> - *                       sticky.
> + * VMA_MAYBE_GUARD_BIT / VMA_MAYBE_UFFD_POISON_BIT - Page tables may contain guard
> + *                       or poison markers not described by the VMA. Any
> + *                       merged VMA may also contain this metadata, so these
> + *                       flags must be sticky.
>   */
>  #ifdef CONFIG_MEM_SOFT_DIRTY
> -#define VMA_STICKY_FLAGS mk_vma_flags(VMA_SOFTDIRTY_BIT, VMA_MAYBE_GUARD_BIT)
> +#define VMA_STICKY_FLAGS mk_vma_flags(VMA_SOFTDIRTY_BIT, VMA_MAYBE_GUARD_BIT, \
> +				     VMA_MAYBE_UFFD_POISON_BIT)
>  #else
> -#define VMA_STICKY_FLAGS mk_vma_flags(VMA_MAYBE_GUARD_BIT)
> +#define VMA_STICKY_FLAGS mk_vma_flags(VMA_MAYBE_GUARD_BIT, VMA_MAYBE_UFFD_POISON_BIT)
>  #endif
>
>  /*
> @@ -667,13 +678,15 @@ enum {
>   *                           retrieve from page cache, and skip copying
>   *                           will lose those info.
>   *
> - *          VM_MAYBE_GUARD - Could contain page guard region markers which
> - *                           by design are a property of the page tables
> - *                           only and thus cannot be reconstructed on page
> - *                           fault.
> + *          VM_MAYBE_GUARD - Could contain guard markers which cannot be
> + *                           reconstructed on page fault.
> + *
> + *   VM_MAYBE_UFFD_POISON - Could contain poison markers which cannot be
> + *                           reconstructed on page fault, including after
> + *                           userfaultfd unregister.
>   */
>  #define VM_COPY_ON_FORK (VM_PFNMAP | VM_MIXEDMAP | VM_UFFD_WP | VM_UFFD_RWP | \
> -			 VM_MAYBE_GUARD)
> +			 VM_MAYBE_GUARD | VM_MAYBE_UFFD_POISON)
>
>  /*
>   * mapping from the currently active vm_flags protection bits (the
> diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
> index dff9a5c9a0dfa..b8b7cc2f00388 100644
> --- a/include/linux/userfaultfd_k.h
> +++ b/include/linux/userfaultfd_k.h
> @@ -167,11 +167,14 @@ static inline bool is_mergeable_vm_userfaultfd_ctx(struct vm_area_struct *vma,
>
>  /*
>   * Never enable huge pmd sharing on userfaultfd registered VMAs, because
> - * userfaultfd state can be tracked per VMA or per page table entry.
> + * userfaultfd state can be tracked per VMA or per page table entry. Similarly,
> + * handle poison markers that stick around even after userfaultfd was
> + * unregistered.
>   */
>  static inline bool uffd_disable_huge_pmd_share(struct vm_area_struct *vma)
>  {
> -	return vma->vm_userfaultfd_ctx.ctx;
> +	return vma->vm_userfaultfd_ctx.ctx ||
> +	       vma_test_atomic_flag(vma, VMA_MAYBE_UFFD_POISON_BIT);
>  }
>
>  /*
> diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
> index 3c153b3ad8450..942746e4de15b 100644
> --- a/include/trace/events/mmflags.h
> +++ b/include/trace/events/mmflags.h
> @@ -184,6 +184,12 @@ IF_HAVE_PG_ARCH_3(arch_3)
>  #define IF_HAVE_VM_SOFTDIRTY(flag,name)
>  #endif
>
> +#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
> +# define IF_HAVE_UFFD_WP(flag, name) {flag, name},
> +#else
> +# define IF_HAVE_UFFD_WP(flag, name)
> +#endif
> +
>  #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
>  # define IF_HAVE_UFFD_MINOR(flag, name) {flag, name},
>  #else
> @@ -247,7 +253,8 @@ IF_HAVE_PG_ARCH_3(arch_3)
>  IF_HAVE_UFFD_MINOR(VM_UFFD_MINOR,	"uffd_minor"	)		\
>  	{VM_PFNMAP,			"pfnmap"	},		\
>  	{VM_MAYBE_GUARD,		"maybe_guard"	},		\
> -	{VM_UFFD_WP,			"uffd_wp"	},		\
> +	{VM_MAYBE_UFFD_POISON,		"maybe_uffd_poison"	},		\
> +IF_HAVE_UFFD_WP(VM_UFFD_WP,		"uffd_wp")			\
>  IF_HAVE_UFFD_RWP(VM_UFFD_RWP,		"uffd_rwp"	)		\
>  	{VM_LOCKED,			"locked"	},		\
>  	{VM_IO,				"io"		},		\
> diff --git a/mm/Kconfig b/mm/Kconfig
> index afff1b25b5438..ad9236933aab3 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1357,6 +1357,7 @@ config ANON_VMA_NAME
>
>  config HAVE_ARCH_USERFAULTFD_WP
>  	bool
> +	depends on 64BIT

This is just saying out loud what was already the case effectively, which is
nice to do as a side-effect! :)

>  	help
>  	  Arch has userfaultfd write protection support
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 42d9eb26d5fab..2a5ee8fc42335 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -2107,16 +2107,17 @@ static bool file_backed_vma_is_retractable(struct vm_area_struct *vma)
>  		return false;
>
>  	/*
> -	 * If the VMA contains guard regions then we can't collapse it.
> +	 * Preserve guard and poison markers when retracting page tables.
>  	 *
> -	 * This is set atomically on guard marker installation under mmap/VMA
> +	 * These flags are set atomically on marker installation under mmap/VMA
>  	 * read lock, and here we may not hold any VMA or mmap lock at all.
>  	 *
>  	 * This is therefore serialised on the PTE page table lock, which is
> -	 * obtained on guard region installation after the flag is set, so this
> +	 * obtained on marker installation after the flag is set, so this
>  	 * check being performed under this lock excludes races.
>  	 */
> -	if (vma_test_atomic_flag(vma, VMA_MAYBE_GUARD_BIT))
> +	if (vma_test_atomic_flag(vma, VMA_MAYBE_GUARD_BIT) ||
> +	    vma_test_atomic_flag(vma, VMA_MAYBE_UFFD_POISON_BIT))
>  		return false;
>
>  	return true;
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index 169f681f9849b..bb6069320b347 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -963,6 +963,9 @@ static __always_inline ssize_t mfill_atomic(struct userfaultfd_ctx *ctx,
>  	if (err)
>  		goto out;
>
> +	if (uffd_flags_mode_is(flags, MFILL_ATOMIC_POISON))
> +		vma_set_atomic_flag(state.vma, VMA_MAYBE_UFFD_POISON_BIT);
> +
>  	/*
>  	 * If this is a HUGETLB vma, pass off to appropriate routine
>  	 */
> diff --git a/tools/testing/vma/include/dup.h b/tools/testing/vma/include/dup.h
> index dc4927d26296c..f9bafe4e20158 100644
> --- a/tools/testing/vma/include/dup.h
> +++ b/tools/testing/vma/include/dup.h
> @@ -117,7 +117,7 @@ enum {
>  	/* Page-ranges managed without "struct page", just pure PFN */
>  	DECLARE_VMA_BIT(PFNMAP, 10),
>  	DECLARE_VMA_BIT(MAYBE_GUARD, 11),
> -	DECLARE_VMA_BIT(UFFD_WP, 12),	/* wrprotect pages tracking */
> +	DECLARE_VMA_BIT(MAYBE_UFFD_POISON, 12),
>  	DECLARE_VMA_BIT(LOCKED, 13),
>  	DECLARE_VMA_BIT(IO, 14),	/* Memory mapped I/O or similar */
>  	DECLARE_VMA_BIT(SEQ_READ, 15),	/* App will access data sequentially */
> @@ -160,6 +160,7 @@ enum {
>  #endif
>  	DECLARE_VMA_BIT(UFFD_MINOR, 41),
>  	DECLARE_VMA_BIT(SEALED, 42),
> +	DECLARE_VMA_BIT(UFFD_WP, 44),	/* wrprotect pages tracking */
>  	/* Flags that reuse flags above. */
>  	DECLARE_VMA_BIT_ALIAS(PKEY_BIT0, HIGH_ARCH_0),
>  	DECLARE_VMA_BIT_ALIAS(PKEY_BIT1, HIGH_ARCH_1),
> @@ -218,7 +219,12 @@ enum {
>  #endif
>  #define VM_PFNMAP	INIT_VM_FLAG(PFNMAP)
>  #define VM_MAYBE_GUARD	INIT_VM_FLAG(MAYBE_GUARD)
> +#define VM_MAYBE_UFFD_POISON	INIT_VM_FLAG(MAYBE_UFFD_POISON)
> +#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_WP
>  #define VM_UFFD_WP	INIT_VM_FLAG(UFFD_WP)
> +#else
> +#define VM_UFFD_WP	VM_NONE
> +#endif
>  #define VM_LOCKED	INIT_VM_FLAG(LOCKED)
>  #define VM_IO		INIT_VM_FLAG(IO)
>  #define VM_SEQ_READ	INIT_VM_FLAG(SEQ_READ)
> @@ -367,7 +373,8 @@ enum {
>  #define VMA_LOCKED_MASK	mk_vma_flags(VMA_LOCKED_BIT, VMA_LOCKONFAULT_BIT)
>
>  /* These flags can be updated atomically via VMA/mmap read lock. */
> -#define VMA_ATOMIC_SET_ALLOWED mk_vma_flags(VMA_MAYBE_GUARD_BIT)
> +#define VMA_ATOMIC_SET_ALLOWED mk_vma_flags(VMA_MAYBE_GUARD_BIT, \
> +					    VMA_MAYBE_UFFD_POISON_BIT)
>
>  #define RLIMIT_STACK		3	/* max stack size */
>  #define RLIMIT_MEMLOCK		8	/* max locked-in-memory address space */
> @@ -375,14 +382,17 @@ enum {
>  #define CAP_IPC_LOCK         14
>
>  #ifdef CONFIG_MEM_SOFT_DIRTY
> -#define VMA_STICKY_FLAGS mk_vma_flags(VMA_SOFTDIRTY_BIT, VMA_MAYBE_GUARD_BIT)
> +#define VMA_STICKY_FLAGS mk_vma_flags(VMA_SOFTDIRTY_BIT, VMA_MAYBE_GUARD_BIT, \
> +				      VMA_MAYBE_UFFD_POISON_BIT)
>  #else
> -#define VMA_STICKY_FLAGS mk_vma_flags(VMA_MAYBE_GUARD_BIT)
> +#define VMA_STICKY_FLAGS mk_vma_flags(VMA_MAYBE_GUARD_BIT, \
> +				      VMA_MAYBE_UFFD_POISON_BIT)
>  #endif
>
>  #define VMA_IGNORE_MERGE_FLAGS VMA_STICKY_FLAGS
>
> -#define VM_COPY_ON_FORK (VM_PFNMAP | VM_MIXEDMAP | VM_UFFD_WP | VM_MAYBE_GUARD)
> +#define VM_COPY_ON_FORK (VM_PFNMAP | VM_MIXEDMAP | VM_UFFD_WP | \
> +			 VM_MAYBE_GUARD | VM_MAYBE_UFFD_POISON)
>
>  #define pgprot_val(x)		((x).pgprot)
>  #define __pgprot(x)		((pgprot_t) { (x) } )
>
> --
> 2.43.0
>

--
Cheers, Lorenzo

  parent reply	other threads:[~2026-11-14 18:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 23:51 [PATCH 0/2] mm/userfaultfd: prevent poison marker loss David Hildenbrand (Arm)
2026-11-06 23:51 ` [PATCH 1/2] " David Hildenbrand (Arm)
2026-11-14 15:39   ` David Hildenbrand (Arm)
2026-11-14 17:58     ` Lorenzo Stoakes (ARM)
2026-11-14 18:40   ` Lorenzo Stoakes (ARM) [this message]
2026-11-06 23:51 ` [PATCH 2/2] mm/khugepaged: check for empty PTE tables before retracting David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avij463DZ_tSwgKy@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=jannh@google.com \
    --cc=kas@kernel.org \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mhocko@suse.com \
    --cc=nico.pache@linux.dev \
    --cc=peterx@redhat.com \
    --cc=pfalcato@suse.de \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=skhan@linuxfoundation.org \
    --cc=surenb@google.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox