* linux-next: manual merge of the device-id tree with the iio tree
From: Mark Brown @ 2026-07-02 17:43 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jonathan Cameron, Linux Kernel Mailing List,
Linux Next Mailing List, Miao Li, Uwe Kleine-König
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
Hi all,
Today's linux-next merge of the device-id tree got a conflict in:
drivers/iio/accel/stk8ba50.c
between commit:
e8de771d80a3a ("iio: accel: stk8ba50: Update includes to match IWYU")
from the iio tree and commit:
80f98bb4f07ea ("Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)")
from the device-id tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/iio/accel/stk8ba50.c
index 4bacc007897ae,d0c53b8ac850a..0000000000000
--- a/drivers/iio/accel/stk8ba50.c
+++ b/drivers/iio/accel/stk8ba50.c
@@@ -7,19 -7,11 +7,18 @@@
* STK8BA50 7-bit I2C address: 0x18.
*/
+#include <linux/array_size.h>
+#include <linux/bitops.h>
+#include <linux/dev_printk.h>
+#include <linux/errno.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
-#include <linux/kernel.h>
#include <linux/module.h>
- #include <linux/mod_devicetable.h>
+#include <linux/mutex.h>
+#include <linux/pm.h>
+#include <linux/sysfs.h>
#include <linux/types.h>
+
#include <linux/iio/buffer.h>
#include <linux/iio/iio.h>
#include <linux/iio/sysfs.h>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Update i2c branches
From: Mark Brown @ 2026-07-02 18:11 UTC (permalink / raw)
To: Andi Shyti; +Cc: linux-next
In-Reply-To: <akaWcTjDlww10fsR@zenone.zhora.eu>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Thu, Jul 02, 2026 at 06:50:42PM +0200, Andi Shyti wrote:
> > I'm not sure it is sensible for me to merge all three, if I pull both
> > i2c and i2c-next then I'll end up having to redo all the conflict
> > resolutions you've done in i2c-next. Potentially I'll get conflicts due
> > to doing something slightly differently, or the additional stuff in
> > i2c-next only overlapping with conflict resolutions. If i2c-next
> > contains i2c it seems more sensible to get i2c via that instead and
> > avoid the hassle?
> OK, sure, you can also only include i2c-next.
Great, I've updated to replace i2c-host with your i2c-next branch instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure in final build
From: Mark Brown @ 2026-07-02 18:26 UTC (permalink / raw)
To: Kir Chou, David Gow, Andrew Morton, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP)
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
Hi all,
After merging the kthread tree, today's linux-next build
(powerpc pseries_le_defconfig) failed like this:
ERROR: modpost: module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it.
make[3]: *** [/tmp/next/build/scripts/Makefile.modpost:147: Module.symvers] Error 1
make[2]: *** [/tmp/next/build/Makefile:2134: modpost] Error 2
make[1]: *** [/tmp/next/build/Makefile:248: __sub-make] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Caused by commit
2ee1282ed36ff (lib/random32: convert selftest to KUnit)
This appears to be showing up in this specific PowerPC configuration
because ppc64_defconfig turns on
CONFIG_KUNIT=m
CONFIG_KUNIT_ALL_TESTS=m
which is an unusual choice, normally defconfigs don't turn on KUnit and
when KUnit is enabled it is built in.
I have ignored this for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 2
From: Mark Brown @ 2026-07-02 18:29 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
Hi all,
Changes since 20260701:
The vfs-brauner tree lost it's test failure.
The mm-nonmm-unstable tree acquired a conflict with the tip-fixes tree.
The risc-v tree acquired a conflict with the mm-unstable tree.
The net-next tree acquired a conflict with the vfs-brauner tree.
The amdgpu tree acquired a conflict with the origin tree.
The amdgpu tree acquired a conflict with the drm tree.
The device-id tree acquired a conflict with the iio tree.
The mm-nononmm-unstable tree acquired a build failure.
Non-merge commits (relative to Linus' tree): 2945
4620 files changed, 111949 insertions(+), 61215 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 427 trees (counting Linus' and 132 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the device-id tree with the iio tree
From: Jonathan Cameron @ 2026-07-02 18:39 UTC (permalink / raw)
To: Mark Brown
Cc: Uwe Kleine-König, Linux Kernel Mailing List,
Linux Next Mailing List, Miao Li, Uwe Kleine-König
In-Reply-To: <akajRDPG1mkYFL9K@sirena.org.uk>
On Thu, 2 Jul 2026 18:43:32 +0100
Mark Brown <broonie@kernel.org> wrote:
> Hi all,
>
> Today's linux-next merge of the device-id tree got a conflict in:
>
> drivers/iio/accel/stk8ba50.c
>
> between commit:
>
> e8de771d80a3a ("iio: accel: stk8ba50: Update includes to match IWYU")
>
> from the iio tree and commit:
>
> 80f98bb4f07ea ("Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)")
>
> from the device-id tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks. That header drop patch is likely to cause quite a lot of context
and minor merge conflicts. I guess that'll resolve if anyone affected
merges in rc2 once available.
Jonathan
>
> diff --cc drivers/iio/accel/stk8ba50.c
> index 4bacc007897ae,d0c53b8ac850a..0000000000000
> --- a/drivers/iio/accel/stk8ba50.c
> +++ b/drivers/iio/accel/stk8ba50.c
> @@@ -7,19 -7,11 +7,18 @@@
> * STK8BA50 7-bit I2C address: 0x18.
> */
>
> +#include <linux/array_size.h>
> +#include <linux/bitops.h>
> +#include <linux/dev_printk.h>
> +#include <linux/errno.h>
> #include <linux/i2c.h>
> #include <linux/interrupt.h>
> -#include <linux/kernel.h>
> #include <linux/module.h>
> - #include <linux/mod_devicetable.h>
> +#include <linux/mutex.h>
> +#include <linux/pm.h>
> +#include <linux/sysfs.h>
> #include <linux/types.h>
> +
> #include <linux/iio/buffer.h>
> #include <linux/iio/iio.h>
> #include <linux/iio/sysfs.h>
^ permalink raw reply
* [REGRESSION] next/master: (build) module random32_kunit uses symbol prandom_warmup from namespace EX...
From: KernelCI bot @ 2026-07-02 19:59 UTC (permalink / raw)
To: kernelci-results; +Cc: regressions, linux-next
New build issue found on next/master:
---
module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it. in Module.symvers (/tmp/kci/linux/scripts/Makefile.modpost:147) [logspec:kbuild,kbuild.modpost]
---
Log excerpt:
=====================================================
ERROR: modpost: module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it.
=====================================================
When fixing this issue, please attribute this report according to the
patch submission rules:
Reported-by: kernelci.org bot <bot@kernelci.org>
Link: https://lore.kernel.org/all/178302234435.4082.10623859604470804974@kernelci.org/
For complete logs and details about the environment used, see the issue
on the KernelCI dashboard:
- dashboard: https://d.kernelci.org/i/maestro:e1cd3f9474953bfa22c13e3e3b216ed721272880
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
- commit HEAD: 6eb8711ece2ce27e52e327a5b7a628ed39b97f45
- tags: next-20260702
# Builds where the incident occurred:
## ppc64le_defconfig on (powerpc):
- compiler: gcc-14
- config: None
- dashboard: https://d.kernelci.org/build/maestro:6a46b0edbb83f6a3e87f2264
#regzbot introduced: 7de6ae9e12207ec146f2f3f1e58d1a99317e88bc..6eb8711ece2ce27e52e327a5b7a628ed39b97f45
#regzbot link: https://d.kernelci.org/i/maestro:e1cd3f9474953bfa22c13e3e3b216ed721272880
#kernelci issue maestro:e1cd3f9474953bfa22c13e3e3b216ed721272880
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: Fixes tags need work in the ntfs tree
From: Namjae Jeon @ 2026-07-02 23:27 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel, linux-next
In-Reply-To: <akZvxeIEgr8bYu8o@sirena.org.uk>
On Thu, Jul 2, 2026 at 11:03 PM Mark Brown <broonie@kernel.org> wrote:
Hi Mark,
>
> In commit
>
> ec050fc4cf17d ("ntfs: validate error codes from untrusted disk data")
>
> Fixes tag
>
> Fixes: 1e9ea7e04472d ("Revert \"fs: Remove NTFS classic\"")
>
> has these problem(s):
I will fix it.
Thanks for sharing it with me.
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h ("%s")'
^ permalink raw reply
* [STATUS] next/master - 6eb8711ece2ce27e52e327a5b7a628ed39b97f45
From: KernelCI bot @ 2026-07-03 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: linux-next
Hello,
Status summary for next/master
Dashboard:
https://d.kernelci.org/c/next/master/6eb8711ece2ce27e52e327a5b7a628ed39b97f45/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 6eb8711ece2ce27e52e327a5b7a628ed39b97f45
origin: maestro
test start time: 2026-07-02 18:27:38.901000+00:00
Builds: 64 ✅ 4 ❌ 0 ⚠️
Boots: 164 ✅ 2 ❌ 0 ⚠️
Tests: 29798 ✅ 5386 ❌ 5155 ⚠️
### POSSIBLE REGRESSIONS
Hardware: imx8mp-verdin-nonwifi-dahlia
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.kvm_memslot_perf_test
last run: https://d.kernelci.org/test/maestro:6a470673bb83f6a3e882b29a
history: > ✅ > ✅ > ❌
Hardware: k3-am625-verdin-wifi-mallow
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.kvm_memslot_perf_test
last run: https://d.kernelci.org/test/maestro:6a470d59bb83f6a3e882d786
history: > ✅ > ✅ > ❌
Hardware: sun50i-a64-pine64-plus
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.kvm_memslot_perf_test
last run: https://d.kernelci.org/test/maestro:6a471a81bb83f6a3e883038e
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest-device-error-logs-ramdisk
last run: https://d.kernelci.org/test/maestro:6a46bd7cbb83f6a3e87fee76
history: > ❌ > ✅ > ✅
### UNSTABLE TESTS
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a46bd65bb83f6a3e87fedae
history: > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a46d736bb83f6a3e8814860
history: > ✅ > ⚠️ > ✅
### NEW BUILD ISSUES
- Issue: maestro:e1cd3f9474953bfa22c13e3e3b216ed721272880 | version: 1
Build: maestro:6a46b0e2bb83f6a3e87f21f5
Comment: module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it. in Module.symvers (/tmp/kci/linux/scripts/Makefile.modpost:147) [logspec:kbuild,kbuild.modpost]
First seen: 2026-07-02 19:00:37.889060+00:00
Culprit: code
- Issue: maestro:e1cd3f9474953bfa22c13e3e3b216ed721272880 | version: 1
Build: maestro:6a46b0edbb83f6a3e87f2264
Comment: module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it. in Module.symvers (/tmp/kci/linux/scripts/Makefile.modpost:147) [logspec:kbuild,kbuild.modpost]
First seen: 2026-07-02 19:00:37.889060+00:00
Culprit: code
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: linux-next: build failure in final build
From: Kir Chou @ 2026-07-03 5:04 UTC (permalink / raw)
To: Mark Brown
Cc: David Gow, Andrew Morton, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Linux Kernel Mailing List,
linux-next@vger.kernel.org
In-Reply-To: <akatWxAOMy_S1G2Y@sirena.org.uk>
Hi folks,
Sorry for causing this, I think my v4 patch missed MODULE_IMPORT_NS, I just added it to another v5 patch with a kernel local build.
Please let me know if I missed anything, thanks!
Regards,
Kir
> On Jul 3, 2026, at 3:26, Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> After merging the kthread tree, today's linux-next build
> (powerpc pseries_le_defconfig) failed like this:
>
> ERROR: modpost: module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it.
> make[3]: *** [/tmp/next/build/scripts/Makefile.modpost:147: Module.symvers] Error 1
> make[2]: *** [/tmp/next/build/Makefile:2134: modpost] Error 2
> make[1]: *** [/tmp/next/build/Makefile:248: __sub-make] Error 2
> make: *** [Makefile:248: __sub-make] Error 2
>
> Caused by commit
>
> 2ee1282ed36ff (lib/random32: convert selftest to KUnit)
>
> This appears to be showing up in this specific PowerPC configuration
> because ppc64_defconfig turns on
>
> CONFIG_KUNIT=m
> CONFIG_KUNIT_ALL_TESTS=m
>
> which is an unusual choice, normally defconfigs don't turn on KUnit and
> when KUnit is enabled it is built in.
>
> I have ignored this for today.
> <signature.asc>
^ permalink raw reply
* Re: [REGRESSION] next/master: (build) module random32_kunit uses symbol prandom_warmup from namespace EX...
From: Thorsten Leemhuis @ 2026-07-03 5:46 UTC (permalink / raw)
To: kernelci, kernelci-results; +Cc: regressions, linux-next
In-Reply-To: <178302234435.4082.10623859604470804974@kernelci.org>
On 7/2/26 21:59, KernelCI bot wrote:
> New build issue found on next/master:
>
> ---
> module random32_kunit uses symbol prandom_warmup from namespace EXPORTED_FOR_KUNIT_TESTING, but does not import it. in Module.symvers (/tmp/kci/linux/scripts/Makefile.modpost:147) [logspec:kbuild,kbuild.modpost]
akpm dropped the patch that causes this:
https://lore.kernel.org/all/20260702211236.705B71F000E9@smtp.kernel.org/
#regzbot resolve: culprit was dropped from -next
^ permalink raw reply
* GPU reset when running the ROCm hsa runtime tests on gfx12 and next-20260701
From: Bert Karwatzki @ 2026-07-03 12:44 UTC (permalink / raw)
To: Alex Deucher
Cc: Bert Karwatzki, linux-kernel, amd-gfx, linux-next, Jesse Zhang,
Amber Lin, Mario Limonciello
When running the ROCm hsa selftests on debian unstable (with ROCm packages from experimental)
with linux next-20260701, the GPU will reset with the following error message:
$ /usr/libexec/rocm/libhsa-runtime64-tests/run-tests
[ T2548] amdgpu 0000:03:00.0: failed to suspend gangs from MES
[ T2548] amdgpu 0000:03:00.0: MES might be in unrecoverable state, issue a GPU reset
[ T360] amdgpu 0000:03:00.0: GPU reset begin!. Source: 3
[T28252] amdgpu 0000:03:00.0: Failed to evict queue 0
[T28252] amdgpu: Failed to quiesce KFD
[ T360] amdgpu 0000:03:00.0: Dumping IP State
[ T360] amdgpu 0000:03:00.0: Dumping IP State Completed
[ T360] amdgpu 0000:03:00.0: MODE1 reset
[ T360] amdgpu 0000:03:00.0: GPU mode1 reset
[ T360] amdgpu 0000:03:00.0: GPU smu mode1 reset
[ T360] amdgpu 0000:03:00.0: GPU reset succeeded, trying to resume
[drm] PCIE GART of 512M enabled (table at 0x00000083DAB00000).
[drm] AMDGPU device coredump file has been created
[drm] Check your /sys/class/drm/card0/device/devcoredump/data
[ T360] amdgpu 0000:03:00.0: VRAM is lost due to GPU reset!
[ T360] amdgpu 0000:03:00.0: PSP is resuming...
[ T360] amdgpu 0000:03:00.0: RAS: optional ras ta ucode is not available
[ T360] amdgpu 0000:03:00.0: RAP: optional rap ta ucode is not available
[ T360] amdgpu 0000:03:00.0: SECUREDISPLAY: optional securedisplay ta ucode is not available
[ T360] amdgpu 0000:03:00.0: SMU is resuming...
[ T360] amdgpu 0000:03:00.0: SMU is resumed successfully!
[ T360] amdgpu 0000:03:00.0: program CP_MES_CNTL : 0x4000000
[ T360] amdgpu 0000:03:00.0: program CP_MES_CNTL : 0xc000000
[drm] DMUB hardware initialized: version=0x00010300
[ T360] amdgpu 0000:03:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[ T360] amdgpu 0000:03:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[ T360] amdgpu 0000:03:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[ T360] amdgpu 0000:03:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
[ T360] amdgpu 0000:03:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
[ T360] amdgpu 0000:03:00.0: ring sdma0 uses VM inv eng 9 on hub 0
[ T360] amdgpu 0000:03:00.0: ring sdma1 uses VM inv eng 10 on hub 0
[ T360] amdgpu 0000:03:00.0: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[ T360] amdgpu 0000:03:00.0: ring jpeg_dec uses VM inv eng 1 on hub 8
[ T360] amdgpu 0000:03:00.0: GPU reset(1) succeeded!
[drm] device wedged, but no recovery needed
[ T2050] amdgpu 0000:03:00.0: VM memory stats for proc xfwm4(2105) task xfwm4:cs0(2050) is non-zero when fini
[ T1932] amdgpu 0000:03:00.0: VM memory stats for proc (0) task (0) is non-zero when fini
[ T2293] amdgpu 0000:03:00.0: VM memory stats for proc (0) task (0) is non-zero when fini
[ T1929] amdgpu 0000:03:00.0: VM memory stats for proc (0) task (0) is non-zero when fini
[ T1930] amdgpu 0000:03:00.0: VM memory stats for proc (0) task (0) is non-zero when fini
[ T2263] amdgpu 0000:03:00.0: VM memory stats for proc firefox-esr(3483) task firefox-es:cs0(2263) is non-zero when fini
[ T3590] amdgpu 0000:03:00.0: VM memory stats for proc RDD Process(4755) task firefox-es:cs0(3590) is non-zero when fini
[ T1469] amdgpu 0000:03:00.0: VM memory stats for proc Xorg(1495) task Xorg:cs0(1469) is non-zero when fini
As this does not occur on v7.2-rc1 I bisected the issue and found
commit f94bbd648bb4 ("drm/amdgpu: use a single entry point for mes compute reset")
as responsible.
Unfortunately the does not revert cleanly in linux-next-20260701, so I had to revert these
commits to fix the issue in next-20260701:
b789664e3e30 ("drm/amdkfd: Clean up suspend_all and resume_all mes")
a665d09b10af ("drm/amdkfd: Pass known bad queue info to reset")
a4e4d945cba8 ("drm/amdgpu/gfx: defer per-queue helper_end until after MES resume")
f401a2633e02 ("drm/amdgpu: Remove faulty queue before resume")
f94bbd648bb4 ("drm/amdgpu: use a single entry point for mes compute reset")
GPU used:
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 44 [Radeon RX 9060 XT] [1002:7590] (rev c0)
CPU used:
model name : AMD Ryzen 9 9950X 16-Core Processor
Installed ROCm packages (from debian experimental)
bert@homer:~$ dpkg -l | grep 7.2.4
ii hip-utils 7.2.4-1~exp1 amd64 utilities for HIP language development
ii hipcc 7.2.4+dfsg-1~exp1 amd64 C++ Runtime API and Kernel Language for AMD and NVIDIA GPUs
ii libamd-comgr-dev 7.2.4+dfsg-1~exp1 amd64 ROCm code object manager - development package
ii libamd-comgr3:amd64 7.2.4+dfsg-1~exp1 amd64 ROCm code object manager
ii libamdhip64-7:amd64 7.2.4-1~exp1 amd64 HIP runtime for AMD GPUs - library
ii libamdhip64-dev 7.2.4-1~exp1 amd64 HIP runtime for AMD GPUs - headers
ii libhiprtc-builtins7:amd64 7.2.4-1~exp1 amd64 HIP runtime compilation library - builtins
ii libhiprtc7:amd64 7.2.4-1~exp1 amd64 HIP runtime compilation library
ii libhsa-runtime-dev:amd64 7.2.4+dfsg-1~exp1 amd64 HSA Runtime API and runtime for ROCm - development files
ii libhsa-runtime64-1:amd64 7.2.4+dfsg-1~exp1 amd64 HSA Runtime API and runtime for ROCm
ii libhsa-runtime64-tests 7.2.4+dfsg-1~exp1 amd64 HSA Runtime test suites for ROCm
ii librocblas-dev 7.2.4-1~exp1 amd64 ROCm library for basic linear algebra - headers
ii librocblas-doc 7.2.4-1~exp1 all ROCm library for basic linear algebra - documentation
ii librocblas5 7.2.4-1~exp1 amd64 ROCm library for basic linear algebra - library
ii librocblas5-bench 7.2.4-1~exp1 amd64 ROCm library for basic linear algebra - benchmarks
ii librocblas5-tests 7.2.4-1~exp1 amd64 ROCm library for basic linear algebra - tests
ii librocblas5-tests-data 7.2.4-1~exp1 all ROCm library for basic linear algebra - test data
ii librocm-core-dev 7.2.4-1~exp1 amd64 provides methods to get information about installed ROCm - headers
ii librocm-core1 7.2.4-1~exp1 amd64 provides methods to get information about installed ROCm
ii librocm-smi64-7 7.2.4-1~exp1 amd64 ROCm System Management Interface (ROCm SMI) library
ii librocsolver-dev 7.2.4-1~exp1 amd64 ROCm library for numerical linear algebra - headers
ii librocsolver0 7.2.4-1~exp1 amd64 ROCm library for numerical linear algebra - library
ii librocsolver0-tests 7.2.4-1~exp1 amd64 ROCm library for numerical linear algebra - tests
ii libroctx64-4 7.2.4-1~exp1 amd64 ROCm library for profiler annotations - library
ii rocm-device-libs-22 7.2.4+dfsg-1~exp1 amd64 AMD specific device-side language runtime libraries
ii rocm-opencl-icd:amd64 7.2.4-1~exp1 amd64 AMD ROCm implementation of the OpenCL API - ICD runtime
ii rocminfo 7.2.4-1~exp1 amd64 ROCm Application for Reporting System Info
Bert Karwatzki
^ permalink raw reply
* Re: linux-next: manual merge of the mm-nonmm-unstable tree with the tip-fixes tree
From: Masami Hiramatsu @ 2026-07-03 14:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Brown, Bradley Morgan, Breno Leitao,
Linux Kernel Mailing List, Linux Next Mailing List,
Masami Hiramatsu
In-Reply-To: <20260702102850.12ce82e1e2e95766d52e0093@linux-foundation.org>
On Thu, 2 Jul 2026 10:28:50 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 2 Jul 2026 15:04:29 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> > Hi all,
> >
> > Today's linux-next merge of the mm-nonmm-unstable tree got a conflict in:
> >
> > lib/bootconfig.c
> >
> > between commit:
> >
> > dec4d8118c179 ("bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()")
> >
> > from the tip-fixes tree and commit:
> >
> > 9f2274451ae6b ("lib/bootconfig: fix undefined behavior involving NULL pointer arithmetic")
> >
> > from the mm-nonmm-unstable tree which look like two fixes for the same
> > issue.
>
> hm, OK, thanks. I don't know which is preferable, really. I'll drop
> the mm.git patch because the tip-fixes patch has a nice comment ;)
>
Ah, yes. I replied to it. Thanks for dropping.
https://lore.kernel.org/all/20260701082611.6575e0f37541014f67830bdc@kernel.org/
Thank you,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* linux-next: KUnit failure after merge of the mm-nonmm-unstable tree
From: Mark Brown @ 2026-07-03 14:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
Hi all,
After merging the mm-nonmm-unstable tree, today's linux-next failed
KUnit testing like this:
[14:20:52] Configuring KUnit Kernel ...
[14:20:52] Building KUnit Kernel ...
Populating config with:
$ make ARCH=arm64 O=/tmp/next/arm64_kunit olddefconfig CROSS_COMPILE=aarch64-linux-gnu-
Building with:
$ make all compile_commands.json scripts_gdb ARCH=arm64 O=/tmp/next/arm64_kunit --jobs=192 CROSS_COMPILE=aarch64-linux-gnu-
[14:21:06] Starting KUnit Kernel (1/1)...
Running tests with:
$ qemu-system-aarch64 -nodefaults -m 1024 -kernel /tmp/next/arm64_kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -machine virt -cpu max
[14:22:11] ============================================================
[14:22:11] =================== cmdline (8 subtests) ===================
[14:22:11] # cmdline_test_memparse: EXPECTATION FAILED at lib/tests/cmdline_kunit.c:249
[14:22:11] Expected ret == e->result, but
[14:22:11] ret == -16 (0xfffffffffffffff0)
[14:22:11] e->result == -1 (0xffffffffffffffff)
[14:22:11] when parsing '0xffffffffffffffff0'
[14:22:11] [FAILED] cmdline_test_memparse
[14:22:11] # module: cmdline_kunit
[14:22:11] # cmdline: pass:7 fail:1 skip:0 total:8
[14:22:11] # Totals: pass:7 fail:1 skip:0 total:8
[14:22:11] ===================== [FAILED] cmdline =====================
[14:22:11] ============================================================
[14:22:11] Testing complete. Ran 9225 tests: passed: 9104, failed: 1, skipped: 120
[14:22:11] Failures: cmdline.cmdline_test_memparse
[14:22:11] Test results stored in /tmp/next/arm64_kunit.json
[14:22:11] Elapsed time: 79.318s total, 0.002s configuring, 14.632s building, 64.682s running
I honestly have no idea what's triggering this, nothing jumps out from
the commits introduced in the merge of the branch. If I have time later
I'll try to bisect the issue. I have used the tree from next-20260602
instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: duplicate patch in the drm-xe tree
From: Mark Brown @ 2026-07-03 15:08 UTC (permalink / raw)
To: Thomas Hellström, DRM XE List, Matt Roper, Gustavo Sousa,
Violet Monti
Cc: Linux Kernel Mailing List, Linux Next Mailing List
Hi all,
The following commit is also in Linus Torvalds' tree as a different commit
(but the same patch):
5ff004fdc7377 (drm/xe/rtp: Add struct types for RTP tables)
^ permalink raw reply
* linux-next: manual merge of the drm-xe tree with the drm-fixes tree
From: Mark Brown @ 2026-07-03 15:41 UTC (permalink / raw)
To: Thomas Hellström, DRM XE List
Cc: Gustavo Sousa, Linux Kernel Mailing List, Linux Next Mailing List,
Matt Roper, Violet Monti
[-- Attachment #1: Type: text/plain, Size: 10917 bytes --]
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_hw_engine.c
between commit:
e23fafb8594ea ("drm/xe/rtp: Add struct types for RTP tables")
from the drm-fixes tree and commits:
5ff004fdc7377 ("drm/xe/rtp: Add struct types for RTP tables")
431a233c1710c ("drm/xe: Move engines' LRC programming RTP table off the stack")
4ff7902a64c18 ("drm/xe: Move engines' non-LRC programming RTP table off the stack")
from the drm-xe tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined drivers/gpu/drm/xe/xe_hw_engine.c
index 0b193c451a11d,87d60c4117bd8..0000000000000
--- a/drivers/gpu/drm/xe/xe_hw_engine.c
+++ b/drivers/gpu/drm/xe/xe_hw_engine.c
@@@ -337,39 -337,41 +337,41 @@@ static bool xe_rtp_cfeg_wmtp_disabled(c
return xe_mmio_read32(&hwe->gt->mmio, XEHP_FUSE4) & CFEG_WMTP_DISABLE;
}
+ static u32 blit_cctl_val(struct xe_gt *gt, struct xe_hw_engine *hwe)
+ {
+ return REG_FIELD_PREP(BLIT_CCTL_DST_MOCS_MASK, gt->mocs.uc_index) |
+ REG_FIELD_PREP(BLIT_CCTL_SRC_MOCS_MASK, gt->mocs.uc_index);
+ }
+
+ static const struct xe_rtp_table_sr lrc_setup = XE_RTP_TABLE_SR(
+ /*
+ * Some blitter commands do not have a field for MOCS, those
+ * commands will use MOCS index pointed by BLIT_CCTL.
+ * BLIT_CCTL registers are needed to be programmed to un-cached.
+ */
+ { XE_RTP_NAME("BLIT_CCTL_default_MOCS"),
+ XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1200, 1274),
+ ENGINE_CLASS(COPY)),
+ XE_RTP_ACTIONS(FIELD_SET_FUNC(BLIT_CCTL(0),
+ BLIT_CCTL_DST_MOCS_MASK |
+ BLIT_CCTL_SRC_MOCS_MASK,
+ blit_cctl_val,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ /* Disable WMTP if HW doesn't support it */
+ { XE_RTP_NAME("DISABLE_WMTP_ON_UNSUPPORTED_HW"),
+ XE_RTP_RULES(FUNC(xe_rtp_cfeg_wmtp_disabled)),
+ XE_RTP_ACTIONS(FIELD_SET(CS_CHICKEN1(0),
+ PREEMPT_GPGPU_LEVEL_MASK,
+ PREEMPT_GPGPU_THREAD_GROUP_LEVEL)),
+ XE_RTP_ENTRY_FLAG(FOREACH_ENGINE)
+ },
+ );
+
static void
hw_engine_setup_default_lrc_state(struct xe_hw_engine *hwe)
{
- struct xe_gt *gt = hwe->gt;
- const u8 mocs_write_idx = gt->mocs.uc_index;
- const u8 mocs_read_idx = gt->mocs.uc_index;
- u32 blit_cctl_val = REG_FIELD_PREP(BLIT_CCTL_DST_MOCS_MASK, mocs_write_idx) |
- REG_FIELD_PREP(BLIT_CCTL_SRC_MOCS_MASK, mocs_read_idx);
struct xe_rtp_process_ctx ctx = XE_RTP_PROCESS_CTX_INITIALIZER(hwe);
- const struct xe_rtp_table_sr lrc_setup = XE_RTP_TABLE_SR(
- /*
- * Some blitter commands do not have a field for MOCS, those
- * commands will use MOCS index pointed by BLIT_CCTL.
- * BLIT_CCTL registers are needed to be programmed to un-cached.
- */
- { XE_RTP_NAME("BLIT_CCTL_default_MOCS"),
- XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1200, 1274),
- ENGINE_CLASS(COPY)),
- XE_RTP_ACTIONS(FIELD_SET(BLIT_CCTL(0),
- BLIT_CCTL_DST_MOCS_MASK |
- BLIT_CCTL_SRC_MOCS_MASK,
- blit_cctl_val,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- /* Disable WMTP if HW doesn't support it */
- { XE_RTP_NAME("DISABLE_WMTP_ON_UNSUPPORTED_HW"),
- XE_RTP_RULES(FUNC(xe_rtp_cfeg_wmtp_disabled)),
- XE_RTP_ACTIONS(FIELD_SET(CS_CHICKEN1(0),
- PREEMPT_GPGPU_LEVEL_MASK,
- PREEMPT_GPGPU_THREAD_GROUP_LEVEL)),
- XE_RTP_ENTRY_FLAG(FOREACH_ENGINE)
- },
- );
xe_rtp_process_to_sr(&ctx, &lrc_setup, &hwe->reg_lrc, true);
}
@@@ -385,86 -387,92 +387,92 @@@ void xe_hw_engine_setup_reg_lrc(struct
xe_tuning_process_lrc(hwe);
}
+ /*
+ * RING_CMD_CCTL specifies the default MOCS entry that will be
+ * used by the command streamer when executing commands that
+ * don't have a way to explicitly specify a MOCS setting.
+ * The default should usually reference whichever MOCS entry
+ * corresponds to uncached behavior, although use of a WB cached
+ * entry is recommended by the spec in certain circumstances on
+ * specific platforms.
+ * Bspec: 72161
+ */
+ static u32 ring_cmd_cctl_val(struct xe_gt *gt, struct xe_hw_engine *hwe)
+ {
+ struct xe_device *xe = gt_to_xe(gt);
+ u8 mocs_read_idx = gt->mocs.uc_index;
+
+ if (hwe->class == XE_ENGINE_CLASS_COMPUTE && IS_DGFX(xe) &&
+ (GRAPHICS_VER(xe) >= 20 || xe->info.platform == XE_PVC))
+ mocs_read_idx = gt->mocs.wb_index;
+
+ return REG_FIELD_PREP(CMD_CCTL_WRITE_OVERRIDE_MASK, gt->mocs.uc_index) |
+ REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, mocs_read_idx);
+ }
+
+ static const struct xe_rtp_table_sr engine_sr = XE_RTP_TABLE_SR(
+ { XE_RTP_NAME("RING_CMD_CCTL_default_MOCS"),
+ XE_RTP_RULES(FUNC(xe_rtp_match_always)),
+ XE_RTP_ACTIONS(FIELD_SET_FUNC(RING_CMD_CCTL(0),
+ CMD_CCTL_WRITE_OVERRIDE_MASK |
+ CMD_CCTL_READ_OVERRIDE_MASK,
+ ring_cmd_cctl_val,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ { XE_RTP_NAME("Disable HW status page updates for interrupts"),
+ XE_RTP_RULES(FUNC(xe_rtp_match_always)),
+ XE_RTP_ACTIONS(SET(RING_HWSTAM(0), ~0x0,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ { XE_RTP_NAME("Disable engine 'legacy' mode"),
+ XE_RTP_RULES(FUNC(xe_rtp_match_always)),
+ XE_RTP_ACTIONS(SET(GFX_MODE(0), GFX_DISABLE_LEGACY_MODE,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ /*
+ * To allow the GSC engine to go idle on MTL we need to enable
+ * idle messaging and set the hysteresis value (we use 0xA=5us
+ * as recommended in spec). On platforms after MTL this is
+ * enabled by default.
+ */
+ { XE_RTP_NAME("MTL GSCCS IDLE MSG enable"),
+ XE_RTP_RULES(MEDIA_VERSION(1300), ENGINE_CLASS(OTHER)),
+ XE_RTP_ACTIONS(CLR(RING_PSMI_CTL(0),
+ IDLE_MSG_DISABLE,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)),
+ FIELD_SET(RING_PWRCTX_MAXCNT(0),
+ IDLE_WAIT_TIME,
+ 0xA,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ /* Enable Priority Mem Read */
+ { XE_RTP_NAME("Priority_Mem_Read"),
+ XE_RTP_RULES(GRAPHICS_VERSION_RANGE(2001, XE_RTP_END_VERSION_UNDEFINED)),
+ XE_RTP_ACTIONS(SET(CSFE_CHICKEN1(0), CS_PRIORITY_MEM_READ,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ { XE_RTP_NAME("Enable CCS Engine(s)"),
+ XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1255, XE_RTP_END_VERSION_UNDEFINED),
+ FUNC(xe_rtp_match_first_render_or_compute)),
+ XE_RTP_ACTIONS(SET(RCU_MODE, RCU_MODE_CCS_ENABLE))
+ },
+ /* Use Fixed slice CCS mode */
+ { XE_RTP_NAME("RCU_MODE_FIXED_SLICE_CCS_MODE"),
+ XE_RTP_RULES(FUNC(xe_hw_engine_match_fixed_cslice_mode)),
+ XE_RTP_ACTIONS(FIELD_SET(RCU_MODE, RCU_MODE_FIXED_SLICE_CCS_MODE,
+ RCU_MODE_FIXED_SLICE_CCS_MODE))
+ },
+ { XE_RTP_NAME("Enable MSI-X interrupt support"),
+ XE_RTP_RULES(FUNC(xe_rtp_match_has_msix)),
+ XE_RTP_ACTIONS(SET(GFX_MODE(0), GFX_MSIX_INTERRUPT_ENABLE,
+ XE_RTP_ACTION_FLAG(ENGINE_BASE)))
+ },
+ );
+
static void
hw_engine_setup_default_state(struct xe_hw_engine *hwe)
{
- struct xe_gt *gt = hwe->gt;
- struct xe_device *xe = gt_to_xe(gt);
- /*
- * RING_CMD_CCTL specifies the default MOCS entry that will be
- * used by the command streamer when executing commands that
- * don't have a way to explicitly specify a MOCS setting.
- * The default should usually reference whichever MOCS entry
- * corresponds to uncached behavior, although use of a WB cached
- * entry is recommended by the spec in certain circumstances on
- * specific platforms.
- * Bspec: 72161
- */
- const u8 mocs_write_idx = gt->mocs.uc_index;
- const u8 mocs_read_idx = hwe->class == XE_ENGINE_CLASS_COMPUTE && IS_DGFX(xe) &&
- (GRAPHICS_VER(xe) >= 20 || xe->info.platform == XE_PVC) ?
- gt->mocs.wb_index : gt->mocs.uc_index;
- u32 ring_cmd_cctl_val = REG_FIELD_PREP(CMD_CCTL_WRITE_OVERRIDE_MASK, mocs_write_idx) |
- REG_FIELD_PREP(CMD_CCTL_READ_OVERRIDE_MASK, mocs_read_idx);
struct xe_rtp_process_ctx ctx = XE_RTP_PROCESS_CTX_INITIALIZER(hwe);
- const struct xe_rtp_table_sr engine_sr = XE_RTP_TABLE_SR(
- { XE_RTP_NAME("RING_CMD_CCTL_default_MOCS"),
- XE_RTP_RULES(FUNC(xe_rtp_match_always)),
- XE_RTP_ACTIONS(FIELD_SET(RING_CMD_CCTL(0),
- CMD_CCTL_WRITE_OVERRIDE_MASK |
- CMD_CCTL_READ_OVERRIDE_MASK,
- ring_cmd_cctl_val,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- { XE_RTP_NAME("Disable HW status page updates for interrupts"),
- XE_RTP_RULES(FUNC(xe_rtp_match_always)),
- XE_RTP_ACTIONS(SET(RING_HWSTAM(0), ~0x0,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- { XE_RTP_NAME("Disable engine 'legacy' mode"),
- XE_RTP_RULES(FUNC(xe_rtp_match_always)),
- XE_RTP_ACTIONS(SET(GFX_MODE(0), GFX_DISABLE_LEGACY_MODE,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- /*
- * To allow the GSC engine to go idle on MTL we need to enable
- * idle messaging and set the hysteresis value (we use 0xA=5us
- * as recommended in spec). On platforms after MTL this is
- * enabled by default.
- */
- { XE_RTP_NAME("MTL GSCCS IDLE MSG enable"),
- XE_RTP_RULES(MEDIA_VERSION(1300), ENGINE_CLASS(OTHER)),
- XE_RTP_ACTIONS(CLR(RING_PSMI_CTL(0),
- IDLE_MSG_DISABLE,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)),
- FIELD_SET(RING_PWRCTX_MAXCNT(0),
- IDLE_WAIT_TIME,
- 0xA,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- /* Enable Priority Mem Read */
- { XE_RTP_NAME("Priority_Mem_Read"),
- XE_RTP_RULES(GRAPHICS_VERSION_RANGE(2001, XE_RTP_END_VERSION_UNDEFINED)),
- XE_RTP_ACTIONS(SET(CSFE_CHICKEN1(0), CS_PRIORITY_MEM_READ,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- { XE_RTP_NAME("Enable CCS Engine(s)"),
- XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1255, XE_RTP_END_VERSION_UNDEFINED),
- FUNC(xe_rtp_match_first_render_or_compute)),
- XE_RTP_ACTIONS(SET(RCU_MODE, RCU_MODE_CCS_ENABLE))
- },
- /* Use Fixed slice CCS mode */
- { XE_RTP_NAME("RCU_MODE_FIXED_SLICE_CCS_MODE"),
- XE_RTP_RULES(FUNC(xe_hw_engine_match_fixed_cslice_mode)),
- XE_RTP_ACTIONS(FIELD_SET(RCU_MODE, RCU_MODE_FIXED_SLICE_CCS_MODE,
- RCU_MODE_FIXED_SLICE_CCS_MODE))
- },
- { XE_RTP_NAME("Enable MSI-X interrupt support"),
- XE_RTP_RULES(FUNC(xe_rtp_match_has_msix)),
- XE_RTP_ACTIONS(SET(GFX_MODE(0), GFX_MSIX_INTERRUPT_ENABLE,
- XE_RTP_ACTION_FLAG(ENGINE_BASE)))
- },
- );
xe_rtp_process_to_sr(&ctx, &engine_sr, &hwe->reg_sr, false);
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the drm-xe tree with the drm-fixes tree
From: Mark Brown @ 2026-07-03 15:41 UTC (permalink / raw)
To: Thomas Hellström, DRM XE List
Cc: Gustavo Sousa, Linux Kernel Mailing List, Linux Next Mailing List,
Matt Roper, Violet Monti
[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/tests/xe_rtp_test.c
between commit:
e23fafb8594ea ("drm/xe/rtp: Add struct types for RTP tables")
from the drm-fixes tree and commits:
5ff004fdc7377 ("drm/xe/rtp: Add struct types for RTP tables")
c47ffed42b016 ("drm/xe/rtp: Add kunit tests to exercise FIELD_SET_FUNC action")
from the drm-xe tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined drivers/gpu/drm/xe/tests/xe_rtp_test.c
index 3d0688d058d97,367811621880f..0000000000000
--- a/drivers/gpu/drm/xe/tests/xe_rtp_test.c
+++ b/drivers/gpu/drm/xe/tests/xe_rtp_test.c
@@@ -280,6 -280,11 +280,11 @@@ static void xe_rtp_rules_tests(struct k
KUNIT_EXPECT_EQ(test, err, param->expected_err);
}
+ static u32 bits_2_3_set(struct xe_gt *gt, struct xe_hw_engine *hwe)
+ {
+ return REG_BIT(2) | REG_BIT(3);
+ }
+
static const struct rtp_to_sr_test_case rtp_to_sr_cases[] = {
{
.name = "coalesce-same-reg",
@@@ -300,6 -305,29 +305,29 @@@
},
),
},
+ {
+ .name = "coalesce-same-reg-literal-and-func",
+ .expected_reg = REGULAR_REG1,
+ .expected_set_bits = REG_BIT(0) | REG_BIT(1) | REG_BIT(2) | REG_BIT(3),
+ .expected_clr_bits = REG_BIT(0) | REG_BIT(1) | REG_BIT(2) | REG_BIT(3),
+ .expected_active = BIT(0) | BIT(1),
+ .expected_count_sr_entries = 1,
+ /* Different bits on the same register: create a single entry */
+ .table = XE_RTP_TABLE_SR(
+ { XE_RTP_NAME("basic-1"),
+ XE_RTP_RULES(FUNC(match_yes)),
+ XE_RTP_ACTIONS(FIELD_SET(REGULAR_REG1,
+ REG_BIT(0) | REG_BIT(1),
+ REG_BIT(0) | REG_BIT(1)))
+ },
+ { XE_RTP_NAME("basic-2"),
+ XE_RTP_RULES(FUNC(match_yes)),
+ XE_RTP_ACTIONS(FIELD_SET_FUNC(REGULAR_REG1,
+ REG_BIT(2) | REG_BIT(3),
+ bits_2_3_set))
+ },
+ ),
+ },
{
.name = "no-match-no-add",
.expected_reg = REGULAR_REG1,
@@@ -417,6 -445,30 +445,30 @@@
},
),
},
+ {
+ .name = "conflict-not-disjoint-literal-and-func",
+ .expected_reg = REGULAR_REG1,
+ .expected_set_bits = REG_BIT(1) | REG_BIT(2),
+ .expected_clr_bits = REG_BIT(1) | REG_BIT(2),
+ .expected_active = BIT(0) | BIT(1),
+ .expected_count_sr_entries = 1,
+ .expected_sr_errors = 1,
+ .table = XE_RTP_TABLE_SR(
+ { XE_RTP_NAME("basic-1"),
+ XE_RTP_RULES(FUNC(match_yes)),
+ XE_RTP_ACTIONS(FIELD_SET(REGULAR_REG1,
+ REG_BIT(1) | REG_BIT(2),
+ REG_BIT(1) | REG_BIT(2)))
+ },
+ /* drop: bits are not disjoint with previous entries */
+ { XE_RTP_NAME("basic-2"),
+ XE_RTP_RULES(FUNC(match_yes)),
+ XE_RTP_ACTIONS(FIELD_SET_FUNC(REGULAR_REG1,
+ REG_BIT(2) | REG_BIT(3),
+ bits_2_3_set))
+ },
+ ),
+ },
{
.name = "conflict-reg-type",
.expected_reg = REGULAR_REG1,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the drm-xe tree with the drm-fixes tree
From: Mark Brown @ 2026-07-03 15:44 UTC (permalink / raw)
To: Thomas Hellström, DRM XE List
Cc: Ashutosh Dixit, Gustavo Sousa, Linux Kernel Mailing List,
Linux Next Mailing List, Matt Roper, Violet Monti
[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_reg_whitelist.c
between commit:
959b5016e4646 ("drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG")
from the drm-fixes tree and commits:
5ff004fdc7377 ("drm/xe/rtp: Add struct types for RTP tables")
90511bdcfda97 ("drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists")
c478244a9e2d1 ("drm/xe/rtp: Maintain OA whitelists separately")
15739920b71ef ("drm/xe/rtp: Keep track of non-OA nonpriv slots")
c3ff77d7235cc ("drm/xe/rtp: Generalize whitelist_apply_to_hwe")
3a3c3e56db292 ("drm/xe/rtp: Save OA nonpriv registers to register save/restore lists")
aeaa7d2bb0172 ("drm/xe/rtp: Toggle 'deny' bit to (de-)whitelist OA regs")
6f73bf8fffa72 ("drm/xe/rtp: (De-)whitelist OA registers for all hwe's for a gt")
645f1a2589bd4 ("drm/xe/rtp: Ensure locking/ref counting for OA whitelists")
483c9f5451592 ("drm/xe/tests/rtp: Add kunit test for whitelist upper bounds")
f6c23e4589bdc ("drm/xe/oa: Fix offset alignment for MERT WHITELIST_OA_MERT_MMIO_TRG")
from the drm-xe tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined drivers/gpu/drm/xe/xe_reg_whitelist.c
index 526907d2d8246,cab1b578ca0ef..0000000000000
--- a/drivers/gpu/drm/xe/xe_reg_whitelist.c
+++ b/drivers/gpu/drm/xe/xe_reg_whitelist.c
@@@ -5,6 -5,8 +5,8 @@@
#include "xe_reg_whitelist.h"
+ #include <kunit/visibility.h>
+
#include "regs/xe_engine_regs.h"
#include "regs/xe_gt_regs.h"
#include "regs/xe_oa_regs.h"
@@@ -41,7 -43,7 +43,7 @@@ static bool match_multi_queue_class(con
return xe_gt_supports_multi_queue(gt, hwe->class);
}
- static const struct xe_rtp_table_sr register_whitelist = XE_RTP_TABLE_SR(
+ VISIBLE_IF_KUNIT const struct xe_rtp_table_sr register_whitelist = XE_RTP_TABLE_SR(
{ XE_RTP_NAME("WaAllowPMDepthAndInvocationCountAccessFromUMD, 1408556865"),
XE_RTP_RULES(GRAPHICS_VERSION_RANGE(1200, 1210), ENGINE_CLASS(RENDER)),
XE_RTP_ACTIONS(WHITELIST(PS_INVOCATION_COUNT,
@@@ -104,6 -106,7 +106,7 @@@
RING_FORCE_TO_NONPRIV_ACCESS_RW))
},
);
+ EXPORT_SYMBOL_IF_KUNIT(register_whitelist);
static const struct xe_rtp_table_sr oa_whitelist = XE_RTP_TABLE_SR(
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the drm-xe tree with the drm-fixes tree
From: Mark Brown @ 2026-07-03 15:44 UTC (permalink / raw)
To: Thomas Hellström, DRM XE List
Cc: Gustavo Sousa, Linux Kernel Mailing List, Linux Next Mailing List,
Matt Roper, Violet Monti
[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_tuning.c
between commit:
e23fafb8594ea ("drm/xe/rtp: Add struct types for RTP tables")
from the drm-fixes tree and commits:
5ff004fdc7377 ("drm/xe/rtp: Add struct types for RTP tables")
e9845449e37f5 ("drm/xe/rtp: Ensure gt_was doesn't evaluate rules with engine types")
from the drm-xe tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined drivers/gpu/drm/xe/xe_tuning.c
index bf3fad9cdbef4,bcec40ca2d35f..0000000000000
--- a/drivers/gpu/drm/xe/xe_tuning.c
+++ b/drivers/gpu/drm/xe/xe_tuning.c
@@@ -20,7 -20,7 +20,7 @@@
#undef XE_REG_MCR
#define XE_REG_MCR(...) XE_REG(__VA_ARGS__, .mcr = 1)
- static const struct xe_rtp_table_sr gt_tunings = XE_RTP_TABLE_SR(
+ VISIBLE_IF_KUNIT const struct xe_rtp_table_sr gt_tunings = XE_RTP_TABLE_SR(
{ XE_RTP_NAME("Tuning: Blend Fill Caching Optimization Disable"),
XE_RTP_RULES(PLATFORM(DG2)),
XE_RTP_ACTIONS(SET(XEHP_L3SCQREG7, BLEND_FILL_CACHING_OPT_DIS))
@@@ -101,6 -101,7 +101,7 @@@
BANK_HASH_4KB_MODE))
},
);
+ EXPORT_SYMBOL_IF_KUNIT(gt_tunings);
static const struct xe_rtp_table_sr engine_tunings = XE_RTP_TABLE_SR(
{ XE_RTP_NAME("Tuning: L3 Hashing Mask"),
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the drm-xe tree with the drm-fixes tree
From: Mark Brown @ 2026-07-03 16:20 UTC (permalink / raw)
To: Thomas Hellström, DRM XE List
Cc: Gustavo Sousa, Linux Kernel Mailing List, Linux Next Mailing List,
Matt Roper, Violet Monti
[-- Attachment #1: Type: text/plain, Size: 3821 bytes --]
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_wa.c
between commit:
e23fafb8594ea ("drm/xe/rtp: Add struct types for RTP tables")
from the drm-fixes tree and commits:
5ff004fdc7377 ("drm/xe/rtp: Add struct types for RTP tables")
e9845449e37f5 ("drm/xe/rtp: Ensure gt_was doesn't evaluate rules with engine types")
e2cfc5bc0c3ff ("drm/xe/rtp: Ensure oob_was does not evaluate engine type rules")
94e15e89f491e ("drm/xe/rtp: Ensure device_oob_was only evaluates correct rules")
02b41333f4874 ("drm/xe/xe3p_lpg: Add missing references to workarounds")
from the drm-xe tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined drivers/gpu/drm/xe/xe_wa.c
index b9d9fe0801aad,139434946f8f8..0000000000000
--- a/drivers/gpu/drm/xe/xe_wa.c
+++ b/drivers/gpu/drm/xe/xe_wa.c
@@@ -130,7 -130,7 +130,7 @@@
__diag_push();
__diag_ignore_all("-Woverride-init", "Allow field overrides in table");
- static const struct xe_rtp_table_sr gt_was = XE_RTP_TABLE_SR(
+ VISIBLE_IF_KUNIT const struct xe_rtp_table_sr gt_was = XE_RTP_TABLE_SR(
/* Workarounds applying over a range of IPs */
{ XE_RTP_NAME("14011060649"),
@@@ -293,7 -293,7 +293,7 @@@
XE_RTP_ACTIONS(SET(MMIOATSREQLIMIT_GAM_WALK_3D,
DIS_ATS_WRONLY_PG))
},
- { XE_RTP_NAME("14026144927, 16029437861"),
+ { XE_RTP_NAME("14026144927, 16029437861, 14026127056"),
XE_RTP_RULES(GRAPHICS_VERSION(3510), GRAPHICS_STEP(A0, B0)),
XE_RTP_ACTIONS(SET(L3SQCREG2, L3_SQ_DISABLE_COAMA_2WAY_COH |
L3_SQ_DISABLE_COAMA))
@@@ -307,6 -307,7 +307,7 @@@
XE_RTP_ACTIONS(SET(GUC_INTR_CHICKEN, DISABLE_SIGNALING_ENGINES))
},
);
+ EXPORT_SYMBOL_IF_KUNIT(gt_was);
static const struct xe_rtp_table_sr engine_was = XE_RTP_TABLE_SR(
/* Workarounds applying over a range of IPs */
@@@ -586,12 -587,12 +587,12 @@@
/* Xe3p_LPG*/
- { XE_RTP_NAME("22021149932"),
+ { XE_RTP_NAME("22021149932, 14026290593"),
XE_RTP_RULES(GRAPHICS_VERSION(3510), GRAPHICS_STEP(A0, B0),
FUNC(xe_rtp_match_first_render_or_compute)),
XE_RTP_ACTIONS(SET(LSC_CHICKEN_BIT_0_UDW, SAMPLER_LD_LSC_DISABLE))
},
- { XE_RTP_NAME("14025676848"),
+ { XE_RTP_NAME("14025676848, 14026270459"),
XE_RTP_RULES(GRAPHICS_VERSION(3510), GRAPHICS_STEP(A0, B0),
FUNC(xe_rtp_match_first_render_or_compute)),
XE_RTP_ACTIONS(SET(LSC_CHICKEN_BIT_0_UDW, LSCFE_SAME_ADDRESS_ATOMICS_COALESCING_DISABLE))
@@@ -802,10 -803,11 +803,11 @@@ static const struct xe_rtp_entry oob_wa
static_assert(ARRAY_SIZE(oob_was_entries) == _XE_WA_OOB_COUNT);
- static __maybe_unused const struct xe_rtp_table oob_was = {
+ VISIBLE_IF_KUNIT __maybe_unused const struct xe_rtp_table oob_was = {
.entries = oob_was_entries,
.n_entries = ARRAY_SIZE(oob_was_entries),
};
+ EXPORT_SYMBOL_IF_KUNIT(oob_was);
static const struct xe_rtp_entry device_oob_was_entries[] = {
#include <generated/xe_device_wa_oob.c>
@@@ -813,10 -815,11 +815,11 @@@
static_assert(ARRAY_SIZE(device_oob_was_entries) == _XE_DEVICE_WA_OOB_COUNT);
- static __maybe_unused const struct xe_rtp_table device_oob_was = {
+ VISIBLE_IF_KUNIT __maybe_unused const struct xe_rtp_table device_oob_was = {
.entries = device_oob_was_entries,
.n_entries = ARRAY_SIZE(device_oob_was_entries),
};
+ EXPORT_SYMBOL_IF_KUNIT(device_oob_was);
__diag_pop();
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 3
From: Mark Brown @ 2026-07-03 16:20 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]
Hi all,
Changes since 20260702:
The mm-nonmm-unstable tree acquired a KUnit failure, I used the version
from next-20260602 instead.
The drm-intel tree acquired multiple conflicts with the drm-fixes tree.
Non-merge commits (relative to Linus' tree): 3187
3175 files changed, 116065 insertions(+), 62025 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 427 trees (counting Linus' and 132 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: KUnit failure after merge of the mm-nonmm-unstable tree
From: Mark Brown @ 2026-07-03 16:39 UTC (permalink / raw)
To: Andrew Morton, Alexey Dobriyan
Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <akfKl6lJlGL6fPG3@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3507 bytes --]
On Fri, Jul 03, 2026 at 03:43:35PM +0100, Mark Brown wrote:
> Hi all,
>
> After merging the mm-nonmm-unstable tree, today's linux-next failed
> KUnit testing like this:
>
> [14:20:52] Configuring KUnit Kernel ...
> [14:20:52] Building KUnit Kernel ...
> Populating config with:
> $ make ARCH=arm64 O=/tmp/next/arm64_kunit olddefconfig CROSS_COMPILE=aarch64-linux-gnu-
> Building with:
> $ make all compile_commands.json scripts_gdb ARCH=arm64 O=/tmp/next/arm64_kunit --jobs=192 CROSS_COMPILE=aarch64-linux-gnu-
> [14:21:06] Starting KUnit Kernel (1/1)...
> Running tests with:
> $ qemu-system-aarch64 -nodefaults -m 1024 -kernel /tmp/next/arm64_kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -machine virt -cpu max
> [14:22:11] ============================================================
> [14:22:11] =================== cmdline (8 subtests) ===================
> [14:22:11] # cmdline_test_memparse: EXPECTATION FAILED at lib/tests/cmdline_kunit.c:249
> [14:22:11] Expected ret == e->result, but
> [14:22:11] ret == -16 (0xfffffffffffffff0)
> [14:22:11] e->result == -1 (0xffffffffffffffff)
> [14:22:11] when parsing '0xffffffffffffffff0'
> [14:22:11] [FAILED] cmdline_test_memparse
> [14:22:11] # module: cmdline_kunit
> [14:22:11] # cmdline: pass:7 fail:1 skip:0 total:8
> [14:22:11] # Totals: pass:7 fail:1 skip:0 total:8
> [14:22:11] ===================== [FAILED] cmdline =====================
> [14:22:11] ============================================================
> [14:22:11] Testing complete. Ran 9225 tests: passed: 9104, failed: 1, skipped: 120
> [14:22:11] Failures: cmdline.cmdline_test_memparse
> [14:22:11] Test results stored in /tmp/next/arm64_kunit.json
> [14:22:11] Elapsed time: 79.318s total, 0.002s configuring, 14.632s building, 64.682s running
>
> I honestly have no idea what's triggering this, nothing jumps out from
> the commits introduced in the merge of the branch. If I have time later
> I'll try to bisect the issue. I have used the tree from next-20260602
> instead.
bisect tells me it's due to:
e595545005616 (Revert "lib: fix _parse_integer_limit() to handle overflow")
log:
git bisect start
# status: waiting for both good and bad commits
# bad: [604ad02caddab12905643d5191b4a301d87033ef] ocfs2: fix hung task in orphan recovery
git bisect bad 604ad02caddab12905643d5191b4a301d87033ef
# status: waiting for good commit(s), bad commit known
# good: [f548f2851b9323e7d0834d0c655a46644beeda64] MAINTAINERS: add Usama as a THP reviewer
git bisect good f548f2851b9323e7d0834d0c655a46644beeda64
# good: [1c5b1ee7d53126e8b0f027a7e7277a77900bb29f] signal: change sys_kill() to use SEND_SIG_NOINFO
git bisect good 1c5b1ee7d53126e8b0f027a7e7277a77900bb29f
# good: [a4db696aedb5f7ce197978df4a3c9e60c5c132cc] riscv: mm: fix concurrency in mark_new_valid_map()
git bisect good a4db696aedb5f7ce197978df4a3c9e60c5c132cc
# bad: [e595545005616ea8664184a6c81413fa52d46a49] Revert "lib: fix _parse_integer_limit() to handle overflow"
git bisect bad e595545005616ea8664184a6c81413fa52d46a49
# good: [8264c1b8de74dd1215ac2e35166db29562f16e23] tools/compiler: match glibc 2.42 definition of __attribute_const__
git bisect good 8264c1b8de74dd1215ac2e35166db29562f16e23
# first bad commit: [e595545005616ea8664184a6c81413fa52d46a49] Revert "lib: fix _parse_integer_limit() to handle overflow"
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [STATUS] next/master - 2b763db0c2763d6bf73d7d3e69665222d1f377cf
From: KernelCI bot @ 2026-07-04 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: linux-next
Hello,
Status summary for next/master
Dashboard:
https://d.kernelci.org/c/next/master/2b763db0c2763d6bf73d7d3e69665222d1f377cf/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 2b763db0c2763d6bf73d7d3e69665222d1f377cf
origin: maestro
test start time: 2026-07-03 16:48:48.516000+00:00
Builds: 64 ✅ 4 ❌ 0 ⚠️
Boots: 87 ✅ 2 ❌ 0 ⚠️
Tests: 21422 ✅ 4801 ❌ 550 ⚠️
### POSSIBLE REGRESSIONS
Hardware: cd8180-orion-o6
> Config: defconfig+netdev+nfs-root-boot+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a47f5cebb83f6a3e889f046
history: > ✅ > ✅ > ❌
- ltp
last run: https://d.kernelci.org/test/maestro:6a47f5b7bb83f6a3e889f039
history: > ✅ > ✅ > ❌
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
No unstable tests observed.
This branch has 3 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: linux-next: KUnit failure after merge of the mm-nonmm-unstable tree
From: Alexey Dobriyan @ 2026-07-04 4:55 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <992f91e5-a6cc-4b16-8026-74c9d32bc08d@sirena.org.uk>
On Fri, Jul 03, 2026 at 05:39:59PM +0100, Mark Brown wrote:
> On Fri, Jul 03, 2026 at 03:43:35PM +0100, Mark Brown wrote:
> > Hi all,
> >
> > After merging the mm-nonmm-unstable tree, today's linux-next failed
> > KUnit testing like this:
> >
> > [14:20:52] Configuring KUnit Kernel ...
> > [14:20:52] Building KUnit Kernel ...
> > Populating config with:
> > $ make ARCH=arm64 O=/tmp/next/arm64_kunit olddefconfig CROSS_COMPILE=aarch64-linux-gnu-
> > Building with:
> > $ make all compile_commands.json scripts_gdb ARCH=arm64 O=/tmp/next/arm64_kunit --jobs=192 CROSS_COMPILE=aarch64-linux-gnu-
> > [14:21:06] Starting KUnit Kernel (1/1)...
> > Running tests with:
> > $ qemu-system-aarch64 -nodefaults -m 1024 -kernel /tmp/next/arm64_kunit/arch/arm64/boot/Image.gz -append 'kunit.enable=1 console=ttyAMA0 kunit_shutdown=reboot' -no-reboot -nographic -accel kvm -accel hvf -accel tcg -serial stdio -machine virt -cpu max
> > [14:22:11] ============================================================
> > [14:22:11] =================== cmdline (8 subtests) ===================
> > [14:22:11] # cmdline_test_memparse: EXPECTATION FAILED at lib/tests/cmdline_kunit.c:249
> > [14:22:11] Expected ret == e->result, but
> > [14:22:11] ret == -16 (0xfffffffffffffff0)
> > [14:22:11] e->result == -1 (0xffffffffffffffff)
> > [14:22:11] when parsing '0xffffffffffffffff0'
> > [14:22:11] [FAILED] cmdline_test_memparse
> > [14:22:11] # module: cmdline_kunit
> > [14:22:11] # cmdline: pass:7 fail:1 skip:0 total:8
> > [14:22:11] # Totals: pass:7 fail:1 skip:0 total:8
> > [14:22:11] ===================== [FAILED] cmdline =====================
> > [14:22:11] ============================================================
> > [14:22:11] Testing complete. Ran 9225 tests: passed: 9104, failed: 1, skipped: 120
> > [14:22:11] Failures: cmdline.cmdline_test_memparse
> > [14:22:11] Test results stored in /tmp/next/arm64_kunit.json
> > [14:22:11] Elapsed time: 79.318s total, 0.002s configuring, 14.632s building, 64.682s running
> >
> > I honestly have no idea what's triggering this, nothing jumps out from
> > the commits introduced in the merge of the branch. If I have time later
> > I'll try to bisect the issue. I have used the tree from next-20260602
> > instead.
>
> bisect tells me it's due to:
>
> e595545005616 (Revert "lib: fix _parse_integer_limit() to handle overflow")
No, it is due to
commit 9a4580db6e9f83428813f671a79486469684069f
lib: fix memparse() to handle overflow
memparse should be rewritten with _parse_integer().
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-04 10:14 UTC (permalink / raw)
To: Boqun Feng
Cc: Gary Guo, Mark Brown, linux-next, linux-kernel, Miguel Ojeda,
Linus Torvalds, peterz, will, longman, mingo, gregkh
In-Reply-To: <akZxfzEtam8yPXEh@MacBook-0RXW5>
On 2026/07/02 23:11, Boqun Feng wrote:
>>> While testing lockdep changes on linux-next, I found there is a commit
>>> ca65ccfdc5b3 ("locking/lockdep: make lockdep_print_held_locks() always print if
>>> CONFIG_DEBUG_AID_FOR_SYZBOT=y") applied to lockdep. Checking the history it
>>> looks like this commit has been in linux-next for quite a while (at least 2
>>> months); there were no emails on LKML about this commit at all.
>>
>> Yes, these patches are for debugging difficult problems.
>>
>> For example, ca65ccfdc5b3 has been a concern for almost 8 years without progress
>> because developers show little interest for this change:
>>
>> https://lkml.kernel.org/r/1535975097-19080-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
>> https://lkml.kernel.org/r/7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp
>>
>
> This email was from 6 years ago, if that's the latest version, I'm not
> so sure you could say "developers show little interest for this change".
> Maybe you could provide more context about this that I missed?
I don't remember whether some discussions are done somewhere else. But judging from
the fact that code remains unchanged, nobody else has attempted or succeeded to
make this change.
Peter Zijlstra has commented at
https://lkml.kernel.org/r/20200313083107.GV12561@hirez.programming.kicks-ass.net
that disabling
if (p->state == TASK_RUNNING && p != current)
return;
check increases UAF potential, and suggested a kernel command line parameter for
whether to disable this check.
At the same time, Peter has thought that the risk of UAF is quite low.
As far as I know, syzbot did not hit UAF caused by disabling this check
(commit ca65ccfdc5b3 ("locking/lockdep: make lockdep_print_held_locks()
always print if CONFIG_DEBUG_AID_FOR_SYZBOT=y"). So, I guess that we can add
a switch (I prefer a kernel config option over a kernel command line parameter)
for this change.
> Also Greg
> left a comment there, you neither replied nor send a version to resolve
> it. Again I'm not sure if that could count as "developers show little
> interest for this change".
Linus does not like use of kernel config options, but I don't like use of kernel
command line parameters
( https://lkml.kernel.org/r/3ee9c586-002b-f504-9e3b-5afa8929209b@i-love.sakura.ne.jp ).
(1) Adding one switch for one behavior (either a kernel config option or a kernel command
line parameter) is an endless game of maintaining list of switches. Unless someone finds
that a dedicated switch is useful for specific case, number of switches should remain
minimized.
(2) Boot-time switches (i.e. kernel command line parameters) which are visible to
userspace (e.g. /proc/cmdline, /proc/1/cmdline, sysfs and maybe more) are more
difficult to maintain (i.e. follow the "never break the userspace" rule) than
compile-time switches (i.e. kernel config options) because the kernel implementation
might change in a way that makes boot-time switches unnecessary (e.g. switches that
are intended for debugging will become unnecessary after some problem is fixed).
(3) Run-time switch increases size of executable files and cost for runtime evaluation.
Also, assembly dump will include pointless code which is never executed due to run-time
switch. Excluding should-not-be-executed-code from the beginning minimizes size and cost.
(4) Compile-time switch is easier to prove configurations than scanning very very long kernel
command line which is likely already excluded from the console log of a crash report.
As a whole, I prefer compile-time and a global switch. If someone finds that run-time and/or
individual switch is more useful, we can change to run-time and/or individual switch as needed.
But no more response from Greg or Linus...
>>> I recognize that there is a need to add commits that serve as testing and
>>> debugging purpose to linux-next, but I think any of these changes should be
>>> temporary in nature and have acknowledgement from maintainers of touched code.
>>> Perhaps these changes should also be in a separate topic branch which gets
>>> pulled from linux-next temporarily.
>>
>> I'm happy if we can assign a git tree and a ML that are intended for temporary patches.
>> But please note that asking fuzzers to test a tree for hosting temporary patches is not
>> a choice. We need to test on massive instances to reproduce problems. linux.git is the
>
> I don't understand why it's not an option, couldn't you just ask syzbot
> to apply the patches only for linux-next, or merge a tree but only for
> linux-next?
Basic constraint is
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#no-custom-patches .
I don't know whether
https://groups.google.com/g/syzkaller/c/4Y3zvo_t_lI/m/z-4-79ZHBQAJ
could loosen this constraint to some degree.
> The point is not just syzbot consumes linux-next, everyone
> does. Although I trust your good intents, but temporarily patches
> (especially when they are silently merged into linux-next) can undermine
> what linux-next is supposed to be.
I know that syzbot is not the only consumer of linux-next. Therefore, I try to minimize
users affected (e.g. guard changes by CONFIG_DEBUG_AID_FOR_SYZBOT=y or CONFIG_KCOV=y )
when making changes.
>
> By "silently" I mean I didn't see you gave a heads-up about doing this
> either, e.g. an email saying "hey I'm including these into the
> linux-next". Maybe I'm missing something here?
I'm fine with announcing to ML that I am about to make debug/temporary changes.
But we might want a prefix for debug/temporary patches that are not intended for upstream?
Also, we might want a kernel config option (e.g. CONFIG_DEBUG_AID_FOR_SYZBOT) for
minimizing users affected?
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-04 12:06 UTC (permalink / raw)
To: Tetsuo Handa, Alexander Potapenko
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <7f1b93a9-f756-4bfc-81d7-1350ac1d50ac@I-love.SAKURA.ne.jp>
On Sat, Jul 4, 2026 at 12:15 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Basic constraint is
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#no-custom-patches .
No, that section talks about two different things: patches that are
fixes as well as temporary debugging patches.
For the former, it just says you should talk to maintainers to land
the fix. That is: you need agreement from maintainers, which is what
we have been saying.
For the latter, it simply says that sometimes debugging patches have
been added in the past to linux-next. It doesn't say it was done
unilaterally. (And even if it did, it is just a third-party document).
Critically, the section also explicitly ends with:
"One can also always run syzkaller locally on any kernel for better
stress testing
of a particular subsystem and/or patch."
...which sounds logical to me and is precisely what I was asking. So
to me it seems you don't actually need to put it in linux-next.
Now, reading the Google Groups thread you link, it seems like your
*actual constraint* doesn't come from syzkaller, but rather that you
want to use the compute resources Google allocates for big trees like
linux-next.
I understand it may be nice to use such resources, but the solution is
to talk to both sides, as you do in that thread. From what I see, they
even offered to add a mailing list for those patches:
"Aleksandr says we can create a special mailing list to test draft
patches, so the series sent to that list is fuzzed for some time,
similarly to how upstream patch testing works now.
Do you think that would help you to debug these issues? "
So what happened with that? It seems there was a way forward there,
no? (Cc'ing Alexander from that thread)
Cheers,
Miguel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).