From: Hugh Dickins <hughd@google.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: "Sasha Levin" <sashal@kernel.org>,
"Hugh Dickins" <hughd@google.com>,
stable@vger.kernel.org, willy@infradead.org,
akpm@linux-foundation.org, david@redhat.com, jannh@google.com,
"José Pekkarinen" <jose.pekkarinen@foxhound.fi>,
kirill.shutemov@linux.intel.com
Subject: Re: [PATCH 5.15.y] mm: fix oops when filemap_map_pmd) without prealloc_pte
Date: Mon, 11 Dec 2023 09:18:06 -0800 (PST) [thread overview]
Message-ID: <ac3262ba-7398-eef1-1d80-8425e394dc6f@google.com> (raw)
In-Reply-To: <2023121120-degree-target-cd18@gregkh>
[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]
On Mon, 11 Dec 2023, Greg KH wrote:
> On Sat, Dec 09, 2023 at 09:18:42PM -0800, Hugh Dickins wrote:
> > syzbot reports oops in lockdep's __lock_acquire(), called from
> > __pte_offset_map_lock() called from filemap_map_pages(); or when I run the
> > repro, the oops comes in pmd_install(), called from filemap_map_pmd()
> > called from filemap_map_pages(), just before the __pte_offset_map_lock().
> >
> > The problem is that filemap_map_pmd() has been assuming that when it finds
> > pmd_none(), a page table has already been prepared in prealloc_pte; and
> > indeed do_fault_around() has been careful to preallocate one there, when
> > it finds pmd_none(): but what if *pmd became none in between?
> >
> > My 6.6 mods in mm/khugepaged.c, avoiding mmap_lock for write, have made it
> > easy for *pmd to be cleared while servicing a page fault; but even before
> > those, a huge *pmd might be zapped while a fault is serviced.
> >
> > The difference in symptomatic stack traces comes from the "memory model"
> > in use: pmd_install() uses pmd_populate() uses page_to_pfn(): in some
> > models that is strict, and will oops on the NULL prealloc_pte; in other
> > models, it will construct a bogus value to be populated into *pmd, then
> > __pte_offset_map_lock() oops when trying to access split ptlock pointer
> > (or some other symptom in normal case of ptlock embedded not pointer).
> >
> > Link: https://lore.kernel.org/linux-mm/20231115065506.19780-1-jose.pekkarinen@foxhound.fi/
> > Link: https://lkml.kernel.org/r/6ed0c50c-78ef-0719-b3c5-60c0c010431c@google.com
> > Fixes: f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() codepaths")
> > Signed-off-by: Hugh Dickins <hughd@google.com>
> > Reported-and-tested-by: syzbot+89edd67979b52675ddec@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/linux-mm/0000000000005e44550608a0806c@google.com/
> > Reviewed-by: David Hildenbrand <david@redhat.com>
> > Cc: Jann Horn <jannh@google.com>,
> > Cc: José Pekkarinen <jose.pekkarinen@foxhound.fi>
> > Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> > Cc: <stable@vger.kernel.org> [5.12+]
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > (cherry picked from commit 9aa1345d66b8132745ffb99b348b1492088da9e2)
> > Signed-off-by: Hugh Dickins <hughd@google.com>
> > ---
> > mm/filemap.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Now queued up, thanks.
>
> greg k-h
Thanks Greg: but Sasha appears to have a competing queue, in which
he's cherry-picked in a dependency from 5.16 ahead of a clean
cherry-pick for this one.
He posted his the next day: I expect it's more to your taste (pull
in dependency rather than edit cherry-pick) and it looked fine to me.
Please sort out with Sasha which goes forward, either will do.
Hugh
next prev parent reply other threads:[~2023-12-11 17:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-10 5:18 [PATCH 5.15.y] mm: fix oops when filemap_map_pmd) without prealloc_pte Hugh Dickins
2023-12-11 13:19 ` Greg KH
2023-12-11 17:18 ` Hugh Dickins [this message]
2023-12-11 18:18 ` Greg KH
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=ac3262ba-7398-eef1-1d80-8425e394dc6f@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=jose.pekkarinen@foxhound.fi \
--cc=kirill.shutemov@linux.intel.com \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--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 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.