Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Naresh Kamboju]

On Thu, 6 Feb 2025 at 21:36, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.6.76 release.
> There are 389 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 08 Feb 2025 15:51:12 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.76-rc2.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


There are three different regressions found and reporting here,
We are working on bisecting and investigating these issues,

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 ]---

2)
Regression on Gravition-V4 boot has noticed this kernel warning while
booting the
6.6.76-rc1 and 6.6.76-rc2.

Boot regression: WARNING-crypto-testmgr-alg_test

[   62.438009] ------------[ cut here ]------------
[   62.440316] alg: self-tests for stdrng using drbg_nopr_hmac_sha512
failed (rc=-22)
[   62.440324] WARNING: CPU: 1 PID: 158 at crypto/testmgr.c:5936
alg_test (crypto/testmgr.c:5936 (discriminator 1))
[   62.443128] Modules linked in:
[   62.443729] CPU: 1 PID: 158 Comm: cryptomgr_test Not tainted 6.6.76-rc2 #1
[   62.445029] Hardware name: Amazon EC2 r8g.large/, BIOS 1.0 11/1/2018
[   62.446248] pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[   62.447588] pc : alg_test (crypto/testmgr.c:5936 (discriminator 1))
[   62.448306] lr : alg_test (crypto/testmgr.c:5936 (discriminator 1))
[   62.449029] sp : ffff8000817c3d40
[   62.449683] x29: ffff8000817c3d40 x28: ffffcf33cddf6388 x27: 0000000000000059
[   62.451056] x26: 00000000ffffffea x25: 00000000ffffffff x24: ffffcf33cf699000
[   62.452417] x23: ffffcf33cddf6388 x22: 000000000000000c x21: ffff0003c4627a80
[   62.453786] x20: ffff0003c4627a00 x19: 0000000000000058 x18: 00000000fffffffe
[   62.455163] x17: 72282064656c6961 x16: 6620323135616873 x15: ffff8000817c3950
[   62.456545] x14: 0000000000000000 x13: 00000000000003f2 x12: 00000000ffffffea
[   62.457927] x11: 00000000ffffefff x10: ffffcf33cf23d2d8 x9 : ffffcf33cf1e5278
[   62.459319] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8
[   62.460697] x5 : 0000000000000fff x4 : 0000000000000000 x3 : 0000000000000000
[   62.462069] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003c4697000
[   62.463445] Call trace:
[   62.463940] alg_test (crypto/testmgr.c:5936 (discriminator 1))
[   62.464595] cryptomgr_test (crypto/algboss.c:182)
[   62.465314] kthread (kernel/kthread.c:388)
[   62.465920] ret_from_fork (arch/arm64/kernel/entry.S:862)
[   62.466619] ---[ end trace 0000000000000000 ]---

3)
Regression on qemu-arm64 while running LTP fs fs_fill the following
kernel warning found this was seen from the last rc round also.

Boot regression: WARNING-fs-buffer-mark_buffer_dirty

<3>[  942.039675] Buffer I/O error on dev loop0, logical block 153753,
lost async page write
<3>[  942.040482] I/O error, dev loop0, sector 1222152 op 0x1:(WRITE)
flags 0x100000 phys_seg 1 prio class 2
<3>[  942.041273] Buffer I/O error on dev loop0, logical block 152769,
lost async page write
<4>[  942.048676] ------------[ cut here ]------------
<4>[ 942.051768] WARNING: CPU: 1 PID: 6290 at fs/buffer.c:1188
mark_buffer_dirty (fs/buffer.c:0)
<4>[  942.057394] Modules linked in: btrfs xor xor_neon raid6_pq
zstd_compress libcrc32c tun crct10dif_ce sm3_ce sm3 sha3_ce sha512_ce
sha512_arm64 fuse drm backlight ip_tables x_tables
<4>[  942.068545] CPU: 1 PID: 6290 Comm: fs_fill Not tainted 6.6.76-rc2 #1
<4>[  942.071224] Hardware name: linux,dummy-virt (DT)
<4>[  942.074657] pstate: 83402009 (Nzcv daif +PAN -UAO +TCO +DIT
-SSBS BTYPE=--)
<4>[ 942.076823] pc : mark_buffer_dirty (fs/buffer.c:0)
<4>[ 942.077221] lr : mark_buffer_dirty_inode (fs/buffer.c:682)
<4>[  942.077523] sp : ffff8000822d3820
<4>[  942.077766] x29: ffff8000822d3820 x28: 00000000000278f1 x27:
0000000000000001
<4>[  942.081352] x26: 0000000000000000 x25: 0000000000001000 x24:
ffff8000822d38e0
<4>[  942.081928] x23: ffff8000822d39bc x22: ffff8000822d3920 x21:
ffff0000ce30d1d0
<4>[  942.082381] x20: ffff0000c0480b78 x19: ffff0000fabb3a90 x18:
00000059f17bbe9e
<4>[  942.082841] x17: 0000000000000000 x16: 0000000000000000 x15:
00000000c6a2c000
<4>[  942.084209] x14: 0000000000000001 x13: ffff8000822d0000 x12:
ffff8000822d4000
<4>[  942.085009] x11: edcfb2436f68dc00 x10: 000000000000d84f x9 :
ffffb9036e21ef44
<4>[  942.085793] x8 : 0000000000000418 x7 : 00000000000275d8 x6 :
ffff0000e2a98400
<4>[  942.086706] x5 : ffff0000c77db560 x4 : 00000000ffffffff x3 :
ffff8000822d3710
<4>[  942.087819] x2 : ffff0000c29b4200 x1 : ffff0000ce30d058 x0 :
ffff0000fabb3a90
<4>[  942.091430] Call trace:
<4>[ 942.093962] mark_buffer_dirty (fs/buffer.c:0)
<4>[ 942.095407] ext2_get_blocks (fs/ext2/inode.c:602 fs/ext2/inode.c:765)
<4>[ 942.097279] ext2_get_block (fs/ext2/inode.c:793)
<4>[ 942.098201] __block_write_begin_int (fs/buffer.c:2127)
<4>[ 942.098948] block_write_begin (fs/buffer.c:2235)
<4>[ 942.099493] ext2_write_begin (fs/ext2/inode.c:924)
<4>[ 942.099933] generic_perform_write (mm/filemap.c:4006)
<4>[ 942.102488] __generic_file_write_iter (mm/filemap.c:0)
<4>[ 942.103176] generic_file_write_iter (mm/filemap.c:4125)
<4>[ 942.103607] ext2_file_write_iter (fs/ext2/file.c:0)
<4>[ 942.104071] do_iter_write (fs/read_write.c:736 fs/read_write.c:860)
<4>[ 942.104499] vfs_writev (fs/read_write.c:933)
<4>[ 942.104901] do_writev (fs/read_write.c:976)
<4>[ 942.105307] __arm64_sys_writev (fs/read_write.c:1046)
<4>[ 942.105565] invoke_syscall (arch/arm64/kernel/syscall.c:52)
<4>[ 942.106973] el0_svc_common (include/linux/thread_info.h:127
arch/arm64/kernel/syscall.c:142)
<4>[ 942.107316] do_el0_svc (arch/arm64/kernel/syscall.c:154)
<4>[ 942.107639] el0_svc (arch/arm64/kernel/entry-common.c:133
arch/arm64/kernel/entry-common.c:144
arch/arm64/kernel/entry-common.c:679)
<4>[ 942.110407] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:731)
<4>[ 942.111160] el0t_64_sync (arch/arm64/kernel/entry.S:599)
<4>[  942.113215] ---[ end trace 0000000000000000 ]---

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

## Source
* kernel version: 6.6.76-rc2
* git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git sha: e5534ef3ba233d5207312b032b12b1d3788e94ac
* git describe: v6.6.75-390-ge5534ef3ba23
* project details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23

##Boot log fvp-aemva-qemu-arm64
qemu-arm64 log:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228347/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/log
fvp-aemva log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228386/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/log
fvp-aemva details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228386/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/details/
fvp-aemva-qemu-arm64 history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228347/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/history/


##Boot log graviton-v4
graviton-v4 log:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/log
graviton-v4 details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/details/
gravition-v4 history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/history/

##Boot log qemu-arm64
* build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/details/
qemu-arm64 fsbuffer details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27229114/suite/log-parser-test/test/exception-warning-cpu-pid-at-fsbuffer-mark_buffer_dirty/details/
qemu-arm64 fsbuffer history:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27229261/suite/log-parser-test/test/exception-warning-cpu-pid-at-fsbuffer-mark_buffer_dirty/history/


--
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Naresh Kamboju]

On Sat, 8 Feb 2025 at 16:54, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Thu, 6 Feb 2025 at 21:36, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 6.6.76 release.
> > There are 389 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 08 Feb 2025 15:51:12 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.76-rc2.gz
> > or in the git tree and branch at:
> >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
>
> There are three different regressions found and reporting here,
> We are working on bisecting and investigating these issues,

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

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 ]---
>
> 2)
> Regression on Gravition-V4 boot has noticed this kernel warning while
> booting the
> 6.6.76-rc1 and 6.6.76-rc2.
>
> Boot regression: WARNING-crypto-testmgr-alg_test
>
> [   62.438009] ------------[ cut here ]------------
> [   62.440316] alg: self-tests for stdrng using drbg_nopr_hmac_sha512
> failed (rc=-22)
> [   62.440324] WARNING: CPU: 1 PID: 158 at crypto/testmgr.c:5936
> alg_test (crypto/testmgr.c:5936 (discriminator 1))
> [   62.443128] Modules linked in:
> [   62.443729] CPU: 1 PID: 158 Comm: cryptomgr_test Not tainted 6.6.76-rc2 #1
> [   62.445029] Hardware name: Amazon EC2 r8g.large/, BIOS 1.0 11/1/2018
> [   62.446248] pstate: 63400005 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
> [   62.447588] pc : alg_test (crypto/testmgr.c:5936 (discriminator 1))
> [   62.448306] lr : alg_test (crypto/testmgr.c:5936 (discriminator 1))
> [   62.449029] sp : ffff8000817c3d40
> [   62.449683] x29: ffff8000817c3d40 x28: ffffcf33cddf6388 x27: 0000000000000059
> [   62.451056] x26: 00000000ffffffea x25: 00000000ffffffff x24: ffffcf33cf699000
> [   62.452417] x23: ffffcf33cddf6388 x22: 000000000000000c x21: ffff0003c4627a80
> [   62.453786] x20: ffff0003c4627a00 x19: 0000000000000058 x18: 00000000fffffffe
> [   62.455163] x17: 72282064656c6961 x16: 6620323135616873 x15: ffff8000817c3950
> [   62.456545] x14: 0000000000000000 x13: 00000000000003f2 x12: 00000000ffffffea
> [   62.457927] x11: 00000000ffffefff x10: ffffcf33cf23d2d8 x9 : ffffcf33cf1e5278
> [   62.459319] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000057fa8
> [   62.460697] x5 : 0000000000000fff x4 : 0000000000000000 x3 : 0000000000000000
> [   62.462069] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003c4697000
> [   62.463445] Call trace:
> [   62.463940] alg_test (crypto/testmgr.c:5936 (discriminator 1))
> [   62.464595] cryptomgr_test (crypto/algboss.c:182)
> [   62.465314] kthread (kernel/kthread.c:388)
> [   62.465920] ret_from_fork (arch/arm64/kernel/entry.S:862)
> [   62.466619] ---[ end trace 0000000000000000 ]---
>
> 3)
> Regression on qemu-arm64 while running LTP fs fs_fill the following
> kernel warning found this was seen from the last rc round also.
>
> Boot regression: WARNING-fs-buffer-mark_buffer_dirty
>
> <3>[  942.039675] Buffer I/O error on dev loop0, logical block 153753,
> lost async page write
> <3>[  942.040482] I/O error, dev loop0, sector 1222152 op 0x1:(WRITE)
> flags 0x100000 phys_seg 1 prio class 2
> <3>[  942.041273] Buffer I/O error on dev loop0, logical block 152769,
> lost async page write
> <4>[  942.048676] ------------[ cut here ]------------
> <4>[ 942.051768] WARNING: CPU: 1 PID: 6290 at fs/buffer.c:1188
> mark_buffer_dirty (fs/buffer.c:0)
> <4>[  942.057394] Modules linked in: btrfs xor xor_neon raid6_pq
> zstd_compress libcrc32c tun crct10dif_ce sm3_ce sm3 sha3_ce sha512_ce
> sha512_arm64 fuse drm backlight ip_tables x_tables
> <4>[  942.068545] CPU: 1 PID: 6290 Comm: fs_fill Not tainted 6.6.76-rc2 #1
> <4>[  942.071224] Hardware name: linux,dummy-virt (DT)
> <4>[  942.074657] pstate: 83402009 (Nzcv daif +PAN -UAO +TCO +DIT
> -SSBS BTYPE=--)
> <4>[ 942.076823] pc : mark_buffer_dirty (fs/buffer.c:0)
> <4>[ 942.077221] lr : mark_buffer_dirty_inode (fs/buffer.c:682)
> <4>[  942.077523] sp : ffff8000822d3820
> <4>[  942.077766] x29: ffff8000822d3820 x28: 00000000000278f1 x27:
> 0000000000000001
> <4>[  942.081352] x26: 0000000000000000 x25: 0000000000001000 x24:
> ffff8000822d38e0
> <4>[  942.081928] x23: ffff8000822d39bc x22: ffff8000822d3920 x21:
> ffff0000ce30d1d0
> <4>[  942.082381] x20: ffff0000c0480b78 x19: ffff0000fabb3a90 x18:
> 00000059f17bbe9e
> <4>[  942.082841] x17: 0000000000000000 x16: 0000000000000000 x15:
> 00000000c6a2c000
> <4>[  942.084209] x14: 0000000000000001 x13: ffff8000822d0000 x12:
> ffff8000822d4000
> <4>[  942.085009] x11: edcfb2436f68dc00 x10: 000000000000d84f x9 :
> ffffb9036e21ef44
> <4>[  942.085793] x8 : 0000000000000418 x7 : 00000000000275d8 x6 :
> ffff0000e2a98400
> <4>[  942.086706] x5 : ffff0000c77db560 x4 : 00000000ffffffff x3 :
> ffff8000822d3710
> <4>[  942.087819] x2 : ffff0000c29b4200 x1 : ffff0000ce30d058 x0 :
> ffff0000fabb3a90
> <4>[  942.091430] Call trace:
> <4>[ 942.093962] mark_buffer_dirty (fs/buffer.c:0)
> <4>[ 942.095407] ext2_get_blocks (fs/ext2/inode.c:602 fs/ext2/inode.c:765)
> <4>[ 942.097279] ext2_get_block (fs/ext2/inode.c:793)
> <4>[ 942.098201] __block_write_begin_int (fs/buffer.c:2127)
> <4>[ 942.098948] block_write_begin (fs/buffer.c:2235)
> <4>[ 942.099493] ext2_write_begin (fs/ext2/inode.c:924)
> <4>[ 942.099933] generic_perform_write (mm/filemap.c:4006)
> <4>[ 942.102488] __generic_file_write_iter (mm/filemap.c:0)
> <4>[ 942.103176] generic_file_write_iter (mm/filemap.c:4125)
> <4>[ 942.103607] ext2_file_write_iter (fs/ext2/file.c:0)
> <4>[ 942.104071] do_iter_write (fs/read_write.c:736 fs/read_write.c:860)
> <4>[ 942.104499] vfs_writev (fs/read_write.c:933)
> <4>[ 942.104901] do_writev (fs/read_write.c:976)
> <4>[ 942.105307] __arm64_sys_writev (fs/read_write.c:1046)
> <4>[ 942.105565] invoke_syscall (arch/arm64/kernel/syscall.c:52)
> <4>[ 942.106973] el0_svc_common (include/linux/thread_info.h:127
> arch/arm64/kernel/syscall.c:142)
> <4>[ 942.107316] do_el0_svc (arch/arm64/kernel/syscall.c:154)
> <4>[ 942.107639] el0_svc (arch/arm64/kernel/entry-common.c:133
> arch/arm64/kernel/entry-common.c:144
> arch/arm64/kernel/entry-common.c:679)
> <4>[ 942.110407] el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:731)
> <4>[ 942.111160] el0t_64_sync (arch/arm64/kernel/entry.S:599)
> <4>[  942.113215] ---[ end trace 0000000000000000 ]---
>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
> ## Source
> * kernel version: 6.6.76-rc2
> * git tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> * git sha: e5534ef3ba233d5207312b032b12b1d3788e94ac
> * git describe: v6.6.75-390-ge5534ef3ba23
> * project details:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23
>
> ##Boot log fvp-aemva-qemu-arm64
> qemu-arm64 log:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228347/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/log
> fvp-aemva log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228386/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/log
> fvp-aemva details:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228386/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/details/
> fvp-aemva-qemu-arm64 history:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228347/suite/log-parser-test/test/exception-warning-cpu-pid-at-archarm64mmcopypage-copy_highpage/history/
>
>
> ##Boot log graviton-v4
> graviton-v4 log:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/log
> graviton-v4 details:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/details/
> gravition-v4 history:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/history/
>
> ##Boot log qemu-arm64
> * build log: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27228382/suite/log-parser-test/test/warning-warning-0m1mcpu-pid-at-cryptotestmgr-alg_test/details/
> qemu-arm64 fsbuffer details:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27229114/suite/log-parser-test/test/exception-warning-cpu-pid-at-fsbuffer-mark_buffer_dirty/details/
> qemu-arm64 fsbuffer history:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.75-390-ge5534ef3ba23/testrun/27229261/suite/log-parser-test/test/exception-warning-cpu-pid-at-fsbuffer-mark_buffer_dirty/history/
>
>
> --
> Linaro LKFT
> https://lkft.linaro.org

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Greg Kroah-Hartman]

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:
> >
> > On Thu, 6 Feb 2025 at 21:36, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > This is the start of the stable review cycle for the 6.6.76 release.
> > > There are 389 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sat, 08 Feb 2025 15:51:12 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.76-rc2.gz
> > > or in the git tree and branch at:
> > >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> >
> > There are three different regressions found and reporting here,
> > We are working on bisecting and investigating these issues,
> 
> 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
> 
> 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.

The test case itself should properly "skip" if the feature is not
present in the kernel.  Why not fix that up instead?

thanks,

greg k-h

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Naresh Kamboju]

On Mon, 17 Feb 2025 at 17:07, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> 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:
> > >
> > > On Thu, 6 Feb 2025 at 21:36, Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > This is the start of the stable review cycle for the 6.6.76 release.
> > > > There are 389 patches in this series, all will be posted as a response
> > > > to this one.  If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Sat, 08 Feb 2025 15:51:12 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > > The whole patch series can be found in one patch at:
> > > >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.76-rc2.gz
> > > > or in the git tree and branch at:
> > > >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> > > > and the diffstat can be found below.
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > >
> > > There are three different regressions found and reporting here,
> > > We are working on bisecting and investigating these issues,
> >
> > 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
> >
> > 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.
>
> The test case itself should properly "skip" if the feature is not
> present in the kernel.  Why not fix that up instead?

The reported test gets PASS at the end, but generates kernel warning
while running the test case (always reproducible) on 6.12 and 6.6.

The reported warning was not seen on stable 6.13.

# Test log:

# selftests: arm64: check_hugetlb_options
# 1..12
# ok 1 Check hugetlb memory with private mapping, sync error mode,
mmap memory and tag check off
# ok 2 Check hugetlb memory with private mapping, no error mode, mmap
memory and tag check off
# ok 3 Check hugetlb memory with private mapping, sync error mode,
mmap memory and tag check on
# ok 4 Check hugetlb memory with private mapping, sync error mode,
mmap/mprotect memory and tag check on
# ok 5 Check hugetlb memory with private mapping, async error mode,
mmap memory and tag check on
# ok 6 Check hugetlb memory with private mapping, async error mode,
mmap/mprotect memory and tag check on
# ok 7 Check clear PROT_MTE flags with private mapping, sync error
mode and mmap memory
# ok 8 Check clear PROT_MTE flags with private mapping and sync error
mode and mmap/mprotect memory
# ok 9 Check child hugetlb memory with private mapping, precise mode
and mmap memory
------------[ 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 ]---#
ok 10 Check child hugetlb memory with private mapping, precise mode
and mmap memory
# ok 11 Check child hugetlb memory with private mapping, precise mode
and mmap/mprotect memory
# ok 12 Check child hugetlb memory with private mapping, precise mode
and mmap/mprotect memory
# # Totals: pass:12 fail:0 xfail:0 xpass:0 skip:0 error:0
ok 2 selftests: arm64: check_hugetlb_options

Links:
 - https://lore.kernel.org/all/CA+G9fYtqBxt+JwSLCcVBchh94GVRhbo9rTP26ceJ=sf4MDo61Q@mail.gmail.com/

>
> thanks,
>
> greg k-h

- Naresh

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Greg Kroah-Hartman]

On Wed, Feb 19, 2025 at 05:16:19PM +0530, Naresh Kamboju wrote:
> On Mon, 17 Feb 2025 at 17:07, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > 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:
> > > >
> > > > On Thu, 6 Feb 2025 at 21:36, Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > This is the start of the stable review cycle for the 6.6.76 release.
> > > > > There are 389 patches in this series, all will be posted as a response
> > > > > to this one.  If anyone has any issues with these being applied, please
> > > > > let me know.
> > > > >
> > > > > Responses should be made by Sat, 08 Feb 2025 15:51:12 +0000.
> > > > > Anything received after that time might be too late.
> > > > >
> > > > > The whole patch series can be found in one patch at:
> > > > >         https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.76-rc2.gz
> > > > > or in the git tree and branch at:
> > > > >         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> > > > > and the diffstat can be found below.
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > >
> > > > There are three different regressions found and reporting here,
> > > > We are working on bisecting and investigating these issues,
> > >
> > > 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
> > >
> > > 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.
> >
> > The test case itself should properly "skip" if the feature is not
> > present in the kernel.  Why not fix that up instead?
> 
> The reported test gets PASS at the end, but generates kernel warning
> while running the test case (always reproducible) on 6.12 and 6.6.
> 
> The reported warning was not seen on stable 6.13.

So this implies that userspace can cause a kernel warning?  That means
it can cause a DoS, that's not good at all.

So the commit you mention actually fixes a bug then?  Otherwise this
feels really odd, as that means that any kernel without that change can
crash this way.  What changed to cause this to happen?

thanks,

greg k-h

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Catalin Marinas]

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

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Dan Carpenter]

Hi Catalin and Yang Shi,

What's happening is that we backport the latest kselftests and run
them on the old kernels.  This is a supported thing so kselftests
are supposed to be able to handle that.

So we need to modify the testing/selftests/arm64/mte/check_hugetlb_options.c
to check if the feature is present and disable the test for older
kernels.

This is not an issue with the stable kernel it's an issue with the
new selftest.

regards,
dan carpenter

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Dan Carpenter]

On Wed, Feb 19, 2025 at 06:43:52PM +0300, Dan Carpenter wrote:
> Hi Catalin and Yang Shi,
> 
> What's happening is that we backport the latest kselftests and run
> them on the old kernels.  This is a supported thing so kselftests
> are supposed to be able to handle that.
> 
> So we need to modify the testing/selftests/arm64/mte/check_hugetlb_options.c
> to check if the feature is present and disable the test for older
> kernels.
> 
> This is not an issue with the stable kernel it's an issue with the
> new selftest.

Gar, nope.  It's me who is wrong.  Greg is right.  Why is usespace
triggering a WARN_ON_ONCE()?

regards,
dan carpenter

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Catalin Marinas]

Hi Dan,

On Wed, Feb 19, 2025 at 06:43:52PM +0300, Dan Carpenter wrote:
> What's happening is that we backport the latest kselftests and run
> them on the old kernels.  This is a supported thing so kselftests
> are supposed to be able to handle that.

Yes, I do this occasionally as well (a single rootfs with the kselftests
that I use with different kernels).

> So we need to modify the testing/selftests/arm64/mte/check_hugetlb_options.c
> to check if the feature is present and disable the test for older
> kernels.

I'm not worried about the test failing yet, we can solve it later, but
rather the WARN_ON_ONCE() in the arm64 copy_highpage(). We should not
trigger this condition since hugetlb vmas don't have VM_MTE_ALLOWED set,
so PROT_MTE mappings should be refused and the test shouldn't get any
mapping.

I tried vanilla 6.6 and it trips over as well, so something wrong in how
we handle MTE hugetlb pages. I'm looking into it.

-- 
Catalin

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Catalin Marinas]

On Wed, Feb 19, 2025 at 02:00:27PM +0000, Catalin Marinas wrote:
> > On Sat, 8 Feb 2025 at 16:54, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > > 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.

The problem is in the arm64 arch_calc_vm_flag_bits() as it returns
VM_MTE_ALLOWED for any MAP_ANONYMOUS ignoring MAP_HUGETLB (it's been
doing this since day 1 of MTE). The implementation does handle the
hugetlb file mmap() correctly but not the MAP_ANONYMOUS case.

The fix would be something like below:

-----------------8<--------------------------
diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
index 5966ee4a6154..8ff5d88c9f12 100644
--- a/arch/arm64/include/asm/mman.h
+++ b/arch/arm64/include/asm/mman.h
@@ -28,7 +28,8 @@ static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags)
 	 * backed by tags-capable memory. The vm_flags may be overridden by a
 	 * filesystem supporting MTE (RAM-based).
 	 */
-	if (system_supports_mte() && (flags & MAP_ANONYMOUS))
+	if (system_supports_mte() &&
+	    ((flags & MAP_ANONYMOUS) && !(flags & MAP_HUGETLB)))
 		return VM_MTE_ALLOWED;

 	return 0;
-------------------8<-----------------------

This fix won't make sense for mainline since it supports MAP_HUGETLB
already.

Greg, are you ok with a stable-only fix as above or you'd rather see the
full 25c17c4b55de ("hugetlb: arm64: add mte support") backported?

Thanks.

-- 
Catalin

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Greg Kroah-Hartman]

On Wed, Feb 19, 2025 at 05:18:24PM +0000, Catalin Marinas wrote:
> On Wed, Feb 19, 2025 at 02:00:27PM +0000, Catalin Marinas wrote:
> > > On Sat, 8 Feb 2025 at 16:54, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > > > 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.
> 
> The problem is in the arm64 arch_calc_vm_flag_bits() as it returns
> VM_MTE_ALLOWED for any MAP_ANONYMOUS ignoring MAP_HUGETLB (it's been
> doing this since day 1 of MTE). The implementation does handle the
> hugetlb file mmap() correctly but not the MAP_ANONYMOUS case.
> 
> The fix would be something like below:
> 
> -----------------8<--------------------------
> diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
> index 5966ee4a6154..8ff5d88c9f12 100644
> --- a/arch/arm64/include/asm/mman.h
> +++ b/arch/arm64/include/asm/mman.h
> @@ -28,7 +28,8 @@ static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags)
>  	 * backed by tags-capable memory. The vm_flags may be overridden by a
>  	 * filesystem supporting MTE (RAM-based).
>  	 */
> -	if (system_supports_mte() && (flags & MAP_ANONYMOUS))
> +	if (system_supports_mte() &&
> +	    ((flags & MAP_ANONYMOUS) && !(flags & MAP_HUGETLB)))
>  		return VM_MTE_ALLOWED;
> 
>  	return 0;
> -------------------8<-----------------------
> 
> This fix won't make sense for mainline since it supports MAP_HUGETLB
> already.
> 
> Greg, are you ok with a stable-only fix as above or you'd rather see the
> full 25c17c4b55de ("hugetlb: arm64: add mte support") backported?

A stable-only fix for this is fine, thanks!  Can you send it with a
changelog and I'll queue it up.  Does it also need to go to older
kernels as well?

thanks,

greg k-h

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Catalin Marinas]

On Wed, Feb 19, 2025 at 07:09:26PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2025 at 05:18:24PM +0000, Catalin Marinas wrote:
> > The problem is in the arm64 arch_calc_vm_flag_bits() as it returns
> > VM_MTE_ALLOWED for any MAP_ANONYMOUS ignoring MAP_HUGETLB (it's been
> > doing this since day 1 of MTE). The implementation does handle the
> > hugetlb file mmap() correctly but not the MAP_ANONYMOUS case.
> > 
> > The fix would be something like below:
> > 
> > -----------------8<--------------------------
> > diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
> > index 5966ee4a6154..8ff5d88c9f12 100644
> > --- a/arch/arm64/include/asm/mman.h
> > +++ b/arch/arm64/include/asm/mman.h
> > @@ -28,7 +28,8 @@ static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags)
> >  	 * backed by tags-capable memory. The vm_flags may be overridden by a
> >  	 * filesystem supporting MTE (RAM-based).
> >  	 */
> > -	if (system_supports_mte() && (flags & MAP_ANONYMOUS))
> > +	if (system_supports_mte() &&
> > +	    ((flags & MAP_ANONYMOUS) && !(flags & MAP_HUGETLB)))
> >  		return VM_MTE_ALLOWED;
> > 
> >  	return 0;
> > -------------------8<-----------------------
> > 
> > This fix won't make sense for mainline since it supports MAP_HUGETLB
> > already.
> > 
> > Greg, are you ok with a stable-only fix as above or you'd rather see the
> > full 25c17c4b55de ("hugetlb: arm64: add mte support") backported?
> 
> A stable-only fix for this is fine, thanks!  Can you send it with a
> changelog and I'll queue it up.  Does it also need to go to older
> kernels as well?

5.10, that's when we got MTE support in. There may be some slight
variations depending on how far 5baf8b037deb ("mm: refactor
arch_calc_vm_flag_bits() and arm64 MTE handling") got backported. This
goes together with deb0f6562884 ("mm/mmap: undo ->mmap() when
arch_validate_flags() fails"), so they may actually go all the way to
5.10.

I'll prepare the patches tomorrow, give them a try and send to stable.

Thanks.

-- 
Catalin

Re: [PATCH 6.6 000/389] 6.6.76-rc2 review

[Yang Shi]

On 2/19/25 9:18 AM, Catalin Marinas wrote:
> On Wed, Feb 19, 2025 at 02:00:27PM +0000, Catalin Marinas wrote:
>>> On Sat, 8 Feb 2025 at 16:54, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>>>> 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.
> The problem is in the arm64 arch_calc_vm_flag_bits() as it returns
> VM_MTE_ALLOWED for any MAP_ANONYMOUS ignoring MAP_HUGETLB (it's been
> doing this since day 1 of MTE). The implementation does handle the
> hugetlb file mmap() correctly but not the MAP_ANONYMOUS case.

Yeah, thanks for catching this. mmap'ing to hugetlbfs file should return 
-EINVAL on prior 6.13 kernel. So it should be just anonymous mapping.

Thanks,
Yang


>
> The fix would be something like below:
>
> -----------------8<--------------------------
> diff --git a/arch/arm64/include/asm/mman.h b/arch/arm64/include/asm/mman.h
> index 5966ee4a6154..8ff5d88c9f12 100644
> --- a/arch/arm64/include/asm/mman.h
> +++ b/arch/arm64/include/asm/mman.h
> @@ -28,7 +28,8 @@ static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags)
>   	 * backed by tags-capable memory. The vm_flags may be overridden by a
>   	 * filesystem supporting MTE (RAM-based).
>   	 */
> -	if (system_supports_mte() && (flags & MAP_ANONYMOUS))
> +	if (system_supports_mte() &&
> +	    ((flags & MAP_ANONYMOUS) && !(flags & MAP_HUGETLB)))
>   		return VM_MTE_ALLOWED;
>
>   	return 0;
> -------------------8<-----------------------
>
> This fix won't make sense for mainline since it supports MAP_HUGETLB
> already.
>
> Greg, are you ok with a stable-only fix as above or you'd rather see the
> full 25c17c4b55de ("hugetlb: arm64: add mte support") backported?
>
> Thanks.
>