* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
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
` (7 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Florian Fainelli @ 2025-02-06 18:07 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow,
conor, hargar, broonie
On 2/6/25 08:06, Greg Kroah-Hartman 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
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
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
` (6 subsequent siblings)
8 siblings, 1 reply; 25+ messages in thread
From: Jon Hunter @ 2025-02-07 11:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
linux-tegra, stable
On Thu, 06 Feb 2025 17:06:18 +0100, Greg Kroah-Hartman 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
Failures detected for Tegra ...
Test results for stable-v6.6:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 114 pass, 2 fail
Linux version: 6.6.76-rc2-ge5534ef3ba23
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Test failures: tegra194-p2972-0000: boot.py
tegra194-p2972-0000: pm-system-suspend.sh
Jon
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-07 11:55 ` Jon Hunter
@ 2025-02-07 11:59 ` Jon Hunter
0 siblings, 0 replies; 25+ messages in thread
From: Jon Hunter @ 2025-02-07 11:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, f.fainelli, sudipm.mukherjee, srw, rwarsow,
conor, hargar, broonie, linux-tegra, stable
On 07/02/2025 11:55, Jon Hunter wrote:
> On Thu, 06 Feb 2025 17:06:18 +0100, Greg Kroah-Hartman 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
>
> Failures detected for Tegra ...
>
> Test results for stable-v6.6:
> 10 builds: 10 pass, 0 fail
> 26 boots: 26 pass, 0 fail
> 116 tests: 114 pass, 2 fail
>
> Linux version: 6.6.76-rc2-ge5534ef3ba23
> Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
> tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
> tegra20-ventana, tegra210-p2371-2180,
> tegra210-p3450-0000, tegra30-cardhu-a04
>
> Test failures: tegra194-p2972-0000: boot.py
> tegra194-p2972-0000: pm-system-suspend.sh
Ignore this report. The latest is the correct one. All is passing. Sorry
for the noise!
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
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:58 ` Jon Hunter
2025-02-07 19:37 ` Mark Brown
` (5 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Jon Hunter @ 2025-02-07 11:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
linux-tegra, stable
On Thu, 06 Feb 2025 17:06:18 +0100, Greg Kroah-Hartman 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
All tests passing for Tegra ...
Test results for stable-v6.6:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
116 tests: 116 pass, 0 fail
Linux version: 6.6.76-rc2-ge5534ef3ba23
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2025-02-07 11:58 ` Jon Hunter
@ 2025-02-07 19:37 ` Mark Brown
2025-02-07 23:17 ` [PATCH 6.6] " Hardik Garg
` (4 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Mark Brown @ 2025-02-07 19:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
On Thu, Feb 06, 2025 at 05:06:18PM +0100, Greg Kroah-Hartman 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.
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6] 6.6.76-rc2 review
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2025-02-07 19:37 ` Mark Brown
@ 2025-02-07 23:17 ` Hardik Garg
2025-02-08 2:13 ` [PATCH 6.6 000/389] " Peter Schneider
` (3 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Hardik Garg @ 2025-02-07 23:17 UTC (permalink / raw)
To: gregkh
Cc: akpm, broonie, conor, f.fainelli, hargar, jonathanh, linux-kernel,
linux, lkft-triage, patches, patches, pavel, rwarsow, shuah, srw,
stable, sudipm.mukherjee, torvalds
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.6.76-rc2 on x86 and arm64 Azure VM.
Kernel binary size for x86 build:
text data bss dec hex filename
27313145 16699374 4653056 48665575 2e693e7 vmlinux
Kernel binary size for arm64 build:
text data bss dec hex filename
34662746 13840386 970368 49473500 2f2e7dc vmlinux
Tested-by: Hardik Garg <hargar@linux.microsoft.com>
Thanks,
Hardik
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2025-02-07 23:17 ` [PATCH 6.6] " Hardik Garg
@ 2025-02-08 2:13 ` Peter Schneider
2025-02-08 5:25 ` Barry K. Nathan
` (2 subsequent siblings)
8 siblings, 0 replies; 25+ messages in thread
From: Peter Schneider @ 2025-02-08 2:13 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, hargar, broonie
Am 06.02.2025 um 17:06 schrieb Greg Kroah-Hartman:
> 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.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg
oddities or regressions found.
Tested-by: Peter Schneider <pschneider1968@googlemail.com>
Beste Grüße,
Peter Schneider
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@googlemail.com
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@gmail.com
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
` (5 preceding siblings ...)
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-09 15:19 ` Guenter Roeck
8 siblings, 1 reply; 25+ messages in thread
From: Barry K. Nathan @ 2025-02-08 5:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, hargar, broonie, herbert, herbert.xu
On 2/6/25 08:06, Greg Kroah-Hartman 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.
[snip]
> Herbert Xu <herbert@gondor.apana.org.au>
> crypto: api - Fix boot-up self-test race
[snip]
I mentioned in an email to the stable mailing list earlier this week
that the crypto-api-fix-boot-up-self-test-race patch, on my systems, is
causing a one-minute freeze followed by a crypto self-test failure. See
the log excerpt below for an example. (In that email I erroneously said
the affected kernel was 6.6.76-rc1. It was 6.6.75 plus stable-queue
patches, but not actually 6.6.76-rc1. Sorry for my mistake.)
I'm still experiencing this with 6.6.76-rc2. As before, reverting
"crypto: api - Fix boot-up self-test race" fixes it. I also tried
testing 6.6.75 plus this patch, and that reproduces the problem. In case
it might have been a compiler issue, I tried upgrading my build system
from Debian bookworm to trixie, but the issue reproduces with trixie's
gcc 14.2 just as it does with bookworm's gcc 12.2.
I also tested 6.12.13-rc2 and 6.13.2-rc2. Those kernels work fine in my
testing and do not reproduce this issue.
To be clear, it's personally not a real problem for me if 6.6.76 is
released with this patch included -- if necessary, I can just keep
reverting this patch until I get my systems upgraded to 6.12. However, I
figure this is still worth reporting, in case it eventually turns out to
be something that doesn't only affect me.
Anyway, I'll keep digging to see if I can figure out more. Since
essentially the same patch that's breaking 6.6 is working just fine on
6.12 and 6.13, I feel like I should be able to find more clues.
(However, I may be busy for the next several days, so I'm not sure how
soon I'll be able to make progress.)
Log excerpt:
[ 5.928519] ima: No TPM chip found, activating TPM-bypass!
[ 5.939514] ima: Allocated hash algorithm: sha256
[ 5.948952] ima: No architecture policies found
[ 5.958056] evm: Initialising EVM extended attributes:
[ 5.968355] evm: security.selinux
[ 5.975045] evm: security.SMACK64 (disabled)
[ 5.983607] evm: security.SMACK64EXEC (disabled)
[ 5.992864] evm: security.SMACK64TRANSMUTE (disabled)
[ 6.002986] evm: security.SMACK64MMAP (disabled)
[ 6.012242] evm: security.apparmor
[ 6.019073] evm: security.ima
[ 6.025034] evm: security.capability
[ 6.032210] evm: HMAC attrs: 0x1
[ 68.455379] DRBG: could not allocate digest TFM handle: hmac(sha512)
[ 68.468106] alg: drbg: Failed to reset rng
[ 68.476319] alg: drbg: Test 0 failed for drbg_nopr_hmac_sha512
[ 68.488002] alg: self-tests for stdrng using drbg_nopr_hmac_sha512
failed (rc=-22)
[ 68.488004] ------------[ cut here ]------------
[ 68.512425] alg: self-tests for stdrng using drbg_nopr_hmac_sha512
failed (rc=-22)
[ 68.512443] WARNING: CPU: 0 PID: 76 at crypto/testmgr.c:5936
alg_test+0x49e/0x610
[ 68.543729] Modules linked in:
[ 68.549864] CPU: 0 PID: 76 Comm: cryptomgr_test Not tainted 6.6.76-rc2 #1
[ 68.563454] Hardware name: Gigabyte Technology Co., Ltd.
G41MT-S2PT/G41MT-S2PT, BIOS F2 12/06/2011
[ 68.581411] RIP: 0010:alg_test+0x49e/0x610
[ 68.589645] Code: de 48 89 df 89 04 24 e8 70 ed fe ff 44 8b 0c 24 e9
bc fc ff ff 44 89 c9 48 89 ea 4c 89 ee 48 c7 c7 f8 9a ad 8d e8 32 75 b2
ff <0f> 0b 44 8b 0c 24 e9 a1 fe ff ff 8b 05 61 04 c2 01 85 c0 74 56 83
[ 68.627206] RSP: 0018:ffffbd1fc02efe10 EFLAGS: 00010286
[ 68.637676] RAX: 0000000000000000 RBX: 00000000ffffffff RCX:
c0000000ffffefff
[ 68.651977] RDX: 0000000000000000 RSI: 00000000ffffefff RDI:
0000000000000001
[ 68.666258] RBP: ffff981cc09a0200 R08: 0000000000000000 R09:
ffffbd1fc02efc98
[ 68.680542] R10: 0000000000000003 R11: ffffffff8dcd1368 R12:
0000000000000058
[ 68.694842] R13: ffff981cc09a0280 R14: 0000000000000058 R15:
0000000000000058
[ 68.709125] FS: 0000000000000000(0000) GS:ffff981df7c00000(0000)
knlGS:0000000000000000
[ 68.725330] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 68.736857] CR2: 00007f1f895112e0 CR3: 0000000083220000 CR4:
00000000000406f0
[ 68.751140] Call Trace:
[ 68.756063] <TASK>
[ 68.760293] ? alg_test+0x49e/0x610
[ 68.767296] ? __warn+0x81/0x130
[ 68.773778] ? alg_test+0x49e/0x610
[ 68.780781] ? report_bug+0x171/0x1a0
[ 68.788130] ? console_unlock+0x78/0x120
[ 68.795999] ? handle_bug+0x58/0x90
[ 68.803000] ? exc_invalid_op+0x17/0x70
[ 68.810699] ? asm_exc_invalid_op+0x1a/0x20
[ 68.819103] ? alg_test+0x49e/0x610
[ 68.826108] ? finish_task_switch.isra.0+0x90/0x2d0
[ 68.835882] ? __schedule+0x3c8/0xb00
[ 68.843231] ? __pfx_cryptomgr_test+0x10/0x10
[ 68.851967] cryptomgr_test+0x24/0x40
[ 68.859317] kthread+0xe5/0x120
[ 68.865627] ? __pfx_kthread+0x10/0x10
[ 68.873166] ret_from_fork+0x31/0x50
[ 68.880343] ? __pfx_kthread+0x10/0x10
[ 68.887881] ret_from_fork_asm+0x1b/0x30
[ 68.895753] </TASK>
[ 68.900154] ---[ end trace 0000000000000000 ]---
--
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-08 5:25 ` Barry K. Nathan
@ 2025-02-08 7:21 ` Greg Kroah-Hartman
0 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2025-02-08 7:21 UTC (permalink / raw)
To: Barry K. Nathan
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie, herbert,
herbert.xu
On Fri, Feb 07, 2025 at 09:25:08PM -0800, Barry K. Nathan wrote:
> On 2/6/25 08:06, Greg Kroah-Hartman 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.
> [snip]
> > Herbert Xu <herbert@gondor.apana.org.au>
> > crypto: api - Fix boot-up self-test race
> [snip]
> I mentioned in an email to the stable mailing list earlier this week that
> the crypto-api-fix-boot-up-self-test-race patch, on my systems, is causing a
> one-minute freeze followed by a crypto self-test failure. See the log
> excerpt below for an example. (In that email I erroneously said the affected
> kernel was 6.6.76-rc1. It was 6.6.75 plus stable-queue patches, but not
> actually 6.6.76-rc1. Sorry for my mistake.)
>
> I'm still experiencing this with 6.6.76-rc2. As before, reverting "crypto:
> api - Fix boot-up self-test race" fixes it. I also tried testing 6.6.75 plus
> this patch, and that reproduces the problem. In case it might have been a
> compiler issue, I tried upgrading my build system from Debian bookworm to
> trixie, but the issue reproduces with trixie's gcc 14.2 just as it does with
> bookworm's gcc 12.2.
>
> I also tested 6.12.13-rc2 and 6.13.2-rc2. Those kernels work fine in my
> testing and do not reproduce this issue.
>
> To be clear, it's personally not a real problem for me if 6.6.76 is released
> with this patch included -- if necessary, I can just keep reverting this
> patch until I get my systems upgraded to 6.12. However, I figure this is
> still worth reporting, in case it eventually turns out to be something that
> doesn't only affect me.
>
> Anyway, I'll keep digging to see if I can figure out more. Since essentially
> the same patch that's breaking 6.6 is working just fine on 6.12 and 6.13, I
> feel like I should be able to find more clues. (However, I may be busy for
> the next several days, so I'm not sure how soon I'll be able to make
> progress.)
Thanks for the info, for some reason I thought this was hitting an
already released kernel. I'll go drop this patch from the 6.6.y queue
now, thanks for pointing it out again.
greg k-h
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2025-02-08 5:25 ` Barry K. Nathan
@ 2025-02-08 11:24 ` Naresh Kamboju
2025-02-17 11:30 ` Naresh Kamboju
2025-02-09 15:19 ` Guenter Roeck
8 siblings, 1 reply; 25+ messages in thread
From: Naresh Kamboju @ 2025-02-08 11:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
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 14:00 ` Catalin Marinas
0 siblings, 2 replies; 25+ messages in thread
From: Naresh Kamboju @ 2025-02-17 11:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, Catalin Marinas, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
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 14:00 ` Catalin Marinas
1 sibling, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2025-02-17 11:37 UTC (permalink / raw)
To: Naresh Kamboju
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, Catalin Marinas, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-17 11:37 ` Greg Kroah-Hartman
@ 2025-02-19 11:46 ` Naresh Kamboju
2025-02-19 12:13 ` Greg Kroah-Hartman
0 siblings, 1 reply; 25+ messages in thread
From: Naresh Kamboju @ 2025-02-19 11:46 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, Catalin Marinas, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 11:46 ` Naresh Kamboju
@ 2025-02-19 12:13 ` Greg Kroah-Hartman
0 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2025-02-19 12:13 UTC (permalink / raw)
To: Naresh Kamboju
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, Catalin Marinas, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-17 11:30 ` Naresh Kamboju
2025-02-17 11:37 ` Greg Kroah-Hartman
@ 2025-02-19 14:00 ` Catalin Marinas
2025-02-19 15:43 ` Dan Carpenter
2025-02-19 17:18 ` Catalin Marinas
1 sibling, 2 replies; 25+ messages in thread
From: Catalin Marinas @ 2025-02-19 14:00 UTC (permalink / raw)
To: Naresh Kamboju
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds, akpm,
linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 14:00 ` Catalin Marinas
@ 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
1 sibling, 2 replies; 25+ messages in thread
From: Dan Carpenter @ 2025-02-19 15:43 UTC (permalink / raw)
To: Catalin Marinas, Yang Shi
Cc: Naresh Kamboju, Greg Kroah-Hartman, stable, patches, linux-kernel,
torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor,
hargar, broonie, Linux Crypto Mailing List, linux-fsdevel,
linux-mm, Anders Roxell, Arnd Bergmann, Herbert Xu, willy,
Pankaj Raghav, Yang Shi, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 15:43 ` Dan Carpenter
@ 2025-02-19 15:52 ` Dan Carpenter
2025-02-19 15:52 ` Catalin Marinas
1 sibling, 0 replies; 25+ messages in thread
From: Dan Carpenter @ 2025-02-19 15:52 UTC (permalink / raw)
To: Catalin Marinas, Yang Shi
Cc: Naresh Kamboju, Greg Kroah-Hartman, stable, patches, linux-kernel,
torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow, conor,
hargar, broonie, Linux Crypto Mailing List, linux-fsdevel,
linux-mm, Anders Roxell, Arnd Bergmann, Herbert Xu, willy,
Pankaj Raghav, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 15:43 ` Dan Carpenter
2025-02-19 15:52 ` Dan Carpenter
@ 2025-02-19 15:52 ` Catalin Marinas
1 sibling, 0 replies; 25+ messages in thread
From: Catalin Marinas @ 2025-02-19 15:52 UTC (permalink / raw)
To: Dan Carpenter
Cc: Yang Shi, Naresh Kamboju, Greg Kroah-Hartman, stable, patches,
linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw, rwarsow,
conor, hargar, broonie, Linux Crypto Mailing List, linux-fsdevel,
linux-mm, Anders Roxell, Arnd Bergmann, Herbert Xu, willy,
Pankaj Raghav, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 14:00 ` Catalin Marinas
2025-02-19 15:43 ` Dan Carpenter
@ 2025-02-19 17:18 ` Catalin Marinas
2025-02-19 18:09 ` Greg Kroah-Hartman
2025-02-19 18:31 ` Yang Shi
1 sibling, 2 replies; 25+ messages in thread
From: Catalin Marinas @ 2025-02-19 17:18 UTC (permalink / raw)
To: Greg Kroah-Hartman, Naresh Kamboju
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, David Hildenbrand
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
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
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
1 sibling, 1 reply; 25+ messages in thread
From: Greg Kroah-Hartman @ 2025-02-19 18:09 UTC (permalink / raw)
To: Catalin Marinas
Cc: Naresh Kamboju, stable, patches, linux-kernel, torvalds, akpm,
linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 18:09 ` Greg Kroah-Hartman
@ 2025-02-19 19:16 ` Catalin Marinas
0 siblings, 0 replies; 25+ messages in thread
From: Catalin Marinas @ 2025-02-19 19:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Naresh Kamboju, stable, patches, linux-kernel, torvalds, akpm,
linux, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
Yang Shi, David Hildenbrand
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-19 17:18 ` Catalin Marinas
2025-02-19 18:09 ` Greg Kroah-Hartman
@ 2025-02-19 18:31 ` Yang Shi
1 sibling, 0 replies; 25+ messages in thread
From: Yang Shi @ 2025-02-19 18:31 UTC (permalink / raw)
To: Catalin Marinas, Greg Kroah-Hartman, Naresh Kamboju
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, hargar, broonie,
Linux Crypto Mailing List, linux-fsdevel, linux-mm, Anders Roxell,
Dan Carpenter, Arnd Bergmann, Herbert Xu, willy, Pankaj Raghav,
David Hildenbrand
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.
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-06 16:06 [PATCH 6.6 000/389] 6.6.76-rc2 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2025-02-08 11:24 ` Naresh Kamboju
@ 2025-02-09 15:19 ` Guenter Roeck
2025-02-11 8:34 ` Greg Kroah-Hartman
8 siblings, 1 reply; 25+ messages in thread
From: Guenter Roeck @ 2025-02-09 15:19 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, hargar, broonie
On 2/6/25 08:06, Greg Kroah-Hartman 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.
>
[ ... ]
> Hongbo Li <lihongbo22@huawei.com>
> hostfs: fix the host directory parse when mounting.
This patch results in:
Building um:defconfig ... failed
--------------
Error log:
fs/hostfs/hostfs_kern.c:972:9: error: implicit declaration of function 'fsparam_string_empty'; did you mean 'fsparam_string'? [-Werror=implicit-function-declaration]
972 | fsparam_string_empty("hostfs", Opt_hostfs),
because fsparam_string_empty() is not declared globally in v6.6.y.
The patch declaring it is 7b30851a70645 ("fs_parser: move fsparam_string_empty()
helper into header"). Applying that patch on top of 6.6.76 fixes the problem.
The problem only affects "um" builds since hostfs (CONFIG_HOSTFS) is only available
and used there. Oddly enough, the patch breaks the build of this file instead of
fixing the problem it claims to fix, and it looks like no one noticed.
On top of that, "hostfs: convert hostfs to use the new mount API" was obviously
not tested. It looks like a substantial change which would definitely warrant
testing when backported.
That makes me wonder: Should I stop build testing "um" images in older kernels ?
Thanks,
Guenter
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 6.6 000/389] 6.6.76-rc2 review
2025-02-09 15:19 ` Guenter Roeck
@ 2025-02-11 8:34 ` Greg Kroah-Hartman
0 siblings, 0 replies; 25+ messages in thread
From: Greg Kroah-Hartman @ 2025-02-11 8:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, hargar, broonie
On Sun, Feb 09, 2025 at 07:19:33AM -0800, Guenter Roeck wrote:
> On 2/6/25 08:06, Greg Kroah-Hartman 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.
> >
> [ ... ]
>
> > Hongbo Li <lihongbo22@huawei.com>
> > hostfs: fix the host directory parse when mounting.
>
> This patch results in:
>
> Building um:defconfig ... failed
> --------------
> Error log:
> fs/hostfs/hostfs_kern.c:972:9: error: implicit declaration of function 'fsparam_string_empty'; did you mean 'fsparam_string'? [-Werror=implicit-function-declaration]
> 972 | fsparam_string_empty("hostfs", Opt_hostfs),
>
> because fsparam_string_empty() is not declared globally in v6.6.y.
>
> The patch declaring it is 7b30851a70645 ("fs_parser: move fsparam_string_empty()
> helper into header"). Applying that patch on top of 6.6.76 fixes the problem.
>
> The problem only affects "um" builds since hostfs (CONFIG_HOSTFS) is only available
> and used there. Oddly enough, the patch breaks the build of this file instead of
> fixing the problem it claims to fix, and it looks like no one noticed.
> On top of that, "hostfs: convert hostfs to use the new mount API" was obviously
> not tested. It looks like a substantial change which would definitely warrant
> testing when backported.
>
> That makes me wonder: Should I stop build testing "um" images in older kernels ?
No, it's good for testing and I'm pretty sure that Android still uses it
for their test infrastructure so it matters. I'll go do some reverts
now and push out a new release with this fixed as it's now shown up on
the kernel.ci build reports as well.
thanks for pointing it out.
greg k-h
^ permalink raw reply [flat|nested] 25+ messages in thread