All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Björn Töpel" <bjorn.topel@intel.com>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Dave Chinner" <david@fromorbit.com>,
	"David Airlie" <airlied@linux.ie>,
	"David S . Miller" <davem@davemloft.net>,
	"Ira Weiny" <ira.weiny@intel.com>, "Jan Kara" <jack@suse.cz>,
	"Jason Gunthorpe" <jgg@ziepe.ca>, "Jens Axboe" <axboe@kernel.dk>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Michal Hocko" <mhocko@suse.com>,
	"Mike Kravetz" <mike.kravetz@oracle.com>,
	"Paul Mackerras" <paulus@samba.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	bpf@vger.kernel.org, dri-devel@lists.freedesktop.org,
	kvm@vger.kernel.org, linux-block@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org,
	linux-rdma@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	netdev@vger.kernel.org, linux-mm@kvack.org,
	LKML <linux-kernel@vger.kernel.org>,
	"Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages
Date: Wed, 15 Jan 2020 13:19:41 -0800	[thread overview]
Message-ID: <4707f191-86f8-db4a-c3de-0a84b415b658@nvidia.com> (raw)
In-Reply-To: <20200115152306.GA19546@infradead.org>

On 1/15/20 7:23 AM, Christoph Hellwig wrote:
...
> 
> I'm really not sold on this scheme.  Note that I think it is
> particularly bad, but it also doesn't seem any better than what
> we had before, and it introduced quite a bit more code.
> 

Hi Christoph,

All by itself, yes. But the very next patch (which needs a little 
rework for other reasons, so not included here) needs to reuse some of 
these functions within __unpin_devmap_managed_user_page():

    page_is_devmap_managed()
    free_devmap_managed_page()

That patch was posted as part of the v11 series [1], and it did this:

+#ifdef CONFIG_DEV_PAGEMAP_OPS
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+	int count;
+
+	if (!page_is_devmap_managed(page))
+		return false;
+
+	count = page_ref_sub_return(page, GUP_PIN_COUNTING_BIAS);
+
+	__update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+	/*
+	 * devmap page refcounts are 1-based, rather than 0-based: if
+	 * refcount is 1, then the page is free and the refcount is
+	 * stable because nobody holds a reference on the page.
+	 */
+	if (count == 1)
+		free_devmap_managed_page(page);
+	else if (!count)
+		__put_page(page);
+
+	return true;
+}
+#else
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+	return false;
+}
+#endif /* CONFIG_DEV_PAGEMAP_OPS */
+
+/**
+ * unpin_user_page() - release a dma-pinned page
+ * @page:            pointer to page to be released
+ *
+ * Pages that were pinned via pin_user_pages*() must be released via either
+ * unpin_user_page(), or one of the unpin_user_pages*() routines. This is so
+ * that such pages can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special handling.
+ */
+void unpin_user_page(struct page *page)
+{
+	page = compound_head(page);
+
+	/*
+	 * For devmap managed pages we need to catch refcount transition from
+	 * GUP_PIN_COUNTING_BIAS to 1, when refcount reach one it means the
+	 * page is free and we need to inform the device driver through
+	 * callback. See include/linux/memremap.h and HMM for details.
+	 */
+	if (__unpin_devmap_managed_user_page(page))
+		return;
+
+	if (page_ref_sub_and_test(page, GUP_PIN_COUNTING_BIAS))
+		__put_page(page);
+
+	__update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+}
+EXPORT_SYMBOL(unpin_user_page);


[1] https://lore.kernel.org/r/20191216222537.491123-24-jhubbard@nvidia.com  
    [PATCH v11 23/25] mm/gup: track FOLL_PIN pages

thanks,
-- 
John Hubbard
NVIDIA

WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Michal Hocko" <mhocko@suse.com>, "Jan Kara" <jack@suse.cz>,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	"David Airlie" <airlied@linux.ie>,
	"Dave Chinner" <david@fromorbit.com>,
	dri-devel@lists.freedesktop.org,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, "Paul Mackerras" <paulus@samba.org>,
	linux-kselftest@vger.kernel.org,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	linux-rdma@vger.kernel.org, "Jason Gunthorpe" <jgg@ziepe.ca>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Björn Töpel" <bjorn.topel@intel.com>,
	linux-media@vger.kernel.org, "Shuah Khan" <shuah@kernel.org>,
	linux-block@vger.kernel.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	bpf@vger.kernel.org,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Jens Axboe" <axboe@kernel.dk>,
	netdev@vger.kernel.org,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	linux-fsdevel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S . Miller" <davem@davemloft.net>,
	"Mike Kravetz" <mike.kravetz@oracle.com>
Subject: Re: [PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages
Date: Wed, 15 Jan 2020 13:19:41 -0800	[thread overview]
Message-ID: <4707f191-86f8-db4a-c3de-0a84b415b658@nvidia.com> (raw)
In-Reply-To: <20200115152306.GA19546@infradead.org>

On 1/15/20 7:23 AM, Christoph Hellwig wrote:
...
> 
> I'm really not sold on this scheme.  Note that I think it is
> particularly bad, but it also doesn't seem any better than what
> we had before, and it introduced quite a bit more code.
> 

Hi Christoph,

All by itself, yes. But the very next patch (which needs a little 
rework for other reasons, so not included here) needs to reuse some of 
these functions within __unpin_devmap_managed_user_page():

    page_is_devmap_managed()
    free_devmap_managed_page()

That patch was posted as part of the v11 series [1], and it did this:

+#ifdef CONFIG_DEV_PAGEMAP_OPS
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+	int count;
+
+	if (!page_is_devmap_managed(page))
+		return false;
+
+	count = page_ref_sub_return(page, GUP_PIN_COUNTING_BIAS);
+
+	__update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+	/*
+	 * devmap page refcounts are 1-based, rather than 0-based: if
+	 * refcount is 1, then the page is free and the refcount is
+	 * stable because nobody holds a reference on the page.
+	 */
+	if (count == 1)
+		free_devmap_managed_page(page);
+	else if (!count)
+		__put_page(page);
+
+	return true;
+}
+#else
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+	return false;
+}
+#endif /* CONFIG_DEV_PAGEMAP_OPS */
+
+/**
+ * unpin_user_page() - release a dma-pinned page
+ * @page:            pointer to page to be released
+ *
+ * Pages that were pinned via pin_user_pages*() must be released via either
+ * unpin_user_page(), or one of the unpin_user_pages*() routines. This is so
+ * that such pages can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special handling.
+ */
+void unpin_user_page(struct page *page)
+{
+	page = compound_head(page);
+
+	/*
+	 * For devmap managed pages we need to catch refcount transition from
+	 * GUP_PIN_COUNTING_BIAS to 1, when refcount reach one it means the
+	 * page is free and we need to inform the device driver through
+	 * callback. See include/linux/memremap.h and HMM for details.
+	 */
+	if (__unpin_devmap_managed_user_page(page))
+		return;
+
+	if (page_ref_sub_and_test(page, GUP_PIN_COUNTING_BIAS))
+		__put_page(page);
+
+	__update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+}
+EXPORT_SYMBOL(unpin_user_page);


[1] https://lore.kernel.org/r/20191216222537.491123-24-jhubbard@nvidia.com  
    [PATCH v11 23/25] mm/gup: track FOLL_PIN pages

thanks,
-- 
John Hubbard
NVIDIA

WARNING: multiple messages have this Message-ID (diff)
From: John Hubbard <jhubbard@nvidia.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Michal Hocko" <mhocko@suse.com>, "Jan Kara" <jack@suse.cz>,
	kvm@vger.kernel.org, linux-doc@vger.kernel.org,
	"David Airlie" <airlied@linux.ie>,
	"Dave Chinner" <david@fromorbit.com>,
	dri-devel@lists.freedesktop.org,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, "Paul Mackerras" <paulus@samba.org>,
	linux-kselftest@vger.kernel.org,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Jonathan Corbet" <corbet@lwn.net>,
	linux-rdma@vger.kernel.org,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Björn Töpel" <bjorn.topel@intel.com>,
	linux-media@vger.kernel.org, "Shuah Khan" <shuah@kernel.org>,
	linux-block@vger.kernel.org, "Jérôme Glisse" <jglisse@redhat.com>,
	"Al Viro" <viro@zeniv.linux.org.uk>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	bpf@vger.kernel.org,
	"Magnus Karlsson" <magnus.karlsson@intel.com>,
	"Jens Axboe" <axboe@kernel.dk>,
	netdev@vger.kernel.org,
	"Alex Williamson" <alex.williamson@redhat.com>,
	linux-fsdevel@vger.kernel.org,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S . Miller" <davem@davemloft.net>,
	"Mike Kravetz" <mike.kravetz@oracle.com>
Subject: Re: [PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages
Date: Wed, 15 Jan 2020 13:19:41 -0800	[thread overview]
Message-ID: <4707f191-86f8-db4a-c3de-0a84b415b658@nvidia.com> (raw)
In-Reply-To: <20200115152306.GA19546@infradead.org>

On 1/15/20 7:23 AM, Christoph Hellwig wrote:
...
> 
> I'm really not sold on this scheme.  Note that I think it is
> particularly bad, but it also doesn't seem any better than what
> we had before, and it introduced quite a bit more code.
> 

Hi Christoph,

All by itself, yes. But the very next patch (which needs a little 
rework for other reasons, so not included here) needs to reuse some of 
these functions within __unpin_devmap_managed_user_page():

    page_is_devmap_managed()
    free_devmap_managed_page()

That patch was posted as part of the v11 series [1], and it did this:

+#ifdef CONFIG_DEV_PAGEMAP_OPS
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+	int count;
+
+	if (!page_is_devmap_managed(page))
+		return false;
+
+	count = page_ref_sub_return(page, GUP_PIN_COUNTING_BIAS);
+
+	__update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+	/*
+	 * devmap page refcounts are 1-based, rather than 0-based: if
+	 * refcount is 1, then the page is free and the refcount is
+	 * stable because nobody holds a reference on the page.
+	 */
+	if (count == 1)
+		free_devmap_managed_page(page);
+	else if (!count)
+		__put_page(page);
+
+	return true;
+}
+#else
+static bool __unpin_devmap_managed_user_page(struct page *page)
+{
+	return false;
+}
+#endif /* CONFIG_DEV_PAGEMAP_OPS */
+
+/**
+ * unpin_user_page() - release a dma-pinned page
+ * @page:            pointer to page to be released
+ *
+ * Pages that were pinned via pin_user_pages*() must be released via either
+ * unpin_user_page(), or one of the unpin_user_pages*() routines. This is so
+ * that such pages can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special handling.
+ */
+void unpin_user_page(struct page *page)
+{
+	page = compound_head(page);
+
+	/*
+	 * For devmap managed pages we need to catch refcount transition from
+	 * GUP_PIN_COUNTING_BIAS to 1, when refcount reach one it means the
+	 * page is free and we need to inform the device driver through
+	 * callback. See include/linux/memremap.h and HMM for details.
+	 */
+	if (__unpin_devmap_managed_user_page(page))
+		return;
+
+	if (page_ref_sub_and_test(page, GUP_PIN_COUNTING_BIAS))
+		__put_page(page);
+
+	__update_proc_vmstat(page, NR_FOLL_PIN_RETURNED, 1);
+}
+EXPORT_SYMBOL(unpin_user_page);


[1] https://lore.kernel.org/r/20191216222537.491123-24-jhubbard@nvidia.com  
    [PATCH v11 23/25] mm/gup: track FOLL_PIN pages

thanks,
-- 
John Hubbard
NVIDIA
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-01-15 21:19 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 22:45 [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN John Hubbard
2020-01-07 22:45 ` John Hubbard
2020-01-07 22:45 ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 01/22] mm/gup: factor out duplicate code from four routines John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 02/22] mm/gup: move try_get_compound_head() to top, fix minor issues John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 03/22] mm: Cleanup __put_devmap_managed_page() vs ->page_free() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-15 15:23   ` Christoph Hellwig
2020-01-15 15:23     ` Christoph Hellwig
2020-01-15 21:19     ` John Hubbard [this message]
2020-01-15 21:19       ` John Hubbard
2020-01-15 21:19       ` John Hubbard
2020-01-16  9:37       ` Christoph Hellwig
2020-01-16  9:37         ` Christoph Hellwig
2020-01-16 20:30         ` John Hubbard
2020-01-16 20:30           ` John Hubbard
2020-01-16 20:30           ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 05/22] goldish_pipe: rename local pin_user_pages() routine John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-15 15:23   ` Christoph Hellwig
2020-01-15 15:23     ` Christoph Hellwig
2020-01-07 22:45 ` [PATCH v12 06/22] mm: fix get_user_pages_remote()'s handling of FOLL_LONGTERM John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-15 15:24   ` Christoph Hellwig
2020-01-15 15:24     ` Christoph Hellwig
2020-01-07 22:45 ` [PATCH v12 07/22] vfio: fix FOLL_LONGTERM use, simplify get_user_pages_remote() call John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 08/22] mm/gup: allow FOLL_FORCE for get_user_pages_fast() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-15 15:25   ` Christoph Hellwig
2020-01-15 15:25     ` Christoph Hellwig
2020-01-07 22:45 ` [PATCH v12 09/22] IB/umem: use get_user_pages_fast() to pin DMA pages John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 10/22] media/v4l2-core: set pages dirty upon releasing DMA buffers John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 11/22] mm/gup: introduce pin_user_pages*() and FOLL_PIN John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-15 15:30   ` Christoph Hellwig
2020-01-15 15:30     ` Christoph Hellwig
2020-01-15 21:34     ` John Hubbard
2020-01-15 21:34       ` John Hubbard
2020-01-15 21:34       ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 12/22] goldish_pipe: convert to pin_user_pages() and put_user_page() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 13/22] IB/{core,hw,umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP John Hubbard
2020-01-07 22:45   ` [PATCH v12 13/22] IB/{core, hw, umem}: " John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 14/22] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 15/22] drm/via: set FOLL_PIN via pin_user_pages_fast() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 16/22] fs/io_uring: set FOLL_PIN via pin_user_pages() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 17/22] net/xdp: " John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 18/22] media/v4l2-core: pin_user_pages (FOLL_PIN) and put_user_page() conversion John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 19/22] vfio, mm: " John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 20/22] powerpc: book3s64: convert to pin_user_pages() and put_user_page() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 21/22] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1" John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45 ` [PATCH v12 22/22] mm, tree-wide: rename put_user_page*() to unpin_user_page*() John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-07 22:45   ` John Hubbard
2020-01-15 15:26   ` Christoph Hellwig
2020-01-15 15:26     ` Christoph Hellwig
2020-01-09 22:07 ` [PATCH v12 00/22] mm/gup: prereqs to track dma-pinned pages: FOLL_PIN John Hubbard
2020-01-09 22:07   ` John Hubbard
2020-01-09 22:07   ` John Hubbard
2020-01-14 20:15   ` John Hubbard
2020-01-14 20:15     ` John Hubbard
2020-01-14 20:15     ` John Hubbard
2020-01-14 23:29     ` Andrew Morton
2020-01-14 23:29       ` Andrew Morton
2020-01-14 23:29       ` Andrew Morton

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=4707f191-86f8-db4a-c3de-0a84b415b658@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=alex.williamson@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=benh@kernel.crashing.org \
    --cc=bjorn.topel@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=david@fromorbit.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=magnus.karlsson@intel.com \
    --cc=mchehab@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=shuah@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.