May 2025 - Linux-stable-mirror

[regression 6.1.y] discard/TRIM through RAID10 blocking (was: Re: Bug#1104460: linux-image-6.1.0-34-powerpc64le: Discard broken) with RAID10: BUG: kernel tried to execute user page (0) - exploit attempt?

by Salvatore Bonaccorso

Hi We got a regression report in Debian after the update from 6.1.133 to 6.1.135. Melvin is reporting that discard/trimm trhough a RAID10 array stalls idefintively. The full report is inlined below and originates from https://bugs.debian.org/1104460 . On Wed, Apr 30, 2025 at 04:46:50PM +0200, Melvin Vermeeren wrote: > Package: src:linux > Version: 6.1.135-1 > Severity: important > Tags: upstream > X-Debbugs-Cc: vermeeren(a)vermwa.re > > Dear Maintainer, > > Upgrading from linux-image-6.1.0-33-powerpc64le (6.1.133-1) to > linux-image-6.1.0-34-powerpc64le (6.1.135-1) it appears there is a > serious regression bug related to discard/TRIM through a RAID10 array. > This only affects RAID10, RAID1 array on the same SSD device is not > affected. Array in question is a fairly standard RAID10 in 2far layout. > > md127 : active raid10 dm-1[2] dm-0[0] > 1872188416 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU] > bitmap: 1/1 pages [64KB], 65536KB chunk > > Any discard operation will result in quite a long kernel error. The > calling process will either segfault (swapon) or, more likely, be stuck > forever (Qemu, fstrim) in the D state per htop. The iostat utility > reports a %util of 100% for any device on top of (directly or > indirectly) of the RAID10 device, despite there being no read or write > requests to the devices or any other acitivty. > > Stuck processes cannot be terminated or killed. Attempting to reboot > normally will result in a stuck machine on shutdown, so only a > REISUB-style reboot will work via procfs sysrq. > > I have briefly diffed and inspected commits between the two kernel > versions and I suspect the commit below may be at fault. Do keep in mind > I have not verified this in any way, so I may be wrong. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… > > Considering this is shipped as part of a stable security update I > consider it quite a serious bug. Affected hosts will not boot up > cleanly, may not have swap, processes will freeze upon discard and clean > reboot it also not possible. > > More logs available upon request. > > Many thanks, > > Melvin Vermeeren. > > -- Package-specific info: > ** Version: > Linux version 6.1.0-34-powerpc64le (debian-kernel(a)lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.135-1 (2025-04-25) > > ** Command line: > root=/dev/mapper/...-root ro quiet > > ** Not tainted > > ** Kernel log: > # /etc/fstab entry > /dev/.../swap none swap sw,discard=once 0 0 > > ~# swapon -va > swapon: /dev/mapper/...-swap: found signature [pagesize=65536, signature=swap] > swapon: /dev/mapper/...-swap: pagesize=65536, swapsize=17179869184, devsize=17179869184 > swapon /dev/mapper/...-swap > Segmentation fault > > ~# dmesg > ... > [ 223.017257] kernel tried to execute user page (0) - exploit attempt? (uid: 0) > [ 223.017287] BUG: Unable to handle kernel instruction fetch (NULL pointer?) > [ 223.017301] Faulting instruction address: 0x00000000 > [ 223.017326] Oops: Kernel access of bad area, sig: 11 [#1] > [ 223.017338] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV > [ 223.017365] Modules linked in: bridge stp llc binfmt_misc nft_connlimit nf_conncount ast drm_vram_helper drm_ttm_helper ofpart ipmi_powernv ttm ipmi_devintf powernv_flash at24 mtd ipmi_msghandler opal_prd regmap_i2c drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_algo_bit sg nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nf_tables nfnetlink drm loop fuse drm_panel_orientation_quirks configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_integrity dm_bufio dm_mod macvlan raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common xhci_pci xts ecb xhci_hcd ctr vmx_crypto gf128mul crc32c_vpmsum tg3 mpt3sas usbcore raid_class libphy scsi_transport_sas usb_common > [ 223.017812] CPU: 8 PID: 10609 Comm: swapon Not tainted 6.1.0-34-powerpc64le #1 Debian 6.1.135-1 > [ 223.017844] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV > [ 223.017879] NIP: 0000000000000000 LR: c0000000003efe70 CTR: 0000000000000000 > [ 223.017926] REGS: c0000000276cf200 TRAP: 0400 Not tainted (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 223.017979] MSR: 900000004280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24004480 XER: 00000004 > [ 223.018060] CFAR: c0000000003efe6c IRQMASK: 0 > GPR00: c0000000003efec4 c0000000276cf4a0 c000000001148100 0000000000092800 > GPR04: 0000000000000000 0000000000000003 0000000000000c00 c00000000296e700 > GPR08: c00000000c0e9700 00000c0000090800 0000000000000000 0000000000002000 > GPR12: 0000000000000000 c000001ffffd9800 c0000000446b8c00 0000000000000000 > GPR16: 0000000000000400 0000000000000000 0000000000000001 000000000000c812 > GPR20: 000000000000c911 c0000000170c5700 c00000000296e718 c00000000296e3f0 > GPR24: 0000000000000000 00000000000003ff 0000000000000000 0000000000000c00 > GPR28: c000200009e2dd00 c00000000296e718 00000c0000092800 0000000000092c00 > [ 223.018372] NIP [0000000000000000] 0x0 > [ 223.018397] LR [c0000000003efe70] mempool_alloc+0xa0/0x210 > [ 223.018435] Call Trace: > [ 223.018453] [c0000000276cf4a0] [c0000000003efec4] mempool_alloc+0xf4/0x210 (unreliable) > [ 223.018507] [c0000000276cf520] [c000000000743bf8] bio_alloc_bioset+0x368/0x510 > [ 223.018552] [c0000000276cf5a0] [c000000000743e74] bio_alloc_clone+0x44/0xa0 > [ 223.018601] [c0000000276cf5e0] [c008000015793adc] md_account_bio+0x54/0xb0 [md_mod] > [ 223.018655] [c0000000276cf610] [c00800001567778c] raid10_make_request+0xc54/0x1040 [raid10] > [ 223.018687] [c0000000276cf770] [c00800001579a290] md_handle_request+0x198/0x380 [md_mod] > [ 223.018735] [c0000000276cf800] [c00000000074c32c] __submit_bio+0x9c/0x250 > [ 223.018773] [c0000000276cf840] [c00000000074ca88] submit_bio_noacct_nocheck+0x178/0x3f0 > [ 223.018825] [c0000000276cf8b0] [c000000000743e08] blk_next_bio+0x68/0x90 > [ 223.018863] [c0000000276cf8e0] [c000000000758c60] __blkdev_issue_discard+0x180/0x280 > [ 223.018898] [c0000000276cf980] [c000000000758de8] blkdev_issue_discard+0x88/0x120 > [ 223.018927] [c0000000276cfa00] [c0000000004a9e8c] sys_swapon+0x11dc/0x18a0 > [ 223.018971] [c0000000276cfb50] [c00000000002b038] system_call_exception+0x138/0x260 > [ 223.019015] [c0000000276cfe10] [c00000000000c0f0] system_call_vectored_common+0xf0/0x280 > [ 223.019058] --- interrupt: 3000 at 0x7fff95146770 > [ 223.019095] NIP: 00007fff95146770 LR: 00007fff95146770 CTR: 0000000000000000 > [ 223.019132] REGS: c0000000276cfe80 TRAP: 3000 Not tainted (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 223.019182] MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48002481 XER: 00000000 > [ 223.019267] IRQMASK: 0 > GPR00: 0000000000000057 00007fffdca2ace0 00007fff95256f00 00000001220a1c20 > GPR04: 0000000000030000 000000000000001e 000000000000000a 000000000000000a > GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > GPR12: 0000000000000000 00007fff955dcbc0 0000000000000000 0000000000000000 > GPR16: 0000000000000000 00000001104066b0 00007fffdca2afc8 000000011040cbd0 > GPR20: 000000011040cbd8 0000000000000000 0000000000010000 00007fffdca2aff0 > GPR24: 00007fffdca2afd0 0000000000000003 0000000000030000 0000000400000000 > GPR28: 00000001220a1c20 000000000000fff6 00000001220a30a0 0000000000100000 > [ 223.019542] NIP [00007fff95146770] 0x7fff95146770 > [ 223.019568] LR [00007fff95146770] 0x7fff95146770 > [ 223.019595] --- interrupt: 3000 > [ 223.019604] Instruction dump: > [ 223.019626] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 223.019665] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 223.019712] ---[ end trace 0000000000000000 ]--- > > [ 224.623456] note: swapon[10609] exited with irqs disabled > [ 224.623483] ------------[ cut here ]------------ > [ 224.623502] WARNING: CPU: 8 PID: 10609 at kernel/exit.c:816 do_exit+0x94/0xbc0 > [ 224.623516] Modules linked in: bridge stp llc binfmt_misc nft_connlimit nf_conncount ast drm_vram_helper drm_ttm_helper ofpart ipmi_powernv ttm ipmi_devintf powernv_flash at24 mtd ipmi_msghandler opal_prd regmap_i2c drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_algo_bit sg nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nf_tables nfnetlink drm loop fuse drm_panel_orientation_quirks configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_integrity dm_bufio dm_mod macvlan raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common xhci_pci xts ecb xhci_hcd ctr vmx_crypto gf128mul crc32c_vpmsum tg3 mpt3sas usbcore raid_class libphy scsi_transport_sas usb_common > [ 224.623825] CPU: 8 PID: 10609 Comm: swapon Tainted: G D 6.1.0-34-powerpc64le #1 Debian 6.1.135-1 > [ 224.623860] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV > [ 224.623892] NIP: c000000000140fa4 LR: c000000000140fa0 CTR: 0000000000000000 > [ 224.623935] REGS: c0000000276cecb0 TRAP: 0700 Tainted: G D (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 224.623969] MSR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 24004222 XER: 00000004 > [ 224.624012] CFAR: c00000000013ea68 IRQMASK: 0 > GPR00: c000000000140fa0 c0000000276cef50 c000000001148100 0000000000000000 > GPR04: 0000000000000000 c0000000276cee20 c0000000276cee18 0000001ffb000000 > GPR08: 0000000000000027 c0000000276cf9b0 0000000000000000 0000000000004000 > GPR12: 0000000031c40000 c000001ffffd9800 c0000000446b8c00 0000000000000000 > GPR16: 0000000000000400 0000000000000000 0000000000000001 000000000000c812 > GPR20: 000000000000c911 c0000000170c5700 c00000000296e718 c00000000296e3f0 > GPR24: 0000000000000000 00000000000003ff 0000000000000000 0000000000000c00 > GPR28: 000000000000000b c00000001ce25d80 c000000078409c00 c000000026529d80 > [ 224.624208] NIP [c000000000140fa4] do_exit+0x94/0xbc0 > [ 224.624239] LR [c000000000140fa0] do_exit+0x90/0xbc0 > [ 224.624269] Call Trace: > [ 224.624274] [c0000000276cef50] [c000000000140fa0] do_exit+0x90/0xbc0 (unreliable) > [ 224.624308] [c0000000276cf020] [c000000000141b80] make_task_dead+0xb0/0x1f0 > [ 224.624320] [c0000000276cf0a0] [c000000000025718] oops_end+0x188/0x1c0 > [ 224.624341] [c0000000276cf120] [c00000000007f72c] __bad_page_fault+0x18c/0x1b0 > [ 224.624375] [c0000000276cf190] [c000000000008cd4] instruction_access_common_virt+0x194/0x1a0 > [ 224.624421] --- interrupt: 400 at 0x0 > [ 224.624438] NIP: 0000000000000000 LR: c0000000003efe70 CTR: 0000000000000000 > [ 224.624471] REGS: c0000000276cf200 TRAP: 0400 Tainted: G D (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 224.624507] MSR: 900000004280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24004480 XER: 00000004 > [ 224.624544] CFAR: c0000000003efe6c IRQMASK: 0 > GPR00: c0000000003efec4 c0000000276cf4a0 c000000001148100 0000000000092800 > GPR04: 0000000000000000 0000000000000003 0000000000000c00 c00000000296e700 > GPR08: c00000000c0e9700 00000c0000090800 0000000000000000 0000000000002000 > GPR12: 0000000000000000 c000001ffffd9800 c0000000446b8c00 0000000000000000 > GPR16: 0000000000000400 0000000000000000 0000000000000001 000000000000c812 > GPR20: 000000000000c911 c0000000170c5700 c00000000296e718 c00000000296e3f0 > GPR24: 0000000000000000 00000000000003ff 0000000000000000 0000000000000c00 > GPR28: c000200009e2dd00 c00000000296e718 00000c0000092800 0000000000092c00 > [ 224.624732] NIP [0000000000000000] 0x0 > [ 224.624749] LR [c0000000003efe70] mempool_alloc+0xa0/0x210 > [ 224.624771] --- interrupt: 400 > [ 224.624789] [c0000000276cf4a0] [c0000000003efec4] mempool_alloc+0xf4/0x210 (unreliable) > [ 224.624823] [c0000000276cf520] [c000000000743bf8] bio_alloc_bioset+0x368/0x510 > [ 224.624859] [c0000000276cf5a0] [c000000000743e74] bio_alloc_clone+0x44/0xa0 > [ 224.624892] [c0000000276cf5e0] [c008000015793adc] md_account_bio+0x54/0xb0 [md_mod] > [ 224.624930] [c0000000276cf610] [c00800001567778c] raid10_make_request+0xc54/0x1040 [raid10] > [ 224.624964] [c0000000276cf770] [c00800001579a290] md_handle_request+0x198/0x380 [md_mod] > [ 224.624997] [c0000000276cf800] [c00000000074c32c] __submit_bio+0x9c/0x250 > [ 224.625018] [c0000000276cf840] [c00000000074ca88] submit_bio_noacct_nocheck+0x178/0x3f0 > [ 224.625043] [c0000000276cf8b0] [c000000000743e08] blk_next_bio+0x68/0x90 > [ 224.625066] [c0000000276cf8e0] [c000000000758c60] __blkdev_issue_discard+0x180/0x280 > [ 224.625091] [c0000000276cf980] [c000000000758de8] blkdev_issue_discard+0x88/0x120 > [ 224.625115] [c0000000276cfa00] [c0000000004a9e8c] sys_swapon+0x11dc/0x18a0 > [ 224.625139] [c0000000276cfb50] [c00000000002b038] system_call_exception+0x138/0x260 > [ 224.625164] [c0000000276cfe10] [c00000000000c0f0] system_call_vectored_common+0xf0/0x280 > [ 224.625201] --- interrupt: 3000 at 0x7fff95146770 > [ 224.625270] NIP: 00007fff95146770 LR: 00007fff95146770 CTR: 0000000000000000 > [ 224.625367] REGS: c0000000276cfe80 TRAP: 3000 Tainted: G D (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 224.625458] MSR: 900000000000f033 <SF,HV,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48002481 XER: 00000000 > [ 224.625570] IRQMASK: 0 > GPR00: 0000000000000057 00007fffdca2ace0 00007fff95256f00 00000001220a1c20 > GPR04: 0000000000030000 000000000000001e 000000000000000a 000000000000000a > GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > GPR12: 0000000000000000 00007fff955dcbc0 0000000000000000 0000000000000000 > GPR16: 0000000000000000 00000001104066b0 00007fffdca2afc8 000000011040cbd0 > GPR20: 000000011040cbd8 0000000000000000 0000000000010000 00007fffdca2aff0 > GPR24: 00007fffdca2afd0 0000000000000003 0000000000030000 0000000400000000 > GPR28: 00000001220a1c20 000000000000fff6 00000001220a30a0 0000000000100000 > [ 224.626325] NIP [00007fff95146770] 0x7fff95146770 > [ 224.626388] LR [00007fff95146770] 0x7fff95146770 > [ 224.626522] --- interrupt: 3000 > [ 224.626568] Instruction dump: > [ 224.626587] 60000000 813f000c 3929ffff 2c090000 913f000c 40820010 813f0074 71290004 > [ 224.626680] 4182074c 7fa3eb78 4bffda7d e93e0b10 <0b090000> e87e0a48 48c7dd0d 60000000 > [ 224.626786] ---[ end trace 0000000000000000 ]--- Does this ring a bell? Melvin, the same change went as well in other stable series, 6.6.88, 6.12.25, 6.14.4, can you test e.g. 6.12.25-1 in Debian as well from unstable to see if the regression is there as well? Might you be able to bisect the upstream stable series between 6.1.133 to 6.1.135 to really confirm the mentioned commit is the one breaking? Regards, Salvatore

4 months

5
12
0 0

[PATCH v4 0/1] kasan: Avoid sleepable page allocation from atomic context

by Alexander Gordeev

Hi All, Chages since v3: - pfn_to_virt() changed to page_to_virt() due to compile error Chages since v2: - page allocation moved out of the atomic context Chages since v1: - Fixes: and -stable tags added to the patch description Thanks! Alexander Gordeev (1): kasan: Avoid sleepable page allocation from atomic context mm/kasan/shadow.c | 63 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 47 insertions(+), 16 deletions(-) -- 2.45.2

4 months

1
2
0 0

[PATCH v3 0/1] kasan: Avoid sleepable page allocation from atomic context

by Alexander Gordeev

Hi All, Chages since v2: - page allocation moved out of the atomic context Chages since v1: - Fixes: and -stable tags added to the patch description Thanks! Alexander Gordeev (1): kasan: Avoid sleepable page allocation from atomic context mm/kasan/shadow.c | 65 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 49 insertions(+), 16 deletions(-) -- 2.45.2

4 months

5
9
0 0

Re: G R A N T

by U N

Greetings Dear, Send your Ref: FSG2025 / Name / Phone Number / Country to Mr. Andrej Mahecic on un.grant(a)socialworker.net, +1 888 673 0430 for your £100,000.00. Sincerely Mr. C. Gunness On behalf of the UN.

4 months

1
0
0 0

[PATCH AUTOSEL 6.12 001/486] kconfig: merge_config: use an empty file as initfile

by Sasha Levin

From: Daniel Gomez <da.gomez(a)samsung.com> [ Upstream commit a26fe287eed112b4e21e854f173c8918a6a8596d ] The scripts/kconfig/merge_config.sh script requires an existing $INITFILE (or the $1 argument) as a base file for merging Kconfig fragments. However, an empty $INITFILE can serve as an initial starting point, later referenced by the KCONFIG_ALLCONFIG Makefile variable if -m is not used. This variable can point to any configuration file containing preset config symbols (the merged output) as stated in Documentation/kbuild/kconfig.rst. When -m is used $INITFILE will contain just the merge output requiring the user to run make (i.e. KCONFIG_ALLCONFIG=<$INITFILE> make <allnoconfig/alldefconfig> or make olddefconfig). Instead of failing when `$INITFILE` is missing, create an empty file and use it as the starting point for merges. Signed-off-by: Daniel Gomez <da.gomez(a)samsung.com> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- scripts/kconfig/merge_config.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh index 0b7952471c18f..79c09b378be81 100755 --- a/scripts/kconfig/merge_config.sh +++ b/scripts/kconfig/merge_config.sh @@ -112,8 +112,8 @@ INITFILE=$1 shift; if [ ! -r "$INITFILE" ]; then - echo "The base file '$INITFILE' does not exist. Exit." >&2 - exit 1 + echo "The base file '$INITFILE' does not exist. Creating one..." >&2 + touch "$INITFILE" fi MERGE_LIST=$* -- 2.39.5

4 months

2
486
0 0

[PATCH v6 02/20] drm/xe: Strict migration policy for atomic SVM faults

by Himal Prasad Ghimiray

From: Matthew Brost <matthew.brost(a)intel.com> Mixing GPU and CPU atomics does not work unless a strict migration policy of GPU atomics must be device memory. Enforce a policy of must be in VRAM with a retry loop of 3 attempts, if retry loop fails abort fault. Removing always_migrate_to_vram modparam as we now have real migration policy. v2: - Only retry migration on atomics - Drop alway migrate modparam v3: - Only set vram_only on DGFX (Himal) - Bail on get_pages failure if vram_only and retry count exceeded (Himal) - s/vram_only/devmem_only - Update xe_svm_range_is_valid to accept devmem_only argument v4: - Fix logic bug get_pages failure v5: - Fix commit message (Himal) - Mention removing always_migrate_to_vram in commit message (Lucas) - Fix xe_svm_range_is_valid to check for devmem pages - Bail on devmem_only && !migrate_devmem (Thomas) v6: - Add READ_ONCE barriers for opportunistic checks (Thomas) Fixes: 2f118c949160 ("drm/xe: Add SVM VRAM migration") Cc: stable(a)vger.kernel.org Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> --- drivers/gpu/drm/xe/xe_module.c | 3 - drivers/gpu/drm/xe/xe_module.h | 1 - drivers/gpu/drm/xe/xe_svm.c | 103 ++++++++++++++++++++++++--------- drivers/gpu/drm/xe/xe_svm.h | 5 -- include/drm/drm_gpusvm.h | 40 ++++++++----- 5 files changed, 103 insertions(+), 49 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_module.c b/drivers/gpu/drm/xe/xe_module.c index 64bf46646544..e4742e27e2cd 100644 --- a/drivers/gpu/drm/xe/xe_module.c +++ b/drivers/gpu/drm/xe/xe_module.c @@ -30,9 +30,6 @@ struct xe_modparam xe_modparam = { module_param_named(svm_notifier_size, xe_modparam.svm_notifier_size, uint, 0600); MODULE_PARM_DESC(svm_notifier_size, "Set the svm notifier size(in MiB), must be power of 2"); -module_param_named(always_migrate_to_vram, xe_modparam.always_migrate_to_vram, bool, 0444); -MODULE_PARM_DESC(always_migrate_to_vram, "Always migrate to VRAM on GPU fault"); - module_param_named_unsafe(force_execlist, xe_modparam.force_execlist, bool, 0444); MODULE_PARM_DESC(force_execlist, "Force Execlist submission"); diff --git a/drivers/gpu/drm/xe/xe_module.h b/drivers/gpu/drm/xe/xe_module.h index 84339e509c80..5a3bfea8b7b4 100644 --- a/drivers/gpu/drm/xe/xe_module.h +++ b/drivers/gpu/drm/xe/xe_module.h @@ -12,7 +12,6 @@ struct xe_modparam { bool force_execlist; bool probe_display; - bool always_migrate_to_vram; u32 force_vram_bar_size; int guc_log_level; char *guc_firmware_path; diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c index 890f6b2f40e9..dcc84e65ca96 100644 --- a/drivers/gpu/drm/xe/xe_svm.c +++ b/drivers/gpu/drm/xe/xe_svm.c @@ -16,8 +16,12 @@ static bool xe_svm_range_in_vram(struct xe_svm_range *range) { - /* Not reliable without notifier lock */ - return range->base.flags.has_devmem_pages; + /* Not reliable without notifier lock, opportunistic only */ + struct drm_gpusvm_range_flags flags = { + .__flags = READ_ONCE(range->base.flags.__flags), + }; + + return flags.has_devmem_pages; } static bool xe_svm_range_has_vram_binding(struct xe_svm_range *range) @@ -650,9 +654,13 @@ void xe_svm_fini(struct xe_vm *vm) } static bool xe_svm_range_is_valid(struct xe_svm_range *range, - struct xe_tile *tile) + struct xe_tile *tile, + bool devmem_only) { - return (range->tile_present & ~range->tile_invalidated) & BIT(tile->id); + /* Not reliable without notifier lock, opportunistic only */ + return ((READ_ONCE(range->tile_present) & + ~READ_ONCE(range->tile_invalidated)) & BIT(tile->id)) && + (!devmem_only || xe_svm_range_in_vram(range)); } #if IS_ENABLED(CONFIG_DRM_XE_DEVMEM_MIRROR) @@ -726,6 +734,36 @@ static int xe_svm_alloc_vram(struct xe_vm *vm, struct xe_tile *tile, } #endif +static bool supports_4K_migration(struct xe_device *xe) +{ + if (xe->info.vram_flags & XE_VRAM_FLAGS_NEED64K) + return false; + + return true; +} + +static bool xe_svm_range_needs_migrate_to_vram(struct xe_svm_range *range, + struct xe_vma *vma) +{ + struct xe_vm *vm = range_to_vm(&range->base); + u64 range_size = xe_svm_range_size(range); + + if (!range->base.flags.migrate_devmem) + return false; + + /* Not reliable without notifier lock, opportunistic only */ + if (xe_svm_range_in_vram(range)) { + drm_dbg(&vm->xe->drm, "Range is already in VRAM\n"); + return false; + } + + if (range_size <= SZ_64K && !supports_4K_migration(vm->xe)) { + drm_dbg(&vm->xe->drm, "Platform doesn't support SZ_4K range migration\n"); + return false; + } + + return true; +} /** * xe_svm_handle_pagefault() - SVM handle page fault @@ -750,12 +788,15 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct xe_vma *vma, IS_ENABLED(CONFIG_DRM_XE_DEVMEM_MIRROR), .check_pages_threshold = IS_DGFX(vm->xe) && IS_ENABLED(CONFIG_DRM_XE_DEVMEM_MIRROR) ? SZ_64K : 0, + .devmem_only = atomic && IS_DGFX(vm->xe) && + IS_ENABLED(CONFIG_DRM_XE_DEVMEM_MIRROR), }; struct xe_svm_range *range; struct drm_gpusvm_range *r; struct drm_exec exec; struct dma_fence *fence; struct xe_tile *tile = gt_to_tile(gt); + int migrate_try_count = ctx.devmem_only ? 3 : 1; ktime_t end = 0; int err; @@ -776,24 +817,30 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct xe_vma *vma, if (IS_ERR(r)) return PTR_ERR(r); + if (ctx.devmem_only && !r->flags.migrate_devmem) + return -EACCES; + range = to_xe_range(r); - if (xe_svm_range_is_valid(range, tile)) + if (xe_svm_range_is_valid(range, tile, ctx.devmem_only)) return 0; range_debug(range, "PAGE FAULT"); - /* XXX: Add migration policy, for now migrate range once */ - if (!range->skip_migrate && range->base.flags.migrate_devmem && - xe_svm_range_size(range) >= SZ_64K) { - range->skip_migrate = true; - + if (--migrate_try_count >= 0 && + xe_svm_range_needs_migrate_to_vram(range, vma)) { err = xe_svm_alloc_vram(vm, tile, range, &ctx); if (err) { - drm_dbg(&vm->xe->drm, - "VRAM allocation failed, falling back to " - "retrying fault, asid=%u, errno=%pe\n", - vm->usm.asid, ERR_PTR(err)); - goto retry; + if (migrate_try_count || !ctx.devmem_only) { + drm_dbg(&vm->xe->drm, + "VRAM allocation failed, falling back to retrying fault, asid=%u, errno=%pe\n", + vm->usm.asid, ERR_PTR(err)); + goto retry; + } else { + drm_err(&vm->xe->drm, + "VRAM allocation failed, retry count exceeded, asid=%u, errno=%pe\n", + vm->usm.asid, ERR_PTR(err)); + return err; + } } } @@ -801,15 +848,22 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct xe_vma *vma, err = drm_gpusvm_range_get_pages(&vm->svm.gpusvm, r, &ctx); /* Corner where CPU mappings have changed */ if (err == -EOPNOTSUPP || err == -EFAULT || err == -EPERM) { - if (err == -EOPNOTSUPP) { - range_debug(range, "PAGE FAULT - EVICT PAGES"); - drm_gpusvm_range_evict(&vm->svm.gpusvm, &range->base); + if (migrate_try_count > 0 || !ctx.devmem_only) { + if (err == -EOPNOTSUPP) { + range_debug(range, "PAGE FAULT - EVICT PAGES"); + drm_gpusvm_range_evict(&vm->svm.gpusvm, + &range->base); + } + drm_dbg(&vm->xe->drm, + "Get pages failed, falling back to retrying, asid=%u, gpusvm=%p, errno=%pe\n", + vm->usm.asid, &vm->svm.gpusvm, ERR_PTR(err)); + range_debug(range, "PAGE FAULT - RETRY PAGES"); + goto retry; + } else { + drm_err(&vm->xe->drm, + "Get pages failed, retry count exceeded, asid=%u, gpusvm=%p, errno=%pe\n", + vm->usm.asid, &vm->svm.gpusvm, ERR_PTR(err)); } - drm_dbg(&vm->xe->drm, - "Get pages failed, falling back to retrying, asid=%u, gpusvm=%p, errno=%pe\n", - vm->usm.asid, &vm->svm.gpusvm, ERR_PTR(err)); - range_debug(range, "PAGE FAULT - RETRY PAGES"); - goto retry; } if (err) { range_debug(range, "PAGE FAULT - FAIL PAGE COLLECT"); @@ -843,9 +897,6 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct xe_vma *vma, } drm_exec_fini(&exec); - if (xe_modparam.always_migrate_to_vram) - range->skip_migrate = false; - dma_fence_wait(fence, false); dma_fence_put(fence); diff --git a/drivers/gpu/drm/xe/xe_svm.h b/drivers/gpu/drm/xe/xe_svm.h index 3d441eb1f7ea..0e1f376a7471 100644 --- a/drivers/gpu/drm/xe/xe_svm.h +++ b/drivers/gpu/drm/xe/xe_svm.h @@ -39,11 +39,6 @@ struct xe_svm_range { * range. Protected by GPU SVM notifier lock. */ u8 tile_invalidated; - /** - * @skip_migrate: Skip migration to VRAM, protected by GPU fault handler - * locking. - */ - u8 skip_migrate :1; }; /** diff --git a/include/drm/drm_gpusvm.h b/include/drm/drm_gpusvm.h index 9fd25fc880a4..653d48dbe1c1 100644 --- a/include/drm/drm_gpusvm.h +++ b/include/drm/drm_gpusvm.h @@ -185,6 +185,31 @@ struct drm_gpusvm_notifier { } flags; }; +/** + * struct drm_gpusvm_range_flags - Structure representing a GPU SVM range flags + * + * @migrate_devmem: Flag indicating whether the range can be migrated to device memory + * @unmapped: Flag indicating if the range has been unmapped + * @partial_unmap: Flag indicating if the range has been partially unmapped + * @has_devmem_pages: Flag indicating if the range has devmem pages + * @has_dma_mapping: Flag indicating if the range has a DMA mapping + * @__flags: Flags for range in u16 form (used for READ_ONCE) + */ +struct drm_gpusvm_range_flags { + union { + struct { + /* All flags below must be set upon creation */ + u16 migrate_devmem : 1; + /* All flags below must be set / cleared under notifier lock */ + u16 unmapped : 1; + u16 partial_unmap : 1; + u16 has_devmem_pages : 1; + u16 has_dma_mapping : 1; + }; + u16 __flags; + }; +}; + /** * struct drm_gpusvm_range - Structure representing a GPU SVM range * @@ -198,11 +223,6 @@ struct drm_gpusvm_notifier { * @dpagemap: The struct drm_pagemap of the device pages we're dma-mapping. * Note this is assuming only one drm_pagemap per range is allowed. * @flags: Flags for range - * @flags.migrate_devmem: Flag indicating whether the range can be migrated to device memory - * @flags.unmapped: Flag indicating if the range has been unmapped - * @flags.partial_unmap: Flag indicating if the range has been partially unmapped - * @flags.has_devmem_pages: Flag indicating if the range has devmem pages - * @flags.has_dma_mapping: Flag indicating if the range has a DMA mapping * * This structure represents a GPU SVM range used for tracking memory ranges * mapped in a DRM device. @@ -216,15 +236,7 @@ struct drm_gpusvm_range { unsigned long notifier_seq; struct drm_pagemap_device_addr *dma_addr; struct drm_pagemap *dpagemap; - struct { - /* All flags below must be set upon creation */ - u16 migrate_devmem : 1; - /* All flags below must be set / cleared under notifier lock */ - u16 unmapped : 1; - u16 partial_unmap : 1; - u16 has_devmem_pages : 1; - u16 has_dma_mapping : 1; - } flags; + struct drm_gpusvm_range_flags flags; }; /** -- 2.34.1

4 months

3
4
0 0

[PATCH 1/4] mm: fix VM_UFFD_MINOR == VM_SHADOW_STACK on USERFAULTFD=y && ARM64_GCS=y

by Florent Revest

On configs with CONFIG_ARM64_GCS=y, VM_SHADOW_STACK is bit 38. On configs with CONFIG_HAVE_ARCH_USERFAULTFD_MINOR=y (selected by CONFIG_ARM64 when CONFIG_USERFAULTFD=y), VM_UFFD_MINOR is _also_ bit 38. This bit being shared by two different VMA flags could lead to all sorts of unintended behaviors. Presumably, a process could maybe call into userfaultfd in a way that disables the shadow stack vma flag. I can't think of any attack where this would help (presumably, if an attacker tries to disable shadow stacks, they are trying to hijack control flow so can't arbitrarily call into userfaultfd yet anyway) but this still feels somewhat scary. Fixes: ae80e1629aea ("mm: Define VM_SHADOW_STACK for arm64 when we support GCS") Cc: <stable(a)vger.kernel.org> Signed-off-by: Florent Revest <revest(a)chromium.org> --- include/linux/mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index bf55206935c46..fdda6b16263b3 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -385,7 +385,7 @@ extern unsigned int kobjsize(const void *objp); #endif #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR -# define VM_UFFD_MINOR_BIT 38 +# define VM_UFFD_MINOR_BIT 41 # define VM_UFFD_MINOR BIT(VM_UFFD_MINOR_BIT) /* UFFD minor faults */ #else /* !CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */ # define VM_UFFD_MINOR VM_NONE -- 2.49.0.967.g6a0df3ecc3-goog

4 months

2
1
0 0

[PATCH 2/2] mm/page_alloc: Fix race condition in unaccepted memory handling

by Kirill A. Shutemov

The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borisal and Thomas pointed out that the tracking is racy operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Fixes: dcdfdd40fa82 ("mm: Add support for unaccepted memory") Link: https://lore.kernel.org/all/20250506092445.GBaBnVXXyvnazly6iF@fat_crate.loc… Reported-by: Borislav Petkov <bp(a)alien8.de> Reported-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org # v6.5+ Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Brendan Jackman <jackmanb(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> --- mm/internal.h | 1 - mm/mm_init.c | 1 - mm/page_alloc.c | 47 ----------------------------------------------- 3 files changed, 49 deletions(-) diff --git a/mm/internal.h b/mm/internal.h index e9695baa5922..50c2f590b2d0 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -1595,7 +1595,6 @@ unsigned long move_page_tables(struct pagetable_move_control *pmc); #ifdef CONFIG_UNACCEPTED_MEMORY void accept_page(struct page *page); -void unaccepted_cleanup_work(struct work_struct *work); #else /* CONFIG_UNACCEPTED_MEMORY */ static inline void accept_page(struct page *page) { diff --git a/mm/mm_init.c b/mm/mm_init.c index 9659689b8ace..84f14fa12d0d 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -1441,7 +1441,6 @@ static void __meminit zone_init_free_lists(struct zone *zone) #ifdef CONFIG_UNACCEPTED_MEMORY INIT_LIST_HEAD(&zone->unaccepted_pages); - INIT_WORK(&zone->unaccepted_cleanup, unaccepted_cleanup_work); #endif } diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 5fccf5fce084..a4a4df2daedb 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -7175,16 +7175,8 @@ bool has_managed_dma(void) #ifdef CONFIG_UNACCEPTED_MEMORY -/* Counts number of zones with unaccepted pages. */ -static DEFINE_STATIC_KEY_FALSE(zones_with_unaccepted_pages); - static bool lazy_accept = true; -void unaccepted_cleanup_work(struct work_struct *work) -{ - static_branch_dec(&zones_with_unaccepted_pages); -} - static int __init accept_memory_parse(char *p) { if (!strcmp(p, "lazy")) { @@ -7209,11 +7201,7 @@ static bool page_contains_unaccepted(struct page *page, unsigned int order) static void __accept_page(struct zone *zone, unsigned long *flags, struct page *page) { - bool last; - list_del(&page->lru); - last = list_empty(&zone->unaccepted_pages); - account_freepages(zone, -MAX_ORDER_NR_PAGES, MIGRATE_MOVABLE); __mod_zone_page_state(zone, NR_UNACCEPTED, -MAX_ORDER_NR_PAGES); __ClearPageUnaccepted(page); @@ -7222,28 +7210,6 @@ static void __accept_page(struct zone *zone, unsigned long *flags, accept_memory(page_to_phys(page), PAGE_SIZE << MAX_PAGE_ORDER); __free_pages_ok(page, MAX_PAGE_ORDER, FPI_TO_TAIL); - - if (last) { - /* - * There are two corner cases: - * - * - If allocation occurs during the CPU bring up, - * static_branch_dec() cannot be used directly as - * it causes a deadlock on cpu_hotplug_lock. - * - * Instead, use schedule_work() to prevent deadlock. - * - * - If allocation occurs before workqueues are initialized, - * static_branch_dec() should be called directly. - * - * Workqueues are initialized before CPU bring up, so this - * will not conflict with the first scenario. - */ - if (system_wq) - schedule_work(&zone->unaccepted_cleanup); - else - unaccepted_cleanup_work(&zone->unaccepted_cleanup); - } } void accept_page(struct page *page) @@ -7280,20 +7246,12 @@ static bool try_to_accept_memory_one(struct zone *zone) return true; } -static inline bool has_unaccepted_memory(void) -{ - return static_branch_unlikely(&zones_with_unaccepted_pages); -} - static bool cond_accept_memory(struct zone *zone, unsigned int order, int alloc_flags) { long to_accept, wmark; bool ret = false; - if (!has_unaccepted_memory()) - return false; - if (list_empty(&zone->unaccepted_pages)) return false; @@ -7331,22 +7289,17 @@ static bool __free_unaccepted(struct page *page) { struct zone *zone = page_zone(page); unsigned long flags; - bool first = false; if (!lazy_accept) return false; spin_lock_irqsave(&zone->lock, flags); - first = list_empty(&zone->unaccepted_pages); list_add_tail(&page->lru, &zone->unaccepted_pages); account_freepages(zone, MAX_ORDER_NR_PAGES, MIGRATE_MOVABLE); __mod_zone_page_state(zone, NR_UNACCEPTED, MAX_ORDER_NR_PAGES); __SetPageUnaccepted(page); spin_unlock_irqrestore(&zone->lock, flags); - if (first) - static_branch_inc(&zones_with_unaccepted_pages); - return true; } -- 2.47.2

4 months

2
2
0 0

[PATCH] usb: typec: tcpm/tcpci_maxim: Fix bounds check in process_rx()

by Amit Sunil Dhamne via B4 Relay

From: Amit Sunil Dhamne <amitsd(a)google.com> Register read of TCPC_RX_BYTE_CNT returns the total size consisting of: PD message (pending read) size + 1 Byte for Frame Type (SOP*) This is validated against the max PD message (`struct pd_message`) size without accounting for the extra byte for the frame type. Note that the struct pd_message does not contain a field for the frame_type. This results in false negatives when the "PD message (pending read)" is equal to the max PD message size. Fixes: 6f413b559f86 ("usb: typec: tcpci_maxim: Chip level TCPC driver") Signed-off-by: Amit Sunil Dhamne <amitsd(a)google.com> Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com> Reviewed-by: Kyle Tso <kyletso(a)google.com> --- drivers/usb/typec/tcpm/tcpci_maxim_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/typec/tcpm/tcpci_maxim_core.c b/drivers/usb/typec/tcpm/tcpci_maxim_core.c index fd1b80593367641a6f997da2fb97a2b7238f6982..648311f5e3cf135f23b5cc0668001d2f177b9edd 100644 --- a/drivers/usb/typec/tcpm/tcpci_maxim_core.c +++ b/drivers/usb/typec/tcpm/tcpci_maxim_core.c @@ -166,7 +166,8 @@ static void process_rx(struct max_tcpci_chip *chip, u16 status) return; } - if (count > sizeof(struct pd_message) || count + 1 > TCPC_RECEIVE_BUFFER_LEN) { + if (count > sizeof(struct pd_message) + 1 || + count + 1 > TCPC_RECEIVE_BUFFER_LEN) { dev_err(chip->dev, "Invalid TCPC_RX_BYTE_CNT %d\n", count); return; } --- base-commit: ebd297a2affadb6f6f4d2e5d975c1eda18ac762d change-id: 20250421-b4-new-fix-pd-rx-count-79297ba619b7 Best regards, -- Amit Sunil Dhamne <amitsd(a)google.com>

4 months

3
2
0 0

[PATCH v2] arm64/cpufeature: annotate arm64_use_ng_mappings with ro_after_init to prevent wrong idmap generation

by Yeoreum Yun

create_init_idmap() could be called before .bss section initialization which is done in early_map_kernel(). Therefore, data/test_prot could be set incorrectly by PTE_MAYBE_NG macro. PTE_MAYBE_NG macro set NG bit according to value of "arm64_use_ng_mappings". and this variable places in .bss section. # llvm-objdump-21 --syms vmlinux-gcc | grep arm64_use_ng_mappings ffff800082f242a8 g O .bss 0000000000000001 arm64_use_ng_mappings If .bss section doesn't initialized, "arm64_use_ng_mappings" would be set with garbage value and then the text_prot or data_prot could be set incorrectly. Here is what i saw with kernel compiled via llvm-21 // create_init_idmap() ffff80008255c058: d10103ff sub sp, sp, #0x40 ffff80008255c05c: a9017bfd stp x29, x30, [sp, #0x10] ffff80008255c060: a90257f6 stp x22, x21, [sp, #0x20] ffff80008255c064: a9034ff4 stp x20, x19, [sp, #0x30] ffff80008255c068: 910043fd add x29, sp, #0x10 ffff80008255c06c: 90003fc8 adrp x8, 0xffff800082d54000 ffff80008255c070: d280e06a mov x10, #0x703 // =1795 ffff80008255c074: 91400409 add x9, x0, #0x1, lsl #12 // =0x1000 ffff80008255c078: 394a4108 ldrb w8, [x8, #0x290] ------------- (1) ffff80008255c07c: f2e00d0a movk x10, #0x68, lsl #48 ffff80008255c080: f90007e9 str x9, [sp, #0x8] ffff80008255c084: aa0103f3 mov x19, x1 ffff80008255c088: aa0003f4 mov x20, x0 ffff80008255c08c: 14000000 b 0xffff80008255c08c <__pi_create_init_idmap+0x34> ffff80008255c090: aa082d56 orr x22, x10, x8, lsl #11 -------- (2) Note, (1) is load the arm64_use_ng_mappings value in w8 and (2) is set the text or data prot with the w8 value to set PTE_NG bit. If .bss section doesn't initialized, x8 can include garbage value -- In case of some platform, x8 loaded with 0xcf -- it could generate wrong mapping. (i.e) text_prot is expected with PAGE_KERNEL_ROX(0x0040000000000F83) but with garbage x8 -- 0xcf, it sets with (0x0040000000067F83) and This makes boot failure with translation fault. This error cannot happen according to code generated by compiler. here is the case of gcc: ffff80008260a940 <__pi_create_init_idmap>: ffff80008260a940: d100c3ff sub sp, sp, #0x30 ffff80008260a944: aa0003ed mov x13, x0 ffff80008260a948: 91400400 add x0, x0, #0x1, lsl #12 // =0x1000 ffff80008260a94c: a9017bfd stp x29, x30, [sp, #0x10] ffff80008260a950: 910043fd add x29, sp, #0x10 ffff80008260a954: f90017e0 str x0, [sp, #0x28] ffff80008260a958: d00048c0 adrp x0, 0xffff800082f24000 <reset_devices> ffff80008260a95c: 394aa000 ldrb w0, [x0, #0x2a8] ffff80008260a960: 37000640 tbnz w0, #0x0, 0xffff80008260aa28 <__pi_create_init_idmap+0xe8> ---(3) ffff80008260a964: d280f060 mov x0, #0x783 // =1923 ffff80008260a968: d280e062 mov x2, #0x703 // =1795 ffff80008260a96c: f2e00800 movk x0, #0x40, lsl #48 ffff80008260a970: f2e00d02 movk x2, #0x68, lsl #48 ffff80008260a974: aa2103e4 mvn x4, x1 ffff80008260a978: 8a210049 bic x9, x2, x1 ... ffff80008260aa28: d281f060 mov x0, #0xf83 // =3971 ffff80008260aa2c: d281e062 mov x2, #0xf03 // =3843 ffff80008260aa30: f2e00800 movk x0, #0x40, lsl #48 In case of gcc, according to value of arm64_use_ng_mappings (annoated as(3)), it branches to each prot settup code. However this is also problem since it branches according to garbage value too -- idmapping with incorrect pgprot. To resolve this, annotate arm64_use_ng_mappings as ro_after_init. Fixes: 84b04d3e6bdb ("arm64: kernel: Create initial ID map from C code") Cc: <stable(a)vger.kernel.org> # 6.9.x Tested-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> --- Since v1: - add comments explaining arm64_use_ng_mappings shouldn't place .bss section - fix type on commit message - https://lore.kernel.org/all/20250502145755.3751405-1-yeoreum.yun@arm.com/ There is another way to solve this problem by setting test/data_prot with _PAGE_DEFAULT which doesn't include PTE_MAYBE_NG with constanst check in create_init_idmap() to be free from arm64_use_ng_mappings. but i think it would be better to change arm64_use_ng_mappings as ro_after_init because it doesn't change after init phase and solve this problem too. --- arch/arm64/kernel/cpufeature.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index d2104a1e7843..913ae2cead98 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -114,7 +114,18 @@ static struct arm64_cpu_capabilities const __ro_after_init *cpucap_ptrs[ARM64_NC DECLARE_BITMAP(boot_cpucaps, ARM64_NCAPS); -bool arm64_use_ng_mappings = false; +/* + * The variable arm64_use_ng_mappings should be placed in the .rodata section. + * Otherwise, it would end up in the .bss section, where it is initialized in + * early_map_kernel(). This can cause problems because the PTE_MAYBE_NG macro + * uses this variable, and create_init_idmap() — which might run before + * early_map_kernel() — could end up generating an incorrect idmap table. + * + * In other words, accessing variable placed in .bss section before + * early_map_kernel() will return garbage, + * potentially resulting in a wrong pgprot value. + */ +bool arm64_use_ng_mappings __ro_after_init = false; EXPORT_SYMBOL(arm64_use_ng_mappings); DEFINE_PER_CPU_READ_MOSTLY(const char *, this_cpu_vector) = vectors; -- LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

4 months

4
21
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025