An upcoming change will allocate the datapages dynamically instead of as
part of the kernel image. Such pages can only be mapped through
'struct page' and not through PFNs.

Prepare for the dynamic allocation by mapping through 'struct page'.

VM_MIXEDMAP is necessary for the call to vmf_insert_page() in the timens
prefault path to work.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
---
 lib/vdso/datastore.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/lib/vdso/datastore.c b/lib/vdso/datastore.c
index 7377fcb6e1dfe31d02ffcae371fdf9da069ae4c1..6e5feb4a95b85f5a1cbdced7cdeddc593fcbad40 100644
--- a/lib/vdso/datastore.c
+++ b/lib/vdso/datastore.c
@@ -39,14 +39,15 @@ struct vdso_arch_data *vdso_k_arch_data = &vdso_arch_data_store.data;
 static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
 			     struct vm_area_struct *vma, struct vm_fault *vmf)
 {
-	struct page *timens_page = find_timens_vvar_page(vma);
-	unsigned long pfn;
+	struct page *page, *timens_page;
+
+	timens_page = find_timens_vvar_page(vma);
 
 	switch (vmf->pgoff) {
 	case VDSO_TIME_PAGE_OFFSET:
 		if (!IS_ENABLED(CONFIG_GENERIC_GETTIMEOFDAY))
 			return VM_FAULT_SIGBUS;
-		pfn = __phys_to_pfn(__pa_symbol(vdso_k_time_data));
+		page = virt_to_page(vdso_k_time_data);
 		if (timens_page) {
 			/*
 			 * Fault in VVAR page too, since it will be accessed
@@ -56,10 +57,10 @@ static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
 			vm_fault_t err;
 
 			addr = vmf->address + VDSO_TIMENS_PAGE_OFFSET * PAGE_SIZE;
-			err = vmf_insert_pfn(vma, addr, pfn);
+			err = vmf_insert_page(vma, addr, page);
 			if (unlikely(err & VM_FAULT_ERROR))
 				return err;
-			pfn = page_to_pfn(timens_page);
+			page = timens_page;
 		}
 		break;
 	case VDSO_TIMENS_PAGE_OFFSET:
@@ -72,24 +73,25 @@ static vm_fault_t vvar_fault(const struct vm_special_mapping *sm,
 		 */
 		if (!IS_ENABLED(CONFIG_TIME_NS) || !timens_page)
 			return VM_FAULT_SIGBUS;
-		pfn = __phys_to_pfn(__pa_symbol(vdso_k_time_data));
+		page = virt_to_page(vdso_k_time_data);
 		break;
 	case VDSO_RNG_PAGE_OFFSET:
 		if (!IS_ENABLED(CONFIG_VDSO_GETRANDOM))
 			return VM_FAULT_SIGBUS;
-		pfn = __phys_to_pfn(__pa_symbol(vdso_k_rng_data));
+		page = virt_to_page(vdso_k_rng_data);
 		break;
 	case VDSO_ARCH_PAGES_START ... VDSO_ARCH_PAGES_END:
 		if (!IS_ENABLED(CONFIG_ARCH_HAS_VDSO_ARCH_DATA))
 			return VM_FAULT_SIGBUS;
-		pfn = __phys_to_pfn(__pa_symbol(vdso_k_arch_data)) +
-			vmf->pgoff - VDSO_ARCH_PAGES_START;
+		page = virt_to_page(vdso_k_arch_data) + vmf->pgoff - VDSO_ARCH_PAGES_START;
 		break;
 	default:
 		return VM_FAULT_SIGBUS;
 	}
 
-	return vmf_insert_pfn(vma, vmf->address, pfn);
+	get_page(page);
+	vmf->page = page;
+	return 0;
 }
 
 const struct vm_special_mapping vdso_vvar_mapping = {
@@ -101,7 +103,7 @@ struct vm_area_struct *vdso_install_vvar_mapping(struct mm_struct *mm, unsigned
 {
 	return _install_special_mapping(mm, addr, VDSO_NR_PAGES * PAGE_SIZE,
 					VM_READ | VM_MAYREAD | VM_IO | VM_DONTDUMP |
-					VM_PFNMAP | VM_SEALED_SYSMAP,
+					VM_MIXEDMAP | VM_SEALED_SYSMAP,
 					&vdso_vvar_mapping);
 }
 

-- 
2.51.0

On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:

> An upcoming change will allocate the datapages dynamically instead of as
> part of the kernel image. Such pages can only be mapped through
> 'struct page' and not through PFNs.

I'm seeing some boot failures on some arm64 platforms in -next which are
bisecting to this patch in -next.  Unfortunately the diagnostics aren't
super useful, we seem to just stop making progress in userspace with no
obvious output.  One sample log from the FVP is:

   https://lava.sirena.org.uk/scheduler/job/2036229#L1268

which isn't super instructive.  Not all platforms seem to be affected,
I've seen this on at least the Arm FVP, Orion O6 and Libretech Renegade
Elite.  The diagnostics aren't very clear here but given that I'm seeing
the same issue and bisect result on multiple platforms it seemed worth
mentioning.  Some platforms do seem fine.

We do have some other serious breakage affecting arm64 in -next which
are making it hard to get a clear picture of which platforms are
affected, at least the FVP and O6 are unaffected by those other issues
(due to using MTE on platforms that don't have it, those platforms do
have MTE).

bisect log:

# bad: [9823120909776bbca58a3c55ef1f27d49283c1f3] Add linux-next specific files for 20251103
# good: [3575af345aa2424636e69ac101a568bda249abe6] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
# good: [ed5d499b5c9cc11dd3edae1a7a55db7dfa4f1bdc] regcache: maple: Split ->populate() from ->init()
# good: [e73b743bfe8a6ff4e05b5657d3f7586a17ac3ba0] ASoC: soc-core: check ops & auto_selectable_formats in snd_soc_dai_get_fmt() to prevent dereference error
# good: [ecd0de438c1f0ee86cf8f6d5047965a2a181444b] spi: tle62x0: Add newline to sysfs attribute output
# good: [6ef8e042cdcaabe3e3c68592ba8bfbaee2fa10a3] ASoC: codec: wm8400: replace printk() calls with dev_*() device aware logging
# good: [f1dfbc1b5cf8650ae9a0d543e5f5335fc0f478ce] ASoC: max98090/91: fixing the stream index
# good: [20bcda681f8597e86070a4b3b12d1e4f541865d3] ASoC: codecs: va-macro: fix revision checking
# good: [cf6bf51b53252284bafc7377a4d8dbf10f048b4d] ASoC: cs4271: Add support for the external mclk
# good: [8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce] ASoC: qcom: sc7280: make use of common helpers
# good: [28039efa4d8e8bbf98b066133a906bd4e307d496] MAINTAINERS: remove obsolete file entry in DIALOG SEMICONDUCTOR DRIVERS
# good: [e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8] regmap: warn users about uninitialized flat cache
# good: [66fecfa91deb536a12ddf3d878a99590d7900277] ASoC: spacemit: use `depends on` instead of `select`
# good: [f034c16a4663eaf3198dc18b201ba50533fb5b81] ASoC: spacemit: add failure check for spacemit_i2s_init_dai()
# good: [4a5ac6cd05a7e54f1585d7779464d6ed6272c134] ASoC: sun4i-spdif: Support SPDIF output on A523 family
# good: [4795375d8aa072e9aacb0b278e6203c6ca41816a] ASoC: cs-amp-lib-test: Add test cases for cs_amp_set_efi_calibration_data()
# good: [ef042df96d0e1089764f39ede61bc8f140a4be00] ASoC: SDCA: Add HID button IRQ
# good: [e7434adf0c53a84d548226304cdb41c8818da1cb] ASoC: cs530x: Add SPI bus support for cs530x parts
# good: [01313661b248c5ba586acae09bff57077dbec0a5] regulator: Let raspberrypi drivers depend on ARM
# good: [d29479abaded34b2b1dab2e17efe96a65eba3d61] ASoC: renesas: fsi: Constify struct fsi_stream_handler
# good: [4c33cef58965eb655a0ac8e243aa323581ec025f] regulator: pca9450: link regulator inputs to supply groups
# good: [e973dfe9259095fb509ab12658c68d46f0e439d7] ASoC: qcom: sm8250: add qrb2210-sndcard compatible string
# good: [77a58ba7c64ccca20616aa03599766ccb0d1a330] spi: spi-mem: Trace exec_op
# good: [c17fa4cbc546c431ccf13e9354d5d9c1cd247b7c] ASoC: sdw_utils: add name_prefix for rt1321 part id
# good: [310bf433c01f78e0756fd5056a43118a2f77318c] ASoC: max98090/91: fixing a space
# good: [2528c15f314ece50218d1273654f630d74109583] ASoC: max98090/91: adding DAPM routing for digital output for max98091
# good: [d054cc3a2ccfb19484f3b54d69b6e416832dc8f4] regulator: rpmh-regulator: Add RPMH regulator support for PMR735D
# good: [fd5ef3d69f8975bad16c437a337b5cb04c8217a2] spi: spi-qpic-snand: make qcom_spi_ecc_engine_ops_pipelined const
# good: [638bae3fb225a708dc67db613af62f6d14c4eff4] ASoC: max98090/91: added DAPM widget for digital output for max98091
# good: [ecba655bf54a661ffe078856cd8dbc898270e4b5] ASoC: fsl_aud2htx: add IEC958_SUBFRAME_LE format in supported list
# good: [7e1906643a7374529af74b013bba35e4fa4e6ffc] ASoC: codecs: va-macro: Clean up on error path in probe()
# good: [d742ebcfe524dc54023f7c520d2ed2e4b7203c19] ASoC: soc.h: remove snd_soc_kcontrol_component()
# good: [fce217449075d59b29052b8cdac567f0f3e22641] ASoC: spacemit: add i2s support for K1 SoC
# good: [6658472a3e2de08197acfe099ba71ee0e2505ecf] ASoC: amd: amd_sdw: Propagate the PCI subsystem Vendor and Device IDs
# good: [0cc08c8130ac8f74419f99fe707dc193b7f79d86] spi: aspeed: Fix an IS_ERR() vs NULL bug in probe()
# good: [0743acf746a81e0460a56fd5ff847d97fa7eb370] spi: airoha: buffer must be 0xff-ed before writing
# good: [d77daa49085b067137d0adbe3263f75a7ee13a1b] spi: aspeed: fix spelling mistake "triming" -> "trimming"
# good: [1e570e77392f43a3cdab2849d1f81535f8a033e2] ASoC: mxs-saif: support usage with simple-audio-card
# good: [15afe57a874eaf104bfbb61ec598fa31627f7b19] ASoC: dt-bindings: qcom: Add Kaanapali LPASS macro codecs
# good: [65efe5404d151767653c7b7dd39bd2e7ad532c2d] regulator: rpmh-regulator: Add RPMH regulator support for Glymur
# good: [fb25114cd760c13cf177d9ac37837fafcc9657b5] regulator: sy7636a: add gpios and input regulator
# good: [6621b0f118d500092f5f3d72ddddb22aeeb3c3a0] ASoC: codecs: rt5670: use SOC_VALUE_ENUM_SINGLE_DECL for DAC2 L/R MX-1B
# good: [0b0eb7702a9fa410755e86124b4b7cd36e7d1cb4] ASoC: replace use of system_wq with system_dfl_wq
# good: [433e294c3c5b5d2020085a0e36c1cb47b694690a] regulator: core: forward undervoltage events downstream by default
# good: [7e7e2c6e2a1cb250f8d03bb99eed01f6d982d5dd] ASoC: sof-function-topology-lib: escalate the log when missing function topoplogy
# good: [6277a486a7faaa6c87f4bf1d59a2de233a093248] regulator: dt-bindings: Convert Dialog DA9211 Regulators to DT schema
# good: [64d87ccfae3326a9561fe41dc6073064a083e0df] spi: aspeed: Only map necessary address window region
# good: [4412ab501677606436e5c49e41151a1e6eac7ac0] spi: dt-bindings: spi-qpic-snand: Add IPQ5332 compatible
# good: [5e537031f322d55315cd384398b726a9a0748d47] ASoC: codecs: Fix the error of excessive semicolons
# good: [4d410ba9aa275e7990a270f63ce436990ace1bea] dt-bindings: sound: Update ADMAIF bindings for tegra264
# good: [fe8cc44dd173cde5788ab4e3730ac61f3d316d9c] spi: dw: add target mode support
# good: [b83fb1b14c06bdd765903ac852ba20a14e24f227] spi: offload: Add offset parameter
# good: [9797329220a2c6622411eb9ecf6a35b24ce09d04] ASoC: sof-function-topology-lib: escalate the log when missing function topoplogy
git bisect start '9823120909776bbca58a3c55ef1f27d49283c1f3' '3575af345aa2424636e69ac101a568bda249abe6' 'ed5d499b5c9cc11dd3edae1a7a55db7dfa4f1bdc' 'e73b743bfe8a6ff4e05b5657d3f7586a17ac3ba0' 'ecd0de438c1f0ee86cf8f6d5047965a2a181444b' '6ef8e042cdcaabe3e3c68592ba8bfbaee2fa10a3' 'f1dfbc1b5cf8650ae9a0d543e5f5335fc0f478ce' '20bcda681f8597e86070a4b3b12d1e4f541865d3' 'cf6bf51b53252284bafc7377a4d8dbf10f048b4d' '8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce' '28039efa4d8e8bbf98b066133a906bd4e307d496' 'e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8' '66fecfa91deb536a12ddf3d878a99590d7900277' 'f034c16a4663eaf3198dc18b201ba50533fb5b81' '4a5ac6cd05a7e54f1585d7779464d6ed6272c134' '4795375d8aa072e9aacb0b278e6203c6ca41816a' 'ef042df96d0e1089764f39ede61bc8f140a4be00' 'e7434adf0c53a84d548226304cdb41c8818da1cb' '01313661b248c5ba586acae09bff57077dbec0a5' 'd29479abaded34b2b1dab2e17efe96a65eba3d61' '4c33cef58965eb655a0ac8e243aa323581ec025f' 'e973dfe9259095fb509ab12658c68d46f0e439d7' '77a58ba7c64ccca20616aa03599766ccb0d1a330' 'c17fa4cbc546c431ccf13e9354d5d9c1cd247b7c' '310bf433c01f78e0756fd5056a43118a2f77318c' '2528c15f314ece50218d1273654f630d74109583' 'd054cc3a2ccfb19484f3b54d69b6e416832dc8f4' 'fd5ef3d69f8975bad16c437a337b5cb04c8217a2' '638bae3fb225a708dc67db613af62f6d14c4eff4' 'ecba655bf54a661ffe078856cd8dbc898270e4b5' '7e1906643a7374529af74b013bba35e4fa4e6ffc' 'd742ebcfe524dc54023f7c520d2ed2e4b7203c19' 'fce217449075d59b29052b8cdac567f0f3e22641' '6658472a3e2de08197acfe099ba71ee0e2505ecf' '0cc08c8130ac8f74419f99fe707dc193b7f79d86' '0743acf746a81e0460a56fd5ff847d97fa7eb370' 'd77daa49085b067137d0adbe3263f75a7ee13a1b' '1e570e77392f43a3cdab2849d1f81535f8a033e2' '15afe57a874eaf104bfbb61ec598fa31627f7b19' '65efe5404d151767653c7b7dd39bd2e7ad532c2d' 'fb25114cd760c13cf177d9ac37837fafcc9657b5' '6621b0f118d500092f5f3d72ddddb22aeeb3c3a0' '0b0eb7702a9fa410755e86124b4b7cd36e7d1cb4' '433e294c3c5b5d2020085a0e36c1cb47b694690a' '7e7e2c6e2a1cb250f8d03bb99eed01f6d982d5dd' '6277a486a7faaa6c87f4bf1d59a2de233a093248' '64d87ccfae3326a9561fe41dc6073064a083e0df' '4412ab501677606436e5c49e41151a1e6eac7ac0' '5e537031f322d55315cd384398b726a9a0748d47' '4d410ba9aa275e7990a270f63ce436990ace1bea' 'fe8cc44dd173cde5788ab4e3730ac61f3d316d9c' 'b83fb1b14c06bdd765903ac852ba20a14e24f227' '9797329220a2c6622411eb9ecf6a35b24ce09d04'
# test job: [ed5d499b5c9cc11dd3edae1a7a55db7dfa4f1bdc] https://lava.sirena.org.uk/scheduler/job/2029024
# test job: [e73b743bfe8a6ff4e05b5657d3f7586a17ac3ba0] https://lava.sirena.org.uk/scheduler/job/2026405
# test job: [ecd0de438c1f0ee86cf8f6d5047965a2a181444b] https://lava.sirena.org.uk/scheduler/job/2026139
# test job: [6ef8e042cdcaabe3e3c68592ba8bfbaee2fa10a3] https://lava.sirena.org.uk/scheduler/job/2025827
# test job: [f1dfbc1b5cf8650ae9a0d543e5f5335fc0f478ce] https://lava.sirena.org.uk/scheduler/job/2025495
# test job: [20bcda681f8597e86070a4b3b12d1e4f541865d3] https://lava.sirena.org.uk/scheduler/job/2023002
# test job: [cf6bf51b53252284bafc7377a4d8dbf10f048b4d] https://lava.sirena.org.uk/scheduler/job/2023010
# test job: [8fdb030fe283c84fd8d378c97ad0f32d6cdec6ce] https://lava.sirena.org.uk/scheduler/job/2021423
# test job: [28039efa4d8e8bbf98b066133a906bd4e307d496] https://lava.sirena.org.uk/scheduler/job/2020312
# test job: [e062bdfdd6adbb2dee7751d054c1d8df63ddb8b8] https://lava.sirena.org.uk/scheduler/job/2020146
# test job: [66fecfa91deb536a12ddf3d878a99590d7900277] https://lava.sirena.org.uk/scheduler/job/2015355
# test job: [f034c16a4663eaf3198dc18b201ba50533fb5b81] https://lava.sirena.org.uk/scheduler/job/2015401
# test job: [4a5ac6cd05a7e54f1585d7779464d6ed6272c134] https://lava.sirena.org.uk/scheduler/job/2011275
# test job: [4795375d8aa072e9aacb0b278e6203c6ca41816a] https://lava.sirena.org.uk/scheduler/job/2009637
# test job: [ef042df96d0e1089764f39ede61bc8f140a4be00] https://lava.sirena.org.uk/scheduler/job/2010189
# test job: [e7434adf0c53a84d548226304cdb41c8818da1cb] https://lava.sirena.org.uk/scheduler/job/2007769
# test job: [01313661b248c5ba586acae09bff57077dbec0a5] https://lava.sirena.org.uk/scheduler/job/2008804
# test job: [d29479abaded34b2b1dab2e17efe96a65eba3d61] https://lava.sirena.org.uk/scheduler/job/2008456
# test job: [4c33cef58965eb655a0ac8e243aa323581ec025f] https://lava.sirena.org.uk/scheduler/job/2009446
# test job: [e973dfe9259095fb509ab12658c68d46f0e439d7] https://lava.sirena.org.uk/scheduler/job/2008154
# test job: [77a58ba7c64ccca20616aa03599766ccb0d1a330] https://lava.sirena.org.uk/scheduler/job/2007294
# test job: [c17fa4cbc546c431ccf13e9354d5d9c1cd247b7c] https://lava.sirena.org.uk/scheduler/job/2000033
# test job: [310bf433c01f78e0756fd5056a43118a2f77318c] https://lava.sirena.org.uk/scheduler/job/1996006
# test job: [2528c15f314ece50218d1273654f630d74109583] https://lava.sirena.org.uk/scheduler/job/1997609
# test job: [d054cc3a2ccfb19484f3b54d69b6e416832dc8f4] https://lava.sirena.org.uk/scheduler/job/1995710
# test job: [fd5ef3d69f8975bad16c437a337b5cb04c8217a2] https://lava.sirena.org.uk/scheduler/job/1996160
# test job: [638bae3fb225a708dc67db613af62f6d14c4eff4] https://lava.sirena.org.uk/scheduler/job/1991858
# test job: [ecba655bf54a661ffe078856cd8dbc898270e4b5] https://lava.sirena.org.uk/scheduler/job/1985138
# test job: [7e1906643a7374529af74b013bba35e4fa4e6ffc] https://lava.sirena.org.uk/scheduler/job/1978644
# test job: [d742ebcfe524dc54023f7c520d2ed2e4b7203c19] https://lava.sirena.org.uk/scheduler/job/1975972
# test job: [fce217449075d59b29052b8cdac567f0f3e22641] https://lava.sirena.org.uk/scheduler/job/1975665
# test job: [6658472a3e2de08197acfe099ba71ee0e2505ecf] https://lava.sirena.org.uk/scheduler/job/1975550
# test job: [0cc08c8130ac8f74419f99fe707dc193b7f79d86] https://lava.sirena.org.uk/scheduler/job/1965723
# test job: [0743acf746a81e0460a56fd5ff847d97fa7eb370] https://lava.sirena.org.uk/scheduler/job/1964844
# test job: [d77daa49085b067137d0adbe3263f75a7ee13a1b] https://lava.sirena.org.uk/scheduler/job/1962817
# test job: [1e570e77392f43a3cdab2849d1f81535f8a033e2] https://lava.sirena.org.uk/scheduler/job/1962293
# test job: [15afe57a874eaf104bfbb61ec598fa31627f7b19] https://lava.sirena.org.uk/scheduler/job/1962946
# test job: [65efe5404d151767653c7b7dd39bd2e7ad532c2d] https://lava.sirena.org.uk/scheduler/job/1959944
# test job: [fb25114cd760c13cf177d9ac37837fafcc9657b5] https://lava.sirena.org.uk/scheduler/job/1960141
# test job: [6621b0f118d500092f5f3d72ddddb22aeeb3c3a0] https://lava.sirena.org.uk/scheduler/job/1959728
# test job: [0b0eb7702a9fa410755e86124b4b7cd36e7d1cb4] https://lava.sirena.org.uk/scheduler/job/1957410
# test job: [433e294c3c5b5d2020085a0e36c1cb47b694690a] https://lava.sirena.org.uk/scheduler/job/1957405
# test job: [7e7e2c6e2a1cb250f8d03bb99eed01f6d982d5dd] https://lava.sirena.org.uk/scheduler/job/1954272
# test job: [6277a486a7faaa6c87f4bf1d59a2de233a093248] https://lava.sirena.org.uk/scheduler/job/1947019
# test job: [64d87ccfae3326a9561fe41dc6073064a083e0df] https://lava.sirena.org.uk/scheduler/job/1947206
# test job: [4412ab501677606436e5c49e41151a1e6eac7ac0] https://lava.sirena.org.uk/scheduler/job/1946280
# test job: [5e537031f322d55315cd384398b726a9a0748d47] https://lava.sirena.org.uk/scheduler/job/1946649
# test job: [4d410ba9aa275e7990a270f63ce436990ace1bea] https://lava.sirena.org.uk/scheduler/job/1947851
# test job: [fe8cc44dd173cde5788ab4e3730ac61f3d316d9c] https://lava.sirena.org.uk/scheduler/job/1947062
# test job: [b83fb1b14c06bdd765903ac852ba20a14e24f227] https://lava.sirena.org.uk/scheduler/job/1946842
# test job: [9797329220a2c6622411eb9ecf6a35b24ce09d04] https://lava.sirena.org.uk/scheduler/job/1947376
# test job: [9823120909776bbca58a3c55ef1f27d49283c1f3] https://lava.sirena.org.uk/scheduler/job/2036229
# bad: [9823120909776bbca58a3c55ef1f27d49283c1f3] Add linux-next specific files for 20251103
git bisect bad 9823120909776bbca58a3c55ef1f27d49283c1f3
# test job: [32db2b6bea82a3565aac82569f0a5dd3f808b1c9] https://lava.sirena.org.uk/scheduler/job/2036846
# good: [32db2b6bea82a3565aac82569f0a5dd3f808b1c9] Merge branch 'nand/next' of https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
git bisect good 32db2b6bea82a3565aac82569f0a5dd3f808b1c9
# test job: [b6ee14cdb3b42da9d2c3773014abca821e5bd6b6] https://lava.sirena.org.uk/scheduler/job/2036933
# good: [b6ee14cdb3b42da9d2c3773014abca821e5bd6b6] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
git bisect good b6ee14cdb3b42da9d2c3773014abca821e5bd6b6
# test job: [4bf8b41b640db6006ae9415262fac145590f69e3] https://lava.sirena.org.uk/scheduler/job/2036996
# bad: [4bf8b41b640db6006ae9415262fac145590f69e3] Merge branch 'driver-core-next' of https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git
git bisect bad 4bf8b41b640db6006ae9415262fac145590f69e3
# test job: [3eaa2454f5701a95dd0e7d080b3afd60b1e83ffa] https://lava.sirena.org.uk/scheduler/job/2037194
# bad: [3eaa2454f5701a95dd0e7d080b3afd60b1e83ffa] Merge branch into tip/master: 'timers/vdso'
git bisect bad 3eaa2454f5701a95dd0e7d080b3afd60b1e83ffa
# test job: [10eaf0467388d7cd57b7bd6075c3c5716e204184] https://lava.sirena.org.uk/scheduler/job/2037413
# good: [10eaf0467388d7cd57b7bd6075c3c5716e204184] Merge branch into tip/master: 'objtool/core'
git bisect good 10eaf0467388d7cd57b7bd6075c3c5716e204184
# test job: [973d20365abff9f24919deb015b12ef76aed0ff8] https://lava.sirena.org.uk/scheduler/job/2037436
# good: [973d20365abff9f24919deb015b12ef76aed0ff8] Merge branch into tip/master: 'x86/entry'
git bisect good 973d20365abff9f24919deb015b12ef76aed0ff8
# test job: [184372e1d10789d8730971070630ba5a10c9be34] https://lava.sirena.org.uk/scheduler/job/2037468
# bad: [184372e1d10789d8730971070630ba5a10c9be34] sparc64: vdso: Implement clock_gettime64()
git bisect bad 184372e1d10789d8730971070630ba5a10c9be34
# test job: [189163e207c49196e52e86737dc3048f37a8eee9] https://lava.sirena.org.uk/scheduler/job/2037700
# good: [189163e207c49196e52e86737dc3048f37a8eee9] random: vDSO: Remove ifdeffery
git bisect good 189163e207c49196e52e86737dc3048f37a8eee9
# test job: [1280e8b97d703a686eb2270c5723f2d44e99252e] https://lava.sirena.org.uk/scheduler/job/2037739
# bad: [1280e8b97d703a686eb2270c5723f2d44e99252e] sparc64: vdso: Link with -z noexecstack
git bisect bad 1280e8b97d703a686eb2270c5723f2d44e99252e
# test job: [5fd2a3424ce51df60deade50d5057177439c62b5] https://lava.sirena.org.uk/scheduler/job/2038036
# good: [5fd2a3424ce51df60deade50d5057177439c62b5] vdso/datastore: Reduce scope of some variables in vvar_fault()
git bisect good 5fd2a3424ce51df60deade50d5057177439c62b5
# test job: [6a011a22829362bfee8ff9fc1212f803c18af5f2] https://lava.sirena.org.uk/scheduler/job/2038079
# bad: [6a011a22829362bfee8ff9fc1212f803c18af5f2] vdso/datastore: Map pages through struct page
git bisect bad 6a011a22829362bfee8ff9fc1212f803c18af5f2
# test job: [8ebb65c38828760ed028f637850d4b4c62655993] https://lava.sirena.org.uk/scheduler/job/2038136
# good: [8ebb65c38828760ed028f637850d4b4c62655993] vdso/datastore: Drop inclusion of linux/mmap_lock.h
git bisect good 8ebb65c38828760ed028f637850d4b4c62655993
# first bad commit: [6a011a22829362bfee8ff9fc1212f803c18af5f2] vdso/datastore: Map pages through struct page

On 03.11.2025 16:24, Mark Brown wrote:
> On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:
>
>> An upcoming change will allocate the datapages dynamically instead of as
>> part of the kernel image. Such pages can only be mapped through
>> 'struct page' and not through PFNs.
> I'm seeing some boot failures on some arm64 platforms in -next which are
> bisecting to this patch in -next.  Unfortunately the diagnostics aren't
> super useful, we seem to just stop making progress in userspace with no
> obvious output.  One sample log from the FVP is:
>
>     https://lava.sirena.org.uk/scheduler/job/2036229#L1268
>
> which isn't super instructive.  Not all platforms seem to be affected,
> I've seen this on at least the Arm FVP, Orion O6 and Libretech Renegade
> Elite.  The diagnostics aren't very clear here but given that I'm seeing
> the same issue and bisect result on multiple platforms it seemed worth
> mentioning.  Some platforms do seem fine.
>
> We do have some other serious breakage affecting arm64 in -next which
> are making it hard to get a clear picture of which platforms are
> affected, at least the FVP and O6 are unaffected by those other issues
> (due to using MTE on platforms that don't have it, those platforms do
> have MTE).

I got almost the same result while bisecting on ARM 32bit Exynos-based 
boards, so the issue with this patchset is not fully ARM64 specific. For 
some reasons it also doesn't affect all systems though. It is even 
worse, because it affected only a subset of boards, but different for 
each tested commit. The observed failure looks exactly the same:

...

[   10.199852] devtmpfs: mounted
[   10.205013] Freeing unused kernel image (initmem) memory: 1024K
[   10.210086] Run /sbin/init as init process

INIT: version 2.88 booting

(no more messages)

The only difference is that bisecting on ARM32bit lead me to the next 
patch (10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically") 
/ [PATCH v4 24/35]).

Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
following panic on 6a011a228293 ("vdso/datastore: Map pages through 
struct page") commit:

VFS: Mounted root (ext4 filesystem) on device 179:3. Trying to move old 
root to /initrd ... okay devtmpfs: mounted Freeing unused kernel memory: 
12672K Run /sbin/init as init process Unable to handle kernel paging 
request at virtual address ffffffffc20b5d48 Mem abort info: ESR = 
0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, 
FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data 
abort info: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 
0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 
swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000230b000 
[ffffffffc20b5d48] pgd=0000000000000000, p4d=0000000003618403, 
pud=0000000003619403, pmd=0000000000000000 Internal error: Oops: 
0000000096000006 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 1 Comm: 
init Tainted: G W 6.18.0-rc1+ #16136 PREEMPT Tainted: [W]=WARN Hardware 
name: Raspberry Pi 3 Model B (DT) pstate: 80000005 (Nzcv daif -PAN -UAO 
-TCO -DIT -SSBS BTYPE=--) pc : vvar_fault+0x7c/0x17c lr : 
vvar_fault+0x24/0x17c ... Call trace: vvar_fault+0x7c/0x17c (P) 
special_mapping_fault+0x24/0xd0 __do_fault+0x3c/0x238 
__handle_mm_fault+0xaa0/0x19e0 handle_mm_fault+0xcc/0x384 
do_page_fault+0x1a0/0x720 do_translation_fault+0x60/0x6c 
do_mem_abort+0x44/0x94 el0_da+0x54/0x230 el0t_64_sync_handler+0xd0/0xe4 
el0t_64_sync+0x198/0x19c Code: f2d83fe0 8b010063 d34cfc63 8b031803 
(f9400461) ---[ end trace 0000000000000000 ]--- Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x0000000b SMP: stopping 
secondary CPUs Kernel Offset: disabled CPU features: 
0x000000,00180000,40004000,0400421b Memory Limit: none ---[ end Kernel 
panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---

Reverting "clocksource: Remove ARCH_CLOCKSOURCE_DATA", "vdso/datastore: 
Allocate data pages dynamically" and "vdso/datastore: Map pages through 
struct page" on top of linux-next fixes booting on all tested boards.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:
> On 03.11.2025 16:24, Mark Brown wrote:
> > On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:

Copying in Ryan Roberts who's much more likely to have some idea about
memory management stuff for arm64 than I am (I have been poking at this
a bit but not got anywhere notable).  Not deleting context for his
benefit.

Given that this issue is very disruptive to userspace it's causing us to
miss huge amounts of test coverage for -next, would it be possible to
drop these patches until we resolve the issue?

> >> An upcoming change will allocate the datapages dynamically instead of as
> >> part of the kernel image. Such pages can only be mapped through
> >> 'struct page' and not through PFNs.

> > I'm seeing some boot failures on some arm64 platforms in -next which are
> > bisecting to this patch in -next.  Unfortunately the diagnostics aren't
> > super useful, we seem to just stop making progress in userspace with no
> > obvious output.  One sample log from the FVP is:

> >     https://lava.sirena.org.uk/scheduler/job/2036229#L1268

> > which isn't super instructive.  Not all platforms seem to be affected,
> > I've seen this on at least the Arm FVP, Orion O6 and Libretech Renegade
> > Elite.  The diagnostics aren't very clear here but given that I'm seeing
> > the same issue and bisect result on multiple platforms it seemed worth
> > mentioning.  Some platforms do seem fine.
> >
> > We do have some other serious breakage affecting arm64 in -next which
> > are making it hard to get a clear picture of which platforms are
> > affected, at least the FVP and O6 are unaffected by those other issues
> > (due to using MTE on platforms that don't have it, those platforms do
> > have MTE).
> 
> I got almost the same result while bisecting on ARM 32bit Exynos-based 
> boards, so the issue with this patchset is not fully ARM64 specific. For 
> some reasons it also doesn't affect all systems though. It is even 
> worse, because it affected only a subset of boards, but different for 
> each tested commit. The observed failure looks exactly the same:
> 
> ...
> 
> [   10.199852] devtmpfs: mounted
> [   10.205013] Freeing unused kernel image (initmem) memory: 1024K
> [   10.210086] Run /sbin/init as init process
> 
> INIT: version 2.88 booting
> 
> (no more messages)
> 
> The only difference is that bisecting on ARM32bit lead me to the next 
> patch (10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically") 
> / [PATCH v4 24/35]).
> 
> Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
> following panic on 6a011a228293 ("vdso/datastore: Map pages through 
> struct page") commit:
> 
> VFS: Mounted root (ext4 filesystem) on device 179:3. Trying to move old 
> root to /initrd ... okay devtmpfs: mounted Freeing unused kernel memory: 
> 12672K Run /sbin/init as init process Unable to handle kernel paging 
> request at virtual address ffffffffc20b5d48 Mem abort info: ESR = 
> 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, 
> FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data 
> abort info: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 
> 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 
> swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000230b000 
> [ffffffffc20b5d48] pgd=0000000000000000, p4d=0000000003618403, 
> pud=0000000003619403, pmd=0000000000000000 Internal error: Oops: 
> 0000000096000006 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 1 Comm: 
> init Tainted: G W 6.18.0-rc1+ #16136 PREEMPT Tainted: [W]=WARN Hardware 
> name: Raspberry Pi 3 Model B (DT) pstate: 80000005 (Nzcv daif -PAN -UAO 
> -TCO -DIT -SSBS BTYPE=--) pc : vvar_fault+0x7c/0x17c lr : 
> vvar_fault+0x24/0x17c ... Call trace: vvar_fault+0x7c/0x17c (P) 
> special_mapping_fault+0x24/0xd0 __do_fault+0x3c/0x238 
> __handle_mm_fault+0xaa0/0x19e0 handle_mm_fault+0xcc/0x384 
> do_page_fault+0x1a0/0x720 do_translation_fault+0x60/0x6c 
> do_mem_abort+0x44/0x94 el0_da+0x54/0x230 el0t_64_sync_handler+0xd0/0xe4 
> el0t_64_sync+0x198/0x19c Code: f2d83fe0 8b010063 d34cfc63 8b031803 
> (f9400461) ---[ end trace 0000000000000000 ]--- Kernel panic - not 
> syncing: Attempted to kill init! exitcode=0x0000000b SMP: stopping 
> secondary CPUs Kernel Offset: disabled CPU features: 
> 0x000000,00180000,40004000,0400421b Memory Limit: none ---[ end Kernel 
> panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> 
> Reverting "clocksource: Remove ARCH_CLOCKSOURCE_DATA", "vdso/datastore: 
> Allocate data pages dynamically" and "vdso/datastore: Map pages through 
> struct page" on top of linux-next fixes booting on all tested boards.

Hi Mark,

On Thu, Nov 06, 2025 at 01:28:35PM +0000, Mark Brown wrote:
> On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:
> > On 03.11.2025 16:24, Mark Brown wrote:
> > > On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:
> 
> Copying in Ryan Roberts who's much more likely to have some idea about
> memory management stuff for arm64 than I am (I have been poking at this
> a bit but not got anywhere notable).  Not deleting context for his
> benefit.

It turned out not even to be an mm problem.
Instead the data pages were not zeroed out on allocation.

> Given that this issue is very disruptive to userspace it's causing us to
> miss huge amounts of test coverage for -next, would it be possible to
> drop these patches until we resolve the issue?

This issue and the observed panics should be fixed in v5 of the series:
https://lore.kernel.org/lkml/20251106-vdso-sparc64-generic-2-v5-0-97ff2b6542f7@linutronix.de/

I'll ping tglx directly.

(...)


Thomas

On Thu, Nov 06, 2025 at 02:32:56PM +0100, Thomas Weißschuh wrote:
> On Thu, Nov 06, 2025 at 01:28:35PM +0000, Mark Brown wrote:

> > Given that this issue is very disruptive to userspace it's causing us to
> > miss huge amounts of test coverage for -next, would it be possible to
> > drop these patches until we resolve the issue?

> This issue and the observed panics should be fixed in v5 of the series:
> https://lore.kernel.org/lkml/20251106-vdso-sparc64-generic-2-v5-0-97ff2b6542f7@linutronix.de/

> I'll ping tglx directly.

Ah, fantastic - I wasn't aware of the new version.

On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:

> I got almost the same result while bisecting on ARM 32bit Exynos-based 
> boards, so the issue with this patchset is not fully ARM64 specific. For 
> some reasons it also doesn't affect all systems though. It is even 
> worse, because it affected only a subset of boards, but different for 
> each tested commit. The observed failure looks exactly the same:

I'm also seeing other architectures affected looking at -next, I see the
Avenger96 (32 bit Arm) and VisionFive 2 (RISC-V) with bisects coming out
on the merge of the branch or on

# first bad commit: [10d91dac2ea5ddf04e647cf862430d1051adb839] vdso/datastore: Allocate data pages dynamically

It looks like the uniprocessor boards I've got (at91sam9g20ek,
BeagleBone Black) are running fine.

On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:
> On 03.11.2025 16:24, Mark Brown wrote:

> > We do have some other serious breakage affecting arm64 in -next which
> > are making it hard to get a clear picture of which platforms are
> > affected, at least the FVP and O6 are unaffected by those other issues
> > (due to using MTE on platforms that don't have it, those platforms do
> > have MTE).

> I got almost the same result while bisecting on ARM 32bit Exynos-based 
> boards, so the issue with this patchset is not fully ARM64 specific. For 
> some reasons it also doesn't affect all systems though. It is even 
> worse, because it affected only a subset of boards, but different for 
> each tested commit. The observed failure looks exactly the same:

I've now got the results for this specific commit, it looks like every
single arm64 system is failing.  I didn't test any other architectures.

> Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
> following panic on 6a011a228293 ("vdso/datastore: Map pages through 
> struct page") commit:

I'm seeing the same thing on at least some of the systems - this is with
arm64 defconfig (I suspect that's what Marek is doing too).  For
example:

   https://lava.sirena.org.uk/scheduler/job/2039543#L1109

I didn't check every single failure.  Feeding one of the backtraces
through addr2line says:

/build/stage/linux/include/linux/page-flags.h:284 (discriminator 2)
/build/stage/linux/mm/mmap.c:1438
/build/stage/linux/mm/memory.c:5280
/build/stage/linux/mm/memory.c:5698
/build/stage/linux/mm/memory.c:6487
/build/stage/linux/arch/arm64/mm/fault.c:696
/build/stage/linux/arch/arm64/mm/fault.c:793
/build/stage/linux/arch/arm64/mm/fault.c:929 (discriminator 1)
/build/stage/linux/arch/arm64/include/asm/irqflags.h:55
/build/stage/linux/arch/arm64/kernel/entry-common.c:767
/build/stage/linux/arch/arm64/kernel/entry.S:596

(this is for this specific commit.)

On Tue, Nov 04, 2025 at 01:14:03PM +0000, Mark Brown wrote:
> On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:
> > On 03.11.2025 16:24, Mark Brown wrote:
> 
> > > We do have some other serious breakage affecting arm64 in -next which
> > > are making it hard to get a clear picture of which platforms are
> > > affected, at least the FVP and O6 are unaffected by those other issues
> > > (due to using MTE on platforms that don't have it, those platforms do
> > > have MTE).
> 
> > I got almost the same result while bisecting on ARM 32bit Exynos-based 
> > boards, so the issue with this patchset is not fully ARM64 specific. For 
> > some reasons it also doesn't affect all systems though. It is even 
> > worse, because it affected only a subset of boards, but different for 
> > each tested commit. The observed failure looks exactly the same:
> 
> I've now got the results for this specific commit, it looks like every
> single arm64 system is failing.  I didn't test any other architectures.

Which one do you mean exactly with "this specific commit"?

6a011a228293 ("vdso/datastore: Map pages through struct page")
10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically")

> > Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
> > following panic on 6a011a228293 ("vdso/datastore: Map pages through 
> > struct page") commit:
> 
> I'm seeing the same thing on at least some of the systems - this is with
> arm64 defconfig (I suspect that's what Marek is doing too).  For
> example:

I can now reproduce this issue, too. Even on QEMU. But it goes away,
as soon as the second commit is applied. The two commits should be merged.
That could also explain the weird bisection results, landing on either one
of the commits. However I can't reproduce the "silent freeze" issue on commit
10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically") on my
Raspberry Pi 3b+.

Any chance I could get remote access to one of your test machines?
I don't have access to the exact machines and that should reduce the chance
of chasing down dead ends.


Thomas

On Tue, Nov 04, 2025 at 04:43:34PM +0100, Thomas Weißschuh wrote:
> On Tue, Nov 04, 2025 at 01:14:03PM +0000, Mark Brown wrote:

> > I've now got the results for this specific commit, it looks like every
> > single arm64 system is failing.  I didn't test any other architectures.

> Which one do you mean exactly with "this specific commit"?

> 6a011a228293 ("vdso/datastore: Map pages through struct page")
> 10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically")

The one in the thread being replied to here, the first.

> Any chance I could get remote access to one of your test machines?
> I don't have access to the exact machines and that should reduce the chance
> of chasing down dead ends.

I can let you submit LAVA jobs to my lab (there's an API, a web
interface for (re)submitting jobs and a CLI tool for shoving jobs in) if
that works?  That's how my own access to it works unless I go pull
boards out.  You should be able to resubmit existing jobs, it downloads
test binaries over HTTP.

On Tue, Nov 04, 2025 at 03:47:13PM +0000, Mark Brown wrote:
> On Tue, Nov 04, 2025 at 04:43:34PM +0100, Thomas Weißschuh wrote:
> > On Tue, Nov 04, 2025 at 01:14:03PM +0000, Mark Brown wrote:
> 
> > > I've now got the results for this specific commit, it looks like every
> > > single arm64 system is failing.  I didn't test any other architectures.
> 
> > Which one do you mean exactly with "this specific commit"?
> 
> > 6a011a228293 ("vdso/datastore: Map pages through struct page")
> > 10d91dac2ea5 ("vdso/datastore: Allocate data pages dynamically")
> 
> The one in the thread being replied to here, the first.

Ack.

> > Any chance I could get remote access to one of your test machines?
> > I don't have access to the exact machines and that should reduce the chance
> > of chasing down dead ends.
> 
> I can let you submit LAVA jobs to my lab (there's an API, a web
> interface for (re)submitting jobs and a CLI tool for shoving jobs in) if
> that works?  That's how my own access to it works unless I go pull
> boards out.  You should be able to resubmit existing jobs, it downloads
> test binaries over HTTP.

Sounds good.


Thomas

On Tue, Nov 04, 2025 at 05:03:28PM +0100, Thomas Weißschuh wrote:
> On Tue, Nov 04, 2025 at 03:47:13PM +0000, Mark Brown wrote:

> > I can let you submit LAVA jobs to my lab (there's an API, a web
> > interface for (re)submitting jobs and a CLI tool for shoving jobs in) if
> > that works?  That's how my own access to it works unless I go pull
> > boards out.  You should be able to resubmit existing jobs, it downloads
> > test binaries over HTTP.

> Sounds good.

OK, folllowing up off-list for that.

Hi Marek,

On Tue, Nov 04, 2025 at 09:44:38AM +0100, Marek Szyprowski wrote:
> On 03.11.2025 16:24, Mark Brown wrote:
> > On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:
> >
> >> An upcoming change will allocate the datapages dynamically instead of as
> >> part of the kernel image. Such pages can only be mapped through
> >> 'struct page' and not through PFNs.
> > I'm seeing some boot failures on some arm64 platforms in -next which are
> > bisecting to this patch in -next.  Unfortunately the diagnostics aren't
> > super useful, we seem to just stop making progress in userspace with no
> > obvious output.  One sample log from the FVP is:

(...)

> Then I've tested it on ARM64bit (RaspberrryPi3b+ board) and got the 
> following panic on 6a011a228293 ("vdso/datastore: Map pages through 
> struct page") commit:
> 
> VFS: Mounted root (ext4 filesystem) on device 179:3. Trying to move old 
> root to /initrd ... okay devtmpfs: mounted Freeing unused kernel memory: 
> 12672K Run /sbin/init as init process Unable to handle kernel paging 
> request at virtual address ffffffffc20b5d48 Mem abort info: ESR = 
> 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, 
> FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data 
> abort info: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 
> 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 
> swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000230b000 
> [ffffffffc20b5d48] pgd=0000000000000000, p4d=0000000003618403, 
> pud=0000000003619403, pmd=0000000000000000 Internal error: Oops: 
> 0000000096000006 [#1] SMP Modules linked in: CPU: 2 UID: 0 PID: 1 Comm: 
> init Tainted: G W 6.18.0-rc1+ #16136 PREEMPT Tainted: [W]=WARN Hardware 
> name: Raspberry Pi 3 Model B (DT) pstate: 80000005 (Nzcv daif -PAN -UAO 
> -TCO -DIT -SSBS BTYPE=--) pc : vvar_fault+0x7c/0x17c lr : 
> vvar_fault+0x24/0x17c ... Call trace: vvar_fault+0x7c/0x17c (P) 
> special_mapping_fault+0x24/0xd0 __do_fault+0x3c/0x238 
> __handle_mm_fault+0xaa0/0x19e0 handle_mm_fault+0xcc/0x384 
> do_page_fault+0x1a0/0x720 do_translation_fault+0x60/0x6c 
> do_mem_abort+0x44/0x94 el0_da+0x54/0x230 el0t_64_sync_handler+0xd0/0xe4 
> el0t_64_sync+0x198/0x19c Code: f2d83fe0 8b010063 d34cfc63 8b031803 
> (f9400461) ---[ end trace 0000000000000000 ]--- Kernel panic - not 
> syncing: Attempted to kill init! exitcode=0x0000000b SMP: stopping 
> secondary CPUs Kernel Offset: disabled CPU features: 
> 0x000000,00180000,40004000,0400421b Memory Limit: none ---[ end Kernel 
> panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> 
> Reverting "clocksource: Remove ARCH_CLOCKSOURCE_DATA", "vdso/datastore: 
> Allocate data pages dynamically" and "vdso/datastore: Map pages through 
> struct page" on top of linux-next fixes booting on all tested boards.

Thanks for the report. I have a Raspberry Pi 3 Model B V1.2 here and will try
to reproduce the issue with it.
Can you send me your kernel configuration?
Which line is vvar_fault+0x7c/0x17c?


Thomas

On Mon, Nov 03 2025 at 15:24, Mark Brown wrote:
> On Tue, Oct 14, 2025 at 08:49:09AM +0200, Thomas Weißschuh wrote:
>
>> An upcoming change will allocate the datapages dynamically instead of as
>> part of the kernel image. Such pages can only be mapped through
>> 'struct page' and not through PFNs.
>
> I'm seeing some boot failures on some arm64 platforms in -next which are
> bisecting to this patch in -next.  Unfortunately the diagnostics aren't
> super useful, we seem to just stop making progress in userspace with no
> obvious output.  One sample log from the FVP is:
>
>    https://lava.sirena.org.uk/scheduler/job/2036229#L1268
>
> which isn't super instructive.  Not all platforms seem to be affected,
> I've seen this on at least the Arm FVP, Orion O6 and Libretech Renegade
> Elite.  The diagnostics aren't very clear here but given that I'm seeing
> the same issue and bisect result on multiple platforms it seemed worth
> mentioning.  Some platforms do seem fine.

Can you try

    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso

which is rc1 based and only contains the VDSO changes. That might give
us a better hint.

Thanks,

        tglx

On Mon, Nov 03, 2025 at 04:54:01PM +0100, Thomas Gleixner wrote:
> On Mon, Nov 03 2025 at 15:24, Mark Brown wrote:

> > which isn't super instructive.  Not all platforms seem to be affected,
> > I've seen this on at least the Arm FVP, Orion O6 and Libretech Renegade
> > Elite.  The diagnostics aren't very clear here but given that I'm seeing
> > the same issue and bisect result on multiple platforms it seemed worth
> > mentioning.  Some platforms do seem fine.

> Can you try

>     git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/vdso

> which is rc1 based and only contains the VDSO changes. That might give
> us a better hint.

Yeah, hopefully - my infrastructure is pretty swamped ATM and I'm in an
internal conference.  I did kick something off earlier on this specific
commit which should be equivalent information but it'll be tomorrow
before I can get a full picture.