All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@mellanox.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Christoph Hellwig" <hch@lst.de>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ben Skeggs" <bskeggs@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
Date: Fri, 28 Jun 2019 18:29:29 +0000	[thread overview]
Message-ID: <20190628182922.GA15242@mellanox.com> (raw)
In-Reply-To: <CAPcyv4iWTe=vOXUqkr_CguFrFRqgA7hJSt4J0B3RpuP-Okz0Vw@mail.gmail.com>

On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote:
> On Fri, Jun 28, 2019 at 10:08 AM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > >
> > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote:
> > > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > > > >
> > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote:
> > > > > > The functionality is identical to the one currently open coded in
> > > > > > device-dax.
> > > > > >
> > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > > > Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > > > > >  drivers/dax/dax-private.h |  4 ----
> > > > > >  drivers/dax/device.c      | 43 ---------------------------------------
> > > > > >  2 files changed, 47 deletions(-)
> > > > >
> > > > > DanW: I think this series has reached enough review, did you want
> > > > > to ack/test any further?
> > > > >
> > > > > This needs to land in hmm.git soon to make the merge window.
> > > >
> > > > I was awaiting a decision about resolving the collision with Ira's
> > > > patch before testing the final result again [1]. You can go ahead and
> > > > add my reviewed-by for the series, but my tested-by should be on the
> > > > final state of the series.
> > >
> > > The conflict looks OK to me, I think we can let Andrew and Linus
> > > resolve it.
> >
> > Andrew's tree effectively always rebases since it's a quilt series.
> > I'd recommend pulling Ira's patch out of -mm and applying it with the
> > rest of hmm reworks. Any other git tree I'd agree with just doing the
> > late conflict resolution, but I'm not clear on what's the best
> > practice when conflicting with -mm.

What happens depends on timing as things arrive to Linus. I promised
to send hmm.git early, so I understand that Andrew will quilt rebase
his tree to Linus's and fix the conflict in Ira's patch before he
sends it.

> Regardless the patch is buggy. If you want to do the conflict
> resolution it should be because the DEVICE_PUBLIC removal effectively
> does the same fix otherwise we're knowingly leaving a broken point in
> the history.

I'm not sure I understand your concern, is there something wrong with
CH's series as it stands? hmm is a non-rebasing git tree, so as long
as the series is correct *when I apply it* there is no broken history.

I assumed the conflict resolution for Ira's patch was to simply take
the deletion of the if block from CH's series - right?

If we do need to take Ira's patch into hmm.git it will go after CH's
series (and Ira will have to rebase/repost it), so I think there is
nothing to do at this moment - unless you are saying there is a
problem with the series in CH's git tree?

Regards,
Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
To: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
	<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
	"nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [PATCH 16/25] device-dax: use the dev_pagemap internal refcount
Date: Fri, 28 Jun 2019 18:29:29 +0000	[thread overview]
Message-ID: <20190628182922.GA15242@mellanox.com> (raw)
In-Reply-To: <CAPcyv4iWTe=vOXUqkr_CguFrFRqgA7hJSt4J0B3RpuP-Okz0Vw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote:
> On Fri, Jun 28, 2019 at 10:08 AM Dan Williams <dan.j.williams@intel.com> wrote:
> >
> > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > >
> > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote:
> > > > On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe <jgg@mellanox.com> wrote:
> > > > >
> > > > > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote:
> > > > > > The functionality is identical to the one currently open coded in
> > > > > > device-dax.
> > > > > >
> > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > > > > > Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> > > > > >  drivers/dax/dax-private.h |  4 ----
> > > > > >  drivers/dax/device.c      | 43 ---------------------------------------
> > > > > >  2 files changed, 47 deletions(-)
> > > > >
> > > > > DanW: I think this series has reached enough review, did you want
> > > > > to ack/test any further?
> > > > >
> > > > > This needs to land in hmm.git soon to make the merge window.
> > > >
> > > > I was awaiting a decision about resolving the collision with Ira's
> > > > patch before testing the final result again [1]. You can go ahead and
> > > > add my reviewed-by for the series, but my tested-by should be on the
> > > > final state of the series.
> > >
> > > The conflict looks OK to me, I think we can let Andrew and Linus
> > > resolve it.
> >
> > Andrew's tree effectively always rebases since it's a quilt series.
> > I'd recommend pulling Ira's patch out of -mm and applying it with the
> > rest of hmm reworks. Any other git tree I'd agree with just doing the
> > late conflict resolution, but I'm not clear on what's the best
> > practice when conflicting with -mm.

What happens depends on timing as things arrive to Linus. I promised
to send hmm.git early, so I understand that Andrew will quilt rebase
his tree to Linus's and fix the conflict in Ira's patch before he
sends it.

> Regardless the patch is buggy. If you want to do the conflict
> resolution it should be because the DEVICE_PUBLIC removal effectively
> does the same fix otherwise we're knowingly leaving a broken point in
> the history.

I'm not sure I understand your concern, is there something wrong with
CH's series as it stands? hmm is a non-rebasing git tree, so as long
as the series is correct *when I apply it* there is no broken history.

I assumed the conflict resolution for Ira's patch was to simply take
the deletion of the if block from CH's series - right?

If we do need to take Ira's patch into hmm.git it will go after CH's
series (and Ira will have to rebase/repost it), so I think there is
nothing to do at this moment - unless you are saying there is a
problem with the series in CH's git tree?

Regards,
Jason
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

  reply	other threads:[~2019-06-28 18:29 UTC|newest]

Thread overview: 139+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26 12:26 dev_pagemap related cleanups v3 Christoph Hellwig
2019-06-26 12:26 ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 01/25] mm: remove the unused ARCH_HAS_HMM_DEVICE Kconfig option Christoph Hellwig
2019-06-26 12:27 ` [PATCH 02/25] mm: remove the struct hmm_device infrastructure Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 03/25] mm: remove hmm_devmem_add_resource Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-27 16:18   ` Jason Gunthorpe
2019-06-27 16:54     ` Christoph Hellwig
2019-06-27 16:54       ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 04/25] mm: remove MEMORY_DEVICE_PUBLIC support Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 16:00   ` Dan Williams
2019-06-26 16:00     ` Dan Williams
2019-06-26 17:14     ` Ira Weiny
2019-06-26 17:14       ` Ira Weiny
2019-06-26 17:14       ` Ira Weiny
2019-06-26 18:49       ` Ira Weiny
2019-06-26 18:49         ` Ira Weiny
2019-06-26 18:49         ` Ira Weiny
2019-06-26 12:27 ` [PATCH 05/25] mm: don't clear ->mapping in hmm_devmem_free Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 06/25] mm: export alloc_pages_vma Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:36   ` Michal Hocko
2019-06-26 12:36     ` Michal Hocko
2019-06-26 12:27 ` [PATCH 07/25] mm: factor out a devm_request_free_mem_region helper Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 08/25] memremap: validate the pagemap type passed to devm_memremap_pages Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 18:01   ` Ira Weiny
2019-06-26 18:01     ` Ira Weiny
2019-06-26 12:27 ` [PATCH 09/25] memremap: move dev_pagemap callbacks into a separate structure Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 10/25] memremap: pass a struct dev_pagemap to ->kill and ->cleanup Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 11/25] memremap: lift the devmap_enable manipulation into devm_memremap_pages Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 19:04   ` Ira Weiny
2019-06-26 19:04     ` Ira Weiny
2019-06-26 19:04     ` Ira Weiny
2019-06-27  8:50     ` Christoph Hellwig
2019-06-27  8:50       ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 12/25] memremap: add a migrate_to_ram method to struct dev_pagemap_ops Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-27 16:29   ` Jason Gunthorpe
2019-06-27 16:29     ` Jason Gunthorpe
2019-06-27 16:53     ` Christoph Hellwig
2019-06-27 16:53       ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 13/25] memremap: remove the data field in struct dev_pagemap Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 14/25] memremap: replace the altmap_valid field with a PGMAP_ALTMAP_VALID flag Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 21:13   ` Ira Weiny
2019-06-26 21:13     ` Ira Weiny
2019-06-26 12:27 ` [PATCH 15/25] memremap: provide an optional internal refcount in struct dev_pagemap Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 21:47   ` Ira Weiny
2019-06-26 21:47     ` Ira Weiny
2019-06-27  8:51     ` Christoph Hellwig
2019-06-27  8:51       ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 16/25] device-dax: use the dev_pagemap internal refcount Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 21:48   ` Ira Weiny
2019-06-26 21:48     ` Ira Weiny
2019-06-26 21:48     ` Ira Weiny
2019-06-28 15:38   ` Jason Gunthorpe
2019-06-28 16:27     ` Dan Williams
2019-06-28 16:27       ` Dan Williams
2019-06-28 17:02       ` Jason Gunthorpe
2019-06-28 17:02         ` Jason Gunthorpe
2019-06-28 17:08         ` Dan Williams
2019-06-28 17:10           ` Dan Williams
2019-06-28 17:10             ` Dan Williams
2019-06-28 18:29             ` Jason Gunthorpe [this message]
2019-06-28 18:29               ` Jason Gunthorpe
2019-06-28 18:44               ` Dan Williams
2019-06-28 18:51                 ` Christoph Hellwig
2019-06-28 18:51                   ` Christoph Hellwig
2019-06-28 18:59                   ` Dan Williams
2019-06-28 18:59                     ` Dan Williams
2019-06-28 19:02                     ` Christoph Hellwig
2019-06-28 19:02                       ` Christoph Hellwig
2019-06-28 19:14                       ` Dan Williams
2019-06-28 19:14                         ` Dan Williams
2019-06-28 19:14                         ` Dan Williams
2019-07-02 22:35                         ` Andrew Morton
2019-07-02 22:35                           ` Andrew Morton
2019-07-02 22:35                           ` Andrew Morton
2019-06-26 12:27 ` [PATCH 17/25] PCI/P2PDMA: " Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 21:49   ` Ira Weiny
2019-06-26 21:49     ` Ira Weiny
2019-06-26 21:49     ` Ira Weiny
2019-06-27 18:49   ` Logan Gunthorpe
2019-06-26 12:27 ` [PATCH 18/25] nouveau: use alloc_page_vma directly Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 19/25] nouveau: use devm_memremap_pages directly Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 20/25] mm: remove hmm_vma_alloc_locked_page Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-27 16:26   ` Jason Gunthorpe
2019-06-26 12:27 ` [PATCH 21/25] mm: remove hmm_devmem_add Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 22/25] mm: simplify ZONE_DEVICE page private data Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27 ` [PATCH 23/25] mm: sort out the DEVICE_PRIVATE Kconfig mess Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 21:36   ` Ira Weiny
2019-06-26 21:36     ` Ira Weiny
2019-06-26 12:27 ` [PATCH 24/25] mm: remove the HMM config option Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 21:38   ` Ira Weiny
2019-06-26 21:38     ` Ira Weiny
2019-06-26 21:38     ` Ira Weiny
2019-06-27 16:29   ` Jason Gunthorpe
2019-06-26 12:27 ` [PATCH 25/25] mm: don't select MIGRATE_VMA_HELPER from HMM_MIRROR Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig
2019-06-26 12:27   ` Christoph Hellwig

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=20190628182922.GA15242@mellanox.com \
    --to=jgg@mellanox.com \
    --cc=akpm@linux-foundation.org \
    --cc=bskeggs@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    /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.