From: David Stevens <[email protected]>
Remove an unnecessary call to xas_set(index) when iterating over the
target range in collapse_file. The extra call to xas_set reset the xas
cursor to the top of the tree, causing the xas_next call on the next
iteration to walk the tree to index instead of advancing to index+1.
This returned the same page again, which would cause collapse_file to
fail because the page is already locked.
This bug was hidden when CONFIG_DEBUG_VM was set. When that config was
used, the xas_load in a subsequent VM_BUG_ON assert would walk xas from
the top of the tree to index, causing the xas_next call on the next loop
iteration to advance the cursor as expected.
Fixes: a2e17cc2efc7 ("mm/khugepaged: maintain page cache uptodate flag")
Signed-off-by: David Stevens <[email protected]>
---
mm/khugepaged.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 6b9d39d65b73..2d0d58fb4e7f 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2070,7 +2070,6 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
TTU_IGNORE_MLOCK | TTU_BATCH_FLUSH);
xas_lock_irq(&xas);
- xas_set(&xas, index);
VM_BUG_ON_PAGE(page != xas_load(&xas), page);
--
2.41.0.rc2.161.g9c6817b8e7-goog
On Wed, Jun 07, 2023 at 02:31:35PM +0900, David Stevens wrote:
> From: David Stevens <[email protected]>
>
> Remove an unnecessary call to xas_set(index) when iterating over the
> target range in collapse_file. The extra call to xas_set reset the xas
> cursor to the top of the tree, causing the xas_next call on the next
> iteration to walk the tree to index instead of advancing to index+1.
> This returned the same page again, which would cause collapse_file to
> fail because the page is already locked.
>
> This bug was hidden when CONFIG_DEBUG_VM was set. When that config was
> used, the xas_load in a subsequent VM_BUG_ON assert would walk xas from
> the top of the tree to index, causing the xas_next call on the next loop
> iteration to advance the cursor as expected.
>
> Fixes: a2e17cc2efc7 ("mm/khugepaged: maintain page cache uptodate flag")
> Signed-off-by: David Stevens <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
--
Peter Xu
On Wed, 7 Jun 2023, David Stevens wrote:
>
> Remove an unnecessary call to xas_set(index) when iterating over the
> target range in collapse_file. The extra call to xas_set reset the xas
> cursor to the top of the tree, causing the xas_next call on the next
> iteration to walk the tree to index instead of advancing to index+1.
> This returned the same page again, which would cause collapse_file to
> fail because the page is already locked.
>
> This bug was hidden when CONFIG_DEBUG_VM was set. When that config was
> used, the xas_load in a subsequent VM_BUG_ON assert would walk xas from
> the top of the tree to index, causing the xas_next call on the next loop
> iteration to advance the cursor as expected.
>
> Fixes: a2e17cc2efc7 ("mm/khugepaged: maintain page cache uptodate flag")
> Signed-off-by: David Stevens <[email protected]>
This patch seems to be wrong, but I have not investigated why.
It's certainly an interesting and worrying observation,
if a CONFIG_DEBUG_VM=y kernel goes a significantly different way.
I almost always do have CONFIG_DEBUG_VM=y, so you won't be surprised that
I never saw the issue. But once I ran an mm-everything with this patch in,
I hit that VM_BUG_ON_PAGE(page != xas_load(&xas), page) for the first time
(after about 2 hours of huge tmpfs swapping load).
As if you have just transferred the problem from DEBUG_VM=n to DEBUG_VM=y.
But I then tried a CONFIG_DEBUG_VM off 6.4-rc1 kernel (including the fixee
but not this fixer) under similar load, and saw no problem in 14 hours.
So I can't even reproduce the bug that is being fixed here: only hit a
bug that it introduces.
Hugh
> ---
> mm/khugepaged.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 6b9d39d65b73..2d0d58fb4e7f 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -2070,7 +2070,6 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
> TTU_IGNORE_MLOCK | TTU_BATCH_FLUSH);
>
> xas_lock_irq(&xas);
> - xas_set(&xas, index);
>
> VM_BUG_ON_PAGE(page != xas_load(&xas), page);
>
> --
> 2.41.0.rc2.161.g9c6817b8e7-goog
On Sat, Jun 10, 2023 at 5:03 AM Hugh Dickins <[email protected]> wrote:
>
> On Wed, 7 Jun 2023, David Stevens wrote:
> >
> > Remove an unnecessary call to xas_set(index) when iterating over the
> > target range in collapse_file. The extra call to xas_set reset the xas
> > cursor to the top of the tree, causing the xas_next call on the next
> > iteration to walk the tree to index instead of advancing to index+1.
> > This returned the same page again, which would cause collapse_file to
> > fail because the page is already locked.
> >
> > This bug was hidden when CONFIG_DEBUG_VM was set. When that config was
> > used, the xas_load in a subsequent VM_BUG_ON assert would walk xas from
> > the top of the tree to index, causing the xas_next call on the next loop
> > iteration to advance the cursor as expected.
> >
> > Fixes: a2e17cc2efc7 ("mm/khugepaged: maintain page cache uptodate flag")
> > Signed-off-by: David Stevens <[email protected]>
>
> This patch seems to be wrong, but I have not investigated why.
>
> It's certainly an interesting and worrying observation,
> if a CONFIG_DEBUG_VM=y kernel goes a significantly different way.
>
> I almost always do have CONFIG_DEBUG_VM=y, so you won't be surprised that
> I never saw the issue. But once I ran an mm-everything with this patch in,
> I hit that VM_BUG_ON_PAGE(page != xas_load(&xas), page) for the first time
> (after about 2 hours of huge tmpfs swapping load).
Is the particular workload one you can share? I haven't hit that
assert so far with my tests.
Also, I'm a little surprised that this is the assert which is being
hit. My patch series didn't make that many changes to the first loop
of the function, and the changes it did make were mostly about missing
pages, not present pages.
> As if you have just transferred the problem from DEBUG_VM=n to DEBUG_VM=y.
> But I then tried a CONFIG_DEBUG_VM off 6.4-rc1 kernel (including the fixee
> but not this fixer) under similar load, and saw no problem in 14 hours.
> So I can't even reproduce the bug that is being fixed here: only hit a
> bug that it introduces.
The bug this fixes isn't a crash - it's the fact that khugepage
becomes nearly unable to collapse pages. Specifically, it can only
collapse if there is exactly one present page, and that page is at
index 511. Since MADV_COLLAPSE uses the same code path, it's easy to
reproduce the bug I'm trying to fix with this program:
#define _GNU_SOURCE
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>
#define THP_SIZE (2 * 1024 * 1024)
#ifndef MADV_COLLAPSE
#define MADV_COLLAPSE 25
#endif
int main() {
int memfd = memfd_create("memfd", MFD_CLOEXEC);
assert(memfd >= 0);
int ret = ftruncate(memfd, THP_SIZE);
assert(ret >= 0);
char *addr = mmap(NULL, THP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, memfd, 0);
assert(addr != MAP_FAILED);
addr[0] = 0xff;
ret = madvise(addr, THP_SIZE, MADV_COLLAPSE);
assert(ret == 0);
}
If DEBUG_VM isn't set, then the test will trigger the assert. If
DEBUG_VM is set or if this fix is included, then the test will pass.
-David
> Hugh
>
> > ---
> > mm/khugepaged.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index 6b9d39d65b73..2d0d58fb4e7f 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -2070,7 +2070,6 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
> > TTU_IGNORE_MLOCK | TTU_BATCH_FLUSH);
> >
> > xas_lock_irq(&xas);
> > - xas_set(&xas, index);
> >
> > VM_BUG_ON_PAGE(page != xas_load(&xas), page);
> >
> > --
> > 2.41.0.rc2.161.g9c6817b8e7-goog
On Sat, 10 Jun 2023, David Stevens wrote:
> On Sat, Jun 10, 2023 at 5:03 AM Hugh Dickins <[email protected]> wrote:
> > On Wed, 7 Jun 2023, David Stevens wrote:
> > >
> > > Remove an unnecessary call to xas_set(index) when iterating over the
> > > target range in collapse_file. The extra call to xas_set reset the xas
> > > cursor to the top of the tree, causing the xas_next call on the next
> > > iteration to walk the tree to index instead of advancing to index+1.
> > > This returned the same page again, which would cause collapse_file to
> > > fail because the page is already locked.
> > >
> > > This bug was hidden when CONFIG_DEBUG_VM was set. When that config was
> > > used, the xas_load in a subsequent VM_BUG_ON assert would walk xas from
> > > the top of the tree to index, causing the xas_next call on the next loop
> > > iteration to advance the cursor as expected.
> > >
> > > Fixes: a2e17cc2efc7 ("mm/khugepaged: maintain page cache uptodate flag")
> > > Signed-off-by: David Stevens <[email protected]>
> >
> > This patch seems to be wrong,
I withdraw the accusation! I haven't thought about the patch itself:
I'd have to learn a bit more about the xarray rules, so cannot quickly
ack it myself; but withdraw my implicit nack.
> > but I have not investigated why.
> >
> > It's certainly an interesting and worrying observation,
> > if a CONFIG_DEBUG_VM=y kernel goes a significantly different way.
> >
> > I almost always do have CONFIG_DEBUG_VM=y, so you won't be surprised that
> > I never saw the issue. But once I ran an mm-everything with this patch in,
> > I hit that VM_BUG_ON_PAGE(page != xas_load(&xas), page) for the first time
> > (after about 2 hours of huge tmpfs swapping load).
>
> Is the particular workload one you can share?
It's a workload familiar to me, and no secret, but which would take much
more time to share than I have to spare; with no great likelihood that
you could easily reproduce all the conditions at the end of it.
> I haven't hit that assert so far with my tests.
And nor have I since. I've been trying 6.4-rc5 with and without your
patch, mm-everything (of a few days ago) with and without your patch,
with and without my pte_offset_map changes. Not once have I seen that
VM_BUG_ON_PAGE(page != xas_load(&xas), page) again, even with the exact
same kernel.
I've no doubt that I did hit it, but I'm now having to assume that it's
something very rare (or very rare in my particular testing). And because
the first time I saw it coincided with the first time I had in your patch
to the last non-blank line above it, I jumped to the conclusion that it
was your patch causing it. Not unreasonable at the time, but not
justified by later attempts. Perhaps there was something unrelated
in that kernel, corrupting an xarray node.
If I ever see it again, I hope I'll be able to spend more time
investigating; or if I study that code with more leisure, maybe a
hypothesis for a rare race will arise. But for now, we'd better
just forget about it.
>
> Also, I'm a little surprised that this is the assert which is being
> hit. My patch series didn't make that many changes to the first loop
> of the function, and the changes it did make were mostly about missing
> pages, not present pages.
I was suspicious of that patch series, as I said at the time; and might
one day want to revert it; but it has not given me any actual problem -
that only came with this fix to it.
>
> > As if you have just transferred the problem from DEBUG_VM=n to DEBUG_VM=y.
> > But I then tried a CONFIG_DEBUG_VM off 6.4-rc1 kernel (including the fixee
> > but not this fixer) under similar load, and saw no problem in 14 hours.
> > So I can't even reproduce the bug that is being fixed here: only hit a
> > bug that it introduces.
>
> The bug this fixes isn't a crash - it's the fact that khugepage
Sorry, yes, I should have re-read your commit message before writing
all that.
Thanks,
Hugh
> becomes nearly unable to collapse pages. Specifically, it can only
> collapse if there is exactly one present page, and that page is at
> index 511. Since MADV_COLLAPSE uses the same code path, it's easy to
> reproduce the bug I'm trying to fix with this program:
>
> #define _GNU_SOURCE
> #include <assert.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <unistd.h>
>
> #define THP_SIZE (2 * 1024 * 1024)
>
> #ifndef MADV_COLLAPSE
> #define MADV_COLLAPSE 25
> #endif
>
> int main() {
> int memfd = memfd_create("memfd", MFD_CLOEXEC);
> assert(memfd >= 0);
>
> int ret = ftruncate(memfd, THP_SIZE);
> assert(ret >= 0);
>
> char *addr = mmap(NULL, THP_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, memfd, 0);
> assert(addr != MAP_FAILED);
>
> addr[0] = 0xff;
>
> ret = madvise(addr, THP_SIZE, MADV_COLLAPSE);
> assert(ret == 0);
> }
>
> If DEBUG_VM isn't set, then the test will trigger the assert. If
> DEBUG_VM is set or if this fix is included, then the test will pass.
>
> -David
>
> > Hugh
> >
> > > ---
> > > mm/khugepaged.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index 6b9d39d65b73..2d0d58fb4e7f 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -2070,7 +2070,6 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
> > > TTU_IGNORE_MLOCK | TTU_BATCH_FLUSH);
> > >
> > > xas_lock_irq(&xas);
> > > - xas_set(&xas, index);
> > >
> > > VM_BUG_ON_PAGE(page != xas_load(&xas), page);
> > >
> > > --
> > > 2.41.0.rc2.161.g9c6817b8e7-goog
There is no xas_pause(&xas) in collapse_file()'s main loop, at the points
where it does xas_unlock_irq(&xas) and then continues.
That would explain why, once two weeks ago and twice yesterday, I have
hit the VM_BUG_ON_PAGE(page != xas_load(&xas), page) since "mm/khugepaged:
fix iteration in collapse_file" removed the xas_set(&xas, index) just
before it: xas.xa_node could be left pointing to a stale node, if there
was concurrent activity on the file which transformed its xarray.
I tried inserting xas_pause()s, but then even bootup crashed on that
VM_BUG_ON_PAGE(): there appears to be a subtle "nextness" implicit in
xas_pause().
xas_next() and xas_pause() are good for use in simple loops, but not in
this one: xas_set() worked well until now, so use xas_set(&xas, index)
explicitly at the head of the loop; and change that VM_BUG_ON_PAGE() not
to need its own xas_set(), and not to interfere with the xa_state (which
would probably stop the crashes from xas_pause(), but I trust that less).
Link: https://lore.kernel.org/linux-mm/[email protected]/
Fixes: c8a8f3b4a95a ("mm/khugepaged: fix iteration in collapse_file")
Signed-off-by: Hugh Dickins <[email protected]>
---
Linus, I'm rushing this directly to you, but not really expecting you
to put it in at this stage, unless you're very comfortable with it,
or perhaps it catches Matthew's eye and gets a quick Ack from him.
The commit being fixed only got in after -rc7, after being held up by my
initial report of this crash; but I had to rescind that when I couldn't
reproduce it at all. Then yesterday morning it hit again on two machines,
and reading XArray Doc reminded me of xas_pause() - seems obvious now.
Patch ran for 14 hours overnight on those two machines without a problem.
mm/khugepaged.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 2d0d58fb4e7f..47b59f2843f6 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1918,9 +1918,9 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
}
} while (1);
- xas_set(&xas, start);
for (index = start; index < end; index++) {
- page = xas_next(&xas);
+ xas_set(&xas, index);
+ page = xas_load(&xas);
VM_BUG_ON(index != xas.xa_index);
if (is_shmem) {
@@ -1935,7 +1935,6 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
result = SCAN_TRUNCATED;
goto xa_locked;
}
- xas_set(&xas, index + 1);
}
if (!shmem_charge(mapping->host, 1)) {
result = SCAN_FAIL;
@@ -2071,7 +2070,7 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
xas_lock_irq(&xas);
- VM_BUG_ON_PAGE(page != xas_load(&xas), page);
+ VM_BUG_ON_PAGE(page != xa_load(xas.xa, index), page);
/*
* We control three references to the page:
--
2.35.3
On Sun, 25 Jun 2023 at 12:06, Hugh Dickins <[email protected]> wrote:
>
> Linus, I'm rushing this directly to you, but not really expecting you
> to put it in at this stage, unless you're very comfortable with it,
> or perhaps it catches Matthew's eye and gets a quick Ack from him.
Yeah, the fix and explanation sound fine to me, but the maple tree
code confuses me enough and has been subtle enough (as exemplified by
this bug and many others) that there's no way I'll apply this just
before the final 6.4 without some "Ack, that's obviously correct" from
Willy or Liam or somebody.
Willy?
Linus
There is no xas_pause(&xas) in collapse_file()'s main loop, at the points
where it does xas_unlock_irq(&xas) and then continues.
That would explain why, once two weeks ago and twice yesterday, I have
hit the VM_BUG_ON_PAGE(page != xas_load(&xas), page) since "mm/khugepaged:
fix iteration in collapse_file" removed the xas_set(&xas, index) just
before it: xas.xa_node could be left pointing to a stale node, if there
was concurrent activity on the file which transformed its xarray.
I tried inserting xas_pause()s, but then even bootup crashed on that
VM_BUG_ON_PAGE(): there appears to be a subtle "nextness" implicit in
xas_pause().
xas_next() and xas_pause() are good for use in simple loops, but not in
this one: xas_set() worked well until now, so use xas_set(&xas, index)
explicitly at the head of the loop; and change that VM_BUG_ON_PAGE() not
to need its own xas_set(), and not to interfere with the xa_state (which
would probably stop the crashes from xas_pause(), but I trust that less).
The user-visible effects of this bug (if VM_BUG_ONs are configured out)
would be data loss and data leak - potentially - though in practice I
expect it is more likely that a subsequent check (e.g. on mapping or on
nr_none) would notice an inconsistency, and just abandon the collapse.
Link: https://lore.kernel.org/linux-mm/[email protected]/
Fixes: c8a8f3b4a95a ("mm/khugepaged: fix iteration in collapse_file")
Signed-off-by: Hugh Dickins <[email protected]>
Cc: <[email protected]>
---
mm/khugepaged.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 3beb4ad2ee5e..78c8d5d8b628 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1937,9 +1937,9 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
}
} while (1);
- xas_set(&xas, start);
for (index = start; index < end; index++) {
- page = xas_next(&xas);
+ xas_set(&xas, index);
+ page = xas_load(&xas);
VM_BUG_ON(index != xas.xa_index);
if (is_shmem) {
@@ -1954,7 +1954,6 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
result = SCAN_TRUNCATED;
goto xa_locked;
}
- xas_set(&xas, index + 1);
}
if (!shmem_charge(mapping->host, 1)) {
result = SCAN_FAIL;
@@ -2090,7 +2089,7 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
xas_lock_irq(&xas);
- VM_BUG_ON_PAGE(page != xas_load(&xas), page);
+ VM_BUG_ON_PAGE(page != xa_load(xas.xa, index), page);
/*
* We control three references to the page:
--
2.35.3
On Wed, 28 Jun 2023 at 21:31, Hugh Dickins <[email protected]> wrote:
>
> There is no xas_pause(&xas) in collapse_file()'s main loop, at the points
> where it does xas_unlock_irq(&xas) and then continues.
Thanks for reminding me. Now applied,
Linus