From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>, Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Arnd Bergmann <arnd@arndb.de>,
Mike Kravetz <mike.kravetz@oracle.com>,
Muchun Song <muchun.song@linux.dev>,
SeongJae Park <sj@kernel.org>,
Uladzislau Rezki <urezki@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
Lorenzo Stoakes <lstoakes@gmail.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Peter Xu <peterx@redhat.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Qi Zheng <zhengqi.arch@bytedance.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, sparclinux@vger.kernel.org,
linux-mm@kvack.org, stable@vger.kernel.org
Subject: Re: [PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64
Date: Fri, 22 Sep 2023 11:23:12 +0200 [thread overview]
Message-ID: <2023092208-sitcom-playpen-b62d@gregkh> (raw)
In-Reply-To: <7c5c2c00-d657-44fd-b478-743b43c57e8a@arm.com>
On Thu, Sep 21, 2023 at 05:35:54PM +0100, Ryan Roberts wrote:
> On 21/09/2023 17:30, Andrew Morton wrote:
> > On Thu, 21 Sep 2023 17:19:59 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:
> >
> >> Hi All,
> >>
> >> This series fixes a bug in arm64's implementation of set_huge_pte_at(), which
> >> can result in an unprivileged user causing a kernel panic. The problem was
> >> triggered when running the new uffd poison mm selftest for HUGETLB memory. This
> >> test (and the uffd poison feature) was merged for v6.6-rc1. However, upon
> >> inspection there are multiple other pre-existing paths that can trigger this
> >> bug.
> >>
> >> Ideally, I'd like to get this fix in for v6.6 if possible? And I guess it should
> >> be backported too, given there are call sites where this can theoretically
> >> happen that pre-date v6.6-rc1 (I've cc'ed stable@vger.kernel.org).
> >
> > This gets you a naggygram from Greg. The way to request a backport is
> > to add cc:stable to all the changelogs. I'll make that change to my copy.
>
> Ahh, sorry about that... I just got the same moan from the kernel test robot too.
>
> >
> >
> >> Ryan Roberts (8):
> >> parisc: hugetlb: Convert set_huge_pte_at() to take vma
> >> powerpc: hugetlb: Convert set_huge_pte_at() to take vma
> >> riscv: hugetlb: Convert set_huge_pte_at() to take vma
> >> s390: hugetlb: Convert set_huge_pte_at() to take vma
> >> sparc: hugetlb: Convert set_huge_pte_at() to take vma
> >> mm: hugetlb: Convert set_huge_pte_at() to take vma
> >> arm64: hugetlb: Convert set_huge_pte_at() to take vma
> >> arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries
> >>
> >> arch/arm64/include/asm/hugetlb.h | 2 +-
> >> arch/arm64/mm/hugetlbpage.c | 22 ++++----------
> >> arch/parisc/include/asm/hugetlb.h | 2 +-
> >> arch/parisc/mm/hugetlbpage.c | 4 +--
> >> .../include/asm/nohash/32/hugetlb-8xx.h | 3 +-
> >> arch/powerpc/mm/book3s64/hugetlbpage.c | 2 +-
> >> arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 2 +-
> >> arch/powerpc/mm/nohash/8xx.c | 2 +-
> >> arch/powerpc/mm/pgtable.c | 7 ++++-
> >> arch/riscv/include/asm/hugetlb.h | 2 +-
> >> arch/riscv/mm/hugetlbpage.c | 3 +-
> >> arch/s390/include/asm/hugetlb.h | 8 +++--
> >> arch/s390/mm/hugetlbpage.c | 8 ++++-
> >> arch/sparc/include/asm/hugetlb.h | 8 +++--
> >> arch/sparc/mm/hugetlbpage.c | 8 ++++-
> >> include/asm-generic/hugetlb.h | 6 ++--
> >> include/linux/hugetlb.h | 6 ++--
> >> mm/damon/vaddr.c | 2 +-
> >> mm/hugetlb.c | 30 +++++++++----------
> >> mm/migrate.c | 2 +-
> >> mm/rmap.c | 10 +++----
> >> mm/vmalloc.c | 5 +++-
> >> 22 files changed, 80 insertions(+), 64 deletions(-)
> >
> > Looks scary but it's actually a fairly modest patchset. It could
> > easily be all rolled into a single patch for ease of backporting.
> > Maybe Greg has an opinion?
>
> Yes, I thought about doing that; or perhaps 2 patches - one for the interface
> change across all arches and core code, and one for the actual bug fix?
I have no issues with taking patch series, or one big patch, into stable
trees, they just have to match up with what is in Linus's tree.
so if it makes more sense to have this as a series (like you did here),
wonderful, make it a patch series. Do not go out of your way to do
things differently just for stable kernels, that is not necessary or
needed at all.
thanks,
greg k-h
prev parent reply other threads:[~2023-09-22 9:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-21 16:19 Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 1/8] parisc: hugetlb: Convert set_huge_pte_at() to take vma Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 2/8] powerpc: " Ryan Roberts
2023-09-21 18:43 ` Christophe Leroy
2023-09-22 6:44 ` Christophe Leroy
2023-09-22 7:19 ` Ryan Roberts
2023-09-22 6:56 ` Christophe Leroy
2023-09-22 7:33 ` Ryan Roberts
2023-09-22 8:10 ` Christophe Leroy
2023-09-22 8:41 ` Ryan Roberts
2023-09-22 9:14 ` Christophe Leroy
2023-09-22 9:37 ` Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 3/8] riscv: " Ryan Roberts
2023-09-22 7:54 ` Alexandre Ghiti
2023-09-22 8:36 ` Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 4/8] s390: " Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 5/8] sparc: " Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 6/8] mm: " Ryan Roberts
2023-09-22 1:37 ` SeongJae Park
2023-09-21 16:20 ` [PATCH v1 7/8] arm64: " Ryan Roberts
2023-09-21 16:20 ` [PATCH v1 8/8] arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries Ryan Roberts
2023-09-22 2:54 ` Qi Zheng
2023-09-22 7:40 ` Ryan Roberts
2023-09-22 7:54 ` Qi Zheng
2023-09-22 9:35 ` Ryan Roberts
2023-09-22 9:58 ` Qi Zheng
2023-09-21 16:30 ` [PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64 Andrew Morton
2023-09-21 16:35 ` Ryan Roberts
2023-09-21 17:38 ` Catalin Marinas
2023-09-22 7:41 ` Ryan Roberts
2023-09-22 9:23 ` Greg Kroah-Hartman [this message]
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=2023092208-sitcom-playpen-b62d@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=axelrasmussen@google.com \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hch@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lstoakes@gmail.com \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterx@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=sj@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
--cc=zhengqi.arch@bytedance.com \
/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