From: Hugh Dickins <hughd@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Hugh Dickins <hughd@google.com>,
Suren Baghdasaryan <surenb@google.com>,
Yang Shi <shy828301@gmail.com>, Michal Hocko <mhocko@suse.com>,
Vlastimil Babka <vbabka@suse.cz>,
syzbot <syzbot+b591856e0f0139f83023@syzkaller.appspotmail.com>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [mm?] kernel BUG in vma_replace_policy
Date: Fri, 15 Sep 2023 19:54:16 -0700 (PDT) [thread overview]
Message-ID: <ace766bc-49c1-8399-9548-5faac04e87c8@google.com> (raw)
In-Reply-To: <ZQShw8lESIBle7GF@casper.infradead.org>
On Fri, 15 Sep 2023, Matthew Wilcox wrote:
> On Thu, Sep 14, 2023 at 09:26:15PM -0700, Hugh Dickins wrote:
> > On Thu, 14 Sep 2023, Suren Baghdasaryan wrote:
> > > Yes, I just finished running the reproducer on both upstream and
> > > linux-next builds listed in
> > > https://syzkaller.appspot.com/bug?extid=b591856e0f0139f83023 and the
> > > problem does not happen anymore.
> > > I'm fine with your suggestion too, just wanted to point out it would
> > > introduce change in the behavior. Let me know how you want to proceed.
> >
> > Well done, identifying the mysterious cause of this problem:
> > I'm glad to hear that you've now verified that hypothesis.
> >
> > You're right, it would be a regression to follow Matthew's suggestion.
> >
> > Traditionally, modulo bugs and inconsistencies, the queue_pages_range()
> > phase of do_mbind() has done the best it can, gathering all the pages it
> > can that need migration, even if some were missed; and proceeds to do the
> > mbind_range() phase if there was nothing "seriously" wrong (a gap causing
> > -EFAULT). Then at the end, if MPOL_MF_STRICT was set, and not all the
> > pages could be migrated (or MOVE was not specified and not all pages
> > were well placed), it returns -EIO rather than 0 to inform the caller
> > that not all could be done.
> >
> > There have been numerous tweaks, but I think most importantly
> > 5.3's d883544515aa ("mm: mempolicy: make the behavior consistent when
> > MPOL_MF_MOVE* and MPOL_MF_STRICT were specified") added those "return 1"s
> > which stop the pagewalk early. In my opinion, not an improvement - makes
> > it harder to get mbind() to do the best job it can (or is it justified as
> > what you're asking for if you say STRICT?).
>
> I suspect you agree that it's inconsistent to stop early. Userspace
> doesn't know at which point we found an unmovable page, so it can't behave
> rationally. Perhaps we should remove the 'early stop' and attempt to
> migrate every page in the range, whether it's before or after the first
> unmovable page?
Yes, that's what I was arguing for, and how it was done in olden days.
Though (after Yang Shi's following comments, and looking back at my
last attempted patch here) I may disagree with myself about the right
behavior in the MPOL_MF_STRICT case.
Hugh
next prev parent reply other threads:[~2023-09-16 2:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 1:03 [syzbot] [mm?] kernel BUG in vma_replace_policy syzbot
[not found] ` <20230906061902.591996-1-eadavis@sina.com>
2023-09-06 12:06 ` [PATCH] mm: as the same logic with queue_pages_range Matthew Wilcox
2023-09-12 5:20 ` kernel test robot
2023-09-13 9:10 ` [LTP] " Cyril Hrubis
2023-09-08 18:04 ` [syzbot] [mm?] kernel BUG in vma_replace_policy syzbot
2023-09-12 5:30 ` Matthew Wilcox
2023-09-12 6:09 ` syzbot
2023-09-12 14:55 ` Matthew Wilcox
2023-09-12 15:03 ` Suren Baghdasaryan
2023-09-12 16:00 ` Suren Baghdasaryan
2023-09-13 16:05 ` Suren Baghdasaryan
2023-09-13 16:46 ` Suren Baghdasaryan
2023-09-14 18:20 ` Suren Baghdasaryan
2023-09-14 19:09 ` Matthew Wilcox
2023-09-14 20:00 ` Suren Baghdasaryan
2023-09-14 20:53 ` Suren Baghdasaryan
2023-09-14 21:24 ` Matthew Wilcox
2023-09-14 22:21 ` Suren Baghdasaryan
2023-09-15 4:26 ` Hugh Dickins
2023-09-15 16:09 ` Suren Baghdasaryan
2023-09-15 18:05 ` Suren Baghdasaryan
2023-09-16 2:43 ` Hugh Dickins
2023-09-18 21:20 ` Suren Baghdasaryan
2023-09-15 18:26 ` Matthew Wilcox
2023-09-16 2:54 ` Hugh Dickins [this message]
2023-09-16 1:35 ` Yang Shi
2023-09-16 3:57 ` Hugh Dickins
2023-09-18 22:34 ` Yang Shi
2023-09-19 0:34 ` Hugh Dickins
[not found] <20230909034207.5816-1-hdanton@sina.com>
2023-09-09 4:43 ` syzbot
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=ace766bc-49c1-8399-9548-5faac04e87c8@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shy828301@gmail.com \
--cc=surenb@google.com \
--cc=syzbot+b591856e0f0139f83023@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).