From: Catalin Marinas <catalin.marinas@arm.com>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, patches@lists.linux.dev,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, linux@roeck-us.net, shuah@kernel.org,
patches@kernelci.org, lkft-triage@lists.linaro.org,
pavel@denx.de, jonathanh@nvidia.com, f.fainelli@gmail.com,
sudipm.mukherjee@gmail.com, srw@sladewatkins.net, rwarsow@gmx.de,
conor@kernel.org, hargar@microsoft.com, broonie@kernel.org,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, linux-mm <linux-mm@kvack.org>,
Anders Roxell <anders.roxell@linaro.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
willy@infradead.org, Pankaj Raghav <p.raghav@samsung.com>,
Yang Shi <yang@os.amperecomputing.com>,
David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
Date: Wed, 19 Feb 2025 14:00:27 +0000 [thread overview]
Message-ID: <Z7Xj-zIe-Sa1syG7@arm.com> (raw)
In-Reply-To: <CA+G9fYtqBxt+JwSLCcVBchh94GVRhbo9rTP26ceJ=sf4MDo61Q@mail.gmail.com>
On Mon, Feb 17, 2025 at 05:00:43PM +0530, Naresh Kamboju wrote:
> On Sat, 8 Feb 2025 at 16:54, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
[...]
> We observed a kernel warning on QEMU-ARM64 and FVP while running the
> newly added selftest: arm64: check_hugetlb_options. This issue appears
> on 6.6.76 onward and 6.12.13 onward, as reported in the stable review [1].
> However, the test case passes successfully on stable 6.13.
>
> The selftests: arm64: check_hugetlb_options test was introduced following
> the recent upgrade of kselftest test sources to the stable 6.13 branch.
> As you are aware, LKFT runs the latest kselftest sources (from stable
> 6.13.x) on 6.12.x, 6.6.x, and older kernels for validation purposes.
>
> From Anders' bisection results, we identified that the missing patch on
> 6.12 is likely causing this regression:
>
> First fixed commit:
> [25c17c4b55def92a01e3eecc9c775a6ee25ca20f]
> hugetlb: arm64: add MTE support
I wouldn't backport this and it's definitely not a fix for the problem
reported.
> Could you confirm whether this patch is eligible for backporting to
> 6.12 and 6.6 kernels?
> If backporting is not an option, we will need to skip running this
> test case on older kernels.
>
> > 1)
> > Regression on qemu-arm64 and FVP noticed this kernel warning running
> > selftests: arm64: check_hugetlb_options test case on 6.6.76-rc1 and
> > 6.6.76-rc2.
> >
> > Test regression: WARNING-arch-arm64-mm-copypage-copy_highpage
> >
> > ------------[ cut here ]------------
> > [ 96.920028] WARNING: CPU: 1 PID: 3611 at
> > arch/arm64/mm/copypage.c:29 copy_highpage
> > (arch/arm64/include/asm/mte.h:87)
> > [ 96.922100] Modules linked in: crct10dif_ce sm3_ce sm3 sha3_ce
> > sha512_ce sha512_arm64 fuse drm backlight ip_tables x_tables
> > [ 96.925603] CPU: 1 PID: 3611 Comm: check_hugetlb_o Not tainted 6.6.76-rc2 #1
> > [ 96.926956] Hardware name: linux,dummy-virt (DT)
> > [ 96.927695] pstate: 43402009 (nZcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> > [ 96.928687] pc : copy_highpage (arch/arm64/include/asm/mte.h:87)
> > [ 96.929037] lr : copy_highpage
> > (arch/arm64/include/asm/alternative-macros.h:232
> > arch/arm64/include/asm/cpufeature.h:443
> > arch/arm64/include/asm/cpufeature.h:504
> > arch/arm64/include/asm/cpufeature.h:814 arch/arm64/mm/copypage.c:27)
> > [ 96.929399] sp : ffff800088aa3ab0
> > [ 96.930232] x29: ffff800088aa3ab0 x28: 00000000000001ff x27: 0000000000000000
> > [ 96.930784] x26: 0000000000000000 x25: 0000ffff9b800000 x24: 0000ffff9b9ff000
> > [ 96.931402] x23: fffffc0003257fc0 x22: ffff0000c95ff000 x21: ffff0000c93ff000
> > [ 96.932054] x20: fffffc0003257fc0 x19: fffffc000324ffc0 x18: 0000ffff9b800000
> > [ 96.933357] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> > [ 96.934091] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
> > [ 96.935095] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
> > [ 96.935982] x8 : 0bfffc0001800000 x7 : 0000000000000000 x6 : 0000000000000000
> > [ 96.936536] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
> > [ 96.937089] x2 : 0000000000000000 x1 : ffff0000c9600000 x0 : ffff0000c9400080
> > [ 96.939431] Call trace:
> > [ 96.939920] copy_highpage (arch/arm64/include/asm/mte.h:87)
> > [ 96.940443] copy_user_highpage (arch/arm64/mm/copypage.c:40)
> > [ 96.940963] copy_user_large_folio (mm/memory.c:5977 mm/memory.c:6109)
> > [ 96.941535] hugetlb_wp (mm/hugetlb.c:5701)
> > [ 96.941948] hugetlb_fault (mm/hugetlb.c:6237)
> > [ 96.942344] handle_mm_fault (mm/memory.c:5330)
> > [ 96.942794] do_page_fault (arch/arm64/mm/fault.c:513
> > arch/arm64/mm/fault.c:626)
> > [ 96.943341] do_mem_abort (arch/arm64/mm/fault.c:846)
> > [ 96.943797] el0_da (arch/arm64/kernel/entry-common.c:133
> > arch/arm64/kernel/entry-common.c:144
> > arch/arm64/kernel/entry-common.c:547)
> > [ 96.944229] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:0)
> > [ 96.944765] el0t_64_sync (arch/arm64/kernel/entry.S:599)
> > [ 96.945383] ---[ end trace 0000000000000000 ]---
Prior to commit 25c17c4b55de ("hugetlb: arm64: add mte support"), there
was no hugetlb support with MTE, so the above code path should not
happen - it seems to get a PROT_MTE hugetlb page which should have been
prevented by arch_validate_flags(). Or something else corrupts the page
flags and we end up with some random PG_mte_tagged set.
Does this happen with vanilla 6.6? I wonder whether we always had this
issue, only that we haven't noticed until the hugetlb MTE kselftest.
There were some backports in this area but I don't see how they would
have caused this.
--
Catalin
next prev parent reply other threads:[~2025-02-19 14:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
2025-02-06 18:07 ` Florian Fainelli
2025-02-07 11:55 ` Jon Hunter
2025-02-07 11:59 ` Jon Hunter
2025-02-07 11:58 ` Jon Hunter
2025-02-07 19:37 ` Mark Brown
2025-02-07 23:17 ` [PATCH 6.6] " Hardik Garg
2025-02-08 2:13 ` [PATCH 6.6 000/389] " Peter Schneider
2025-02-08 5:25 ` Barry K. Nathan
2025-02-08 7:21 ` Greg Kroah-Hartman
2025-02-08 11:24 ` Naresh Kamboju
2025-02-17 11:30 ` Naresh Kamboju
2025-02-17 11:37 ` Greg Kroah-Hartman
2025-02-19 11:46 ` Naresh Kamboju
2025-02-19 12:13 ` Greg Kroah-Hartman
2025-02-19 14:00 ` Catalin Marinas [this message]
2025-02-19 15:43 ` Dan Carpenter
2025-02-19 15:52 ` Dan Carpenter
2025-02-19 15:52 ` Catalin Marinas
2025-02-19 17:18 ` Catalin Marinas
2025-02-19 18:09 ` Greg Kroah-Hartman
2025-02-19 19:16 ` Catalin Marinas
2025-02-19 18:31 ` Yang Shi
2025-02-09 15:19 ` Guenter Roeck
2025-02-11 8:34 ` Greg Kroah-Hartman
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=Z7Xj-zIe-Sa1syG7@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=conor@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=david@redhat.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=hargar@microsoft.com \
--cc=herbert@gondor.apana.org.au \
--cc=jonathanh@nvidia.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@roeck-us.net \
--cc=lkft-triage@lists.linaro.org \
--cc=naresh.kamboju@linaro.org \
--cc=p.raghav@samsung.com \
--cc=patches@kernelci.org \
--cc=patches@lists.linux.dev \
--cc=pavel@denx.de \
--cc=rwarsow@gmx.de \
--cc=shuah@kernel.org \
--cc=srw@sladewatkins.net \
--cc=stable@vger.kernel.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
--cc=yang@os.amperecomputing.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 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.