Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of Linux 5.2-rc6 and has some minor
conflicts with the hmm tree that are easy to resolve.
Diffstat summary:
34 files changed, 379 insertions(+), 1016 deletions(-)
Git tree:
git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.4
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-devmem-cleanup.4
Changes since v3:
- pull in "mm/swap: Fix release_pages() when releasing devmap pages" and
rebase the other patches on top of that
- fold the hmm_devmem_add_resource into the DEVICE_PUBLIC memory removal
patch
- remove _vm_normal_page as it isn't needed without DEVICE_PUBLIC memory
- pick up various ACKs
Changes since v2:
- fix nvdimm kunit build
- add a new memory type for device dax
- fix a few issues in intermediate patches that didn't show up in the end
result
- incorporate feedback from Michal Hocko, including killing of
the DEVICE_PUBLIC memory type entirely
Changes since v1:
- rebase
- also switch p2pdma to the internal refcount
- add type checking for pgmap->type
- rename the migrate method to migrate_to_ram
- cleanup the altmap_valid flag
- various tidbits from the reviews
From: Jason Gunthorpe <[email protected]>
The wait_event_timeout macro already tests the condition as its first
action, so there is no reason to open code another version of this, all
that does is skip the might_sleep() debugging in common cases, which is
not helpful.
Further, based on prior patches, we can now simplify the required condition
test:
- If range is valid memory then so is range->hmm
- If hmm_release() has run then range->valid is set to false
at the same time as dead, so no reason to check both.
- A valid hmm has a valid hmm->mm.
Allowing the return value of wait_event_timeout() (along with its internal
barriers) to compute the result of the function.
Signed-off-by: Jason Gunthorpe <[email protected]>
Reviewed-by: Ralph Campbell <[email protected]>
Reviewed-by: John Hubbard <[email protected]>
Reviewed-by: Ira Weiny <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Tested-by: Philip Yang <[email protected]>
---
include/linux/hmm.h | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 1d97b6d62c5b..26e7c477490c 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -209,17 +209,8 @@ static inline unsigned long hmm_range_page_size(const struct hmm_range *range)
static inline bool hmm_range_wait_until_valid(struct hmm_range *range,
unsigned long timeout)
{
- /* Check if mm is dead ? */
- if (range->hmm == NULL || range->hmm->dead || range->hmm->mm == NULL) {
- range->valid = false;
- return false;
- }
- if (range->valid)
- return true;
- wait_event_timeout(range->hmm->wq, range->valid || range->hmm->dead,
- msecs_to_jiffies(timeout));
- /* Return current valid status just in case we get lucky */
- return range->valid;
+ return wait_event_timeout(range->hmm->wq, range->valid,
+ msecs_to_jiffies(timeout)) != 0;
}
/*
--
2.20.1
From: "Kuehling, Felix" <[email protected]>
Don't set this flag by default in hmm_vma_do_fault. It is set
conditionally just a few lines below. Setting it unconditionally can lead
to handle_mm_fault doing a non-blocking fault, returning -EBUSY and
unlocking mmap_sem unexpectedly.
Signed-off-by: Felix Kuehling <[email protected]>
Reviewed-by: Jérôme Glisse <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index dce4e70e648a..826816ab2377 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -328,7 +328,7 @@ struct hmm_vma_walk {
static int hmm_vma_do_fault(struct mm_walk *walk, unsigned long addr,
bool write_fault, uint64_t *pfn)
{
- unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_REMOTE;
+ unsigned int flags = FAULT_FLAG_REMOTE;
struct hmm_vma_walk *hmm_vma_walk = walk->private;
struct hmm_range *range = hmm_vma_walk->range;
struct vm_area_struct *vma = walk->vma;
--
2.20.1
And I've demonstrated that I can't send patch series.. While this
has all the right patches, it also has the extra patches already
in the hmm tree, and four extra patches I wanted to send once
this series is merged. I'll give up for now, please use the git
url for anything serious, as it contains the right thing.
On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> And I've demonstrated that I can't send patch series.. While this
> has all the right patches, it also has the extra patches already
> in the hmm tree, and four extra patches I wanted to send once
> this series is merged. I'll give up for now, please use the git
> url for anything serious, as it contains the right thing.
Okay, I sorted it all out and temporarily put it here:
https://github.com/jgunthorpe/linux/commits/hmm
Bit involved job:
- Took Ira's v4 patch into hmm.git and confirmed it matches what
Andrew has in linux-next after all the fixups
- Checked your github v4 and the v3 that hit the mailing list were
substantially similar (I never did get a clean v4) and largely
went with the github version
- Based CH's v4 series on -rc7 and put back the removal hunk in swap.c
so it compiles
- Merge'd CH's series to hmm.git and fixed all the conflicts with Ira
and Ralph's patches (such that swap.c remains unchanged)
- Added Dan's ack's and tested-by's
I think this fairly closely follows what was posted to the mailing
list.
As it was more than a simple 'git am', I'll let it sit on github until
I hear OK's then I'll move it to kernel.org's hmm.git and it will hit
linux-next. 0-day should also run on this whole thing from my github.
What I know is outstanding:
- The conflicting ARM patches, I understand Andrew will handle these
post-linux-next
- The conflict with AMD GPU in -next, I am waiting to hear from AMD
Otherwise I think we are done with hmm.git for this
cycle.
Unfortunately this is still not enough to progress rdma's ODP, so we
will need to do this again next cycle :( I'll be working on patches
once I get all the merge window prep I have to do done.
Regards,
Jason
On Tue, Jul 2, 2019 at 11:42 AM Jason Gunthorpe <[email protected]> wrote:
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this
> > has all the right patches, it also has the extra patches already
> > in the hmm tree, and four extra patches I wanted to send once
> > this series is merged. I'll give up for now, please use the git
> > url for anything serious, as it contains the right thing.
>
> Okay, I sorted it all out and temporarily put it here:
>
> https://github.com/jgunthorpe/linux/commits/hmm
>
> Bit involved job:
> - Took Ira's v4 patch into hmm.git and confirmed it matches what
> Andrew has in linux-next after all the fixups
> - Checked your github v4 and the v3 that hit the mailing list were
> substantially similar (I never did get a clean v4) and largely
> went with the github version
> - Based CH's v4 series on -rc7 and put back the removal hunk in swap.c
> so it compiles
> - Merge'd CH's series to hmm.git and fixed all the conflicts with Ira
> and Ralph's patches (such that swap.c remains unchanged)
> - Added Dan's ack's and tested-by's
Looks good. Test merge (with some collisions, see below) also passes
my test suite.
>
> I think this fairly closely follows what was posted to the mailing
> list.
>
> As it was more than a simple 'git am', I'll let it sit on github until
> I hear OK's then I'll move it to kernel.org's hmm.git and it will hit
> linux-next. 0-day should also run on this whole thing from my github.
>
> What I know is outstanding:
> - The conflicting ARM patches, I understand Andrew will handle these
> post-linux-next
> - The conflict with AMD GPU in -next, I am waiting to hear from AMD
Just a heads up that this also collides with the "sub-section" patches
in Andrew's tree. The resolution is straightforward, mostly just
colliding updates to arch_{add,remove}_memory() call sites in
kernel/memremap.c and collisions with pgmap_altmap() usage.
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this has
> > all the right patches, it also has the extra patches already in the
> > hmm tree, and four extra patches I wanted to send once this series is
> > merged. I'll give up for now, please use the git url for anything
> > serious, as it contains the right thing.
>
> Okay, I sorted it all out and temporarily put it here:
>
> https://github.com/jgunthorpe/linux/commits/hmm
>
> Bit involved job:
> - Took Ira's v4 patch into hmm.git and confirmed it matches what
> Andrew has in linux-next after all the fixups
Looking at the final branch seems good.
Ira
> - Checked your github v4 and the v3 that hit the mailing list were
> substantially similar (I never did get a clean v4) and largely
> went with the github version
> - Based CH's v4 series on -rc7 and put back the removal hunk in swap.c
> so it compiles
> - Merge'd CH's series to hmm.git and fixed all the conflicts with Ira
> and Ralph's patches (such that swap.c remains unchanged)
> - Added Dan's ack's and tested-by's
>
> I think this fairly closely follows what was posted to the mailing list.
>
> As it was more than a simple 'git am', I'll let it sit on github until I hear OK's
> then I'll move it to kernel.org's hmm.git and it will hit linux-next. 0-day
> should also run on this whole thing from my github.
>
> What I know is outstanding:
> - The conflicting ARM patches, I understand Andrew will handle these
> post-linux-next
> - The conflict with AMD GPU in -next, I am waiting to hear from AMD
>
> Otherwise I think we are done with hmm.git for this cycle.
>
> Unfortunately this is still not enough to progress rdma's ODP, so we will need
> to do this again next cycle :( I'll be working on patches once I get all the
> merge window prep I have to do done.
>
> Regards,
> Jason
On Tue, Jul 02, 2019 at 04:17:48PM -0700, Dan Williams wrote:
> On Tue, Jul 2, 2019 at 11:42 AM Jason Gunthorpe <[email protected]> wrote:
> >
> > On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > > And I've demonstrated that I can't send patch series.. While this
> > > has all the right patches, it also has the extra patches already
> > > in the hmm tree, and four extra patches I wanted to send once
> > > this series is merged. I'll give up for now, please use the git
> > > url for anything serious, as it contains the right thing.
> >
> > Okay, I sorted it all out and temporarily put it here:
> >
> > https://github.com/jgunthorpe/linux/commits/hmm
> >
> > Bit involved job:
> > - Took Ira's v4 patch into hmm.git and confirmed it matches what
> > Andrew has in linux-next after all the fixups
> > - Checked your github v4 and the v3 that hit the mailing list were
> > substantially similar (I never did get a clean v4) and largely
> > went with the github version
> > - Based CH's v4 series on -rc7 and put back the removal hunk in swap.c
> > so it compiles
> > - Merge'd CH's series to hmm.git and fixed all the conflicts with Ira
> > and Ralph's patches (such that swap.c remains unchanged)
> > - Added Dan's ack's and tested-by's
>
> Looks good. Test merge (with some collisions, see below) also passes
> my test suite.
Okay, published toward linux-next now
> >
> > I think this fairly closely follows what was posted to the mailing
> > list.
> >
> > As it was more than a simple 'git am', I'll let it sit on github until
> > I hear OK's then I'll move it to kernel.org's hmm.git and it will hit
> > linux-next. 0-day should also run on this whole thing from my github.
> >
> > What I know is outstanding:
> > - The conflicting ARM patches, I understand Andrew will handle these
> > post-linux-next
> > - The conflict with AMD GPU in -next, I am waiting to hear from AMD
>
> Just a heads up that this also collides with the "sub-section" patches
> in Andrew's tree. The resolution is straightforward, mostly just
> colliding updates to arch_{add,remove}_memory() call sites in
> kernel/memremap.c and collisions with pgmap_altmap() usage.
Okay, thanks
Jason
On Tue, Jul 02, 2019 at 10:45:34PM +0000, Weiny, Ira wrote:
> >
> > On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > > And I've demonstrated that I can't send patch series.. While this has
> > > all the right patches, it also has the extra patches already in the
> > > hmm tree, and four extra patches I wanted to send once this series is
> > > merged. I'll give up for now, please use the git url for anything
> > > serious, as it contains the right thing.
> >
> > Okay, I sorted it all out and temporarily put it here:
> >
> > https://github.com/jgunthorpe/linux/commits/hmm
> >
> > Bit involved job:
> > - Took Ira's v4 patch into hmm.git and confirmed it matches what
> > Andrew has in linux-next after all the fixups
>
> Looking at the final branch seems good.
Looks good to me as well.