* Re: Policy regarding linux-next only changes
From: Alexander Potapenko @ 2026-07-22 14:19 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Aleksandr Nogikh, Boqun Feng, Gary Guo, Mark Brown, linux-next,
linux-kernel, Miguel Ojeda, Linus Torvalds, peterz, will, longman,
mingo, gregkh, Miguel Ojeda
In-Reply-To: <c0bd6bc6-17de-468d-850d-df9955e2c142@I-love.SAKURA.ne.jp>
On Tue, Jul 21, 2026 at 1:49 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2026/07/21 18:38, Alexander Potapenko wrote:
> > Hi Tetsuo,
> >
> > You can send patches to syzbot@lists.linux.dev.
> >
> > E.g. I ran
> >
> > $ git send-email --suppress-cc=all --to=syzbot@lists.linux.dev
> > patches/kcov-tetsuo-v7/0001-kcov-fix-data-corruption-and-race-conditions-on-PREE.patch
> >
> > to test your latest kcov patch and got the results here:
> > https://ci.syzbot.org/series/33930a89-bb2a-4c5a-b6c5-d45829d5c94c
> >
> > The fuzzing ran on 8 VMs for 3 hours, and there were no new reports.
> >
> > Please let us know what you think of this workflow.
>
> Unfortunately, 8 VMs for 3 hours would be too little to stop my linux-next only patches.
>
> syzbot took more than one month in linux-next until I was able to report
> https://lkml.kernel.org/r/73ed3aa5-f6e1-47b6-9e5d-428ac1f4cbf3@I-love.SAKURA.ne.jp .
> I could have reported within 24 hours if all VMs (I don't know how many VMs are assigned)
> for networking trees were tested with my linux-next only patch.
Currently, two syzbot instances point at linux-next:
ci-upstream-linux-next-kasan-gce-root (10 VMs) and
ci-upstream-rust-kasan-gce (4 VMs).
So, we would need 420 VM-days of fuzzing to find that bug. Adding the
20 machines currently fuzzing net and net-next (assuming those are the
ones you refer to) would have reduced the time to 12.5 days, but not
to 24 hours.
During that time, we would stop fuzzing the main net/net-next
repositories. Another problem is that switching instances between
different Git trees is not zero-cost; it requires manual
reconfiguration and introduces maintenance overhead.
Now imagine that requests to extensively fuzz with a certain debug
patch arrive every week.
How do we decide which of those deserve more attention from the fuzzer?
For how long should we keep those patches?
How do we ensure these patches do not conflict with each other?
>
> syzbot was not able to trigger
> "BUG: %s/%u is doing I/O request on loop%d in Lo_rundown state.\n" message
> using https://lkml.kernel.org/r/30ccdd3c-6353-4a0f-bdc7-230ec3bf4765@I-love.SAKURA.ne.jp
> in linux-next tree. syzbot could have triggered this message within 24 hours if all VMs
> for upstream trees were tested with my linux-next only patch.
>
> What I want is a workflow that can test with patches for many days and many VMs.
I am afraid the only way to achieve that is to ensure the patch
reaches upstream.
I could imagine a compromise: a community-maintained repository
containing a bunch of debug patches applied on top of linux-next.
But we won't be able to allocate too many resources to fuzzing that
repository (it would be just one of the many), so reproducing certain
bugs may still take weeks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the drm-misc tree
From: Neil Armstrong @ 2026-07-22 8:44 UTC (permalink / raw)
To: Mark Brown, Simona Vetter, Intel Graphics, DRI, Maxime Ripard,
Albert Esteve
Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <al987knJq4h66FcJ@sirena.org.uk>
Hi Mark,
On 7/21/26 16:06, Mark Brown wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build
> (arm64 defconfig) failed like this:
>
> /tmp/next/build/drivers/gpu/drm/imx/dcss/dcss-kms.c: In function 'dcss_kms_bridge_connector_init':
> /tmp/next/build/drivers/gpu/drm/imx/dcss/dcss-kms.c:81:17: error: implicit declaration of function 'drm_panel_put'; did you mean 'drm_dev_put'? [-Wimplicit-function-declaration]
> 81 | drm_panel_put(panel);
> | ^~~~~~~~~~~~~
> | drm_dev_put
> make[8]: *** [/tmp/next/build/scripts/Makefile.build:289: drivers/gpu/drm/imx/dcss/dcss-kms.o] Error 1
> make[7]: *** [/tmp/next/build/scripts/Makefile.build:549: drivers/gpu/drm/imx/dcss] Error 2
> make[6]: *** [/tmp/next/build/scripts/Makefile.build:549: drivers/gpu/drm/imx] Error 2
> make[6]: *** Waiting for unfinished jobs....
> /tmp/next/build/drivers/gpu/drm/mxsfb/mxsfb_drv.c: In function 'mxsfb_attach_bridge':
> /tmp/next/build/drivers/gpu/drm/mxsfb/mxsfb_drv.c:130:17: error: implicit declaration of function 'drm_panel_put'; did you mean 'drm_dev_put'? [-Wimplicit-function-declaration]
> 130 | drm_panel_put(panel);
> | ^~~~~~~~~~~~~
> | drm_dev_put
>
> Caused by commit
>
> b71a623598d31 (drm/panel: of_drm_find_panel() return a counted reference)
>
> I have used the version from next-20260720 instead.
Seems the patch hasn't been properly build tested, I'll send a fix today.
Thanks,
Neil
^ permalink raw reply
* [STATUS] next/master - 290aaf24a551d5a0dce037e3fab30820f9113a10
From: KernelCI bot @ 2026-07-22 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/290aaf24a551d5a0dce037e3fab30820f9113a10/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 290aaf24a551d5a0dce037e3fab30820f9113a10
origin: maestro
test start time: 2026-07-21 17:13:37.473000+00:00
Builds: 64 ✅ 4 ❌ 0 ⚠️
Boots: 146 ✅ 3 ❌ 0 ⚠️
Tests: 22104 ✅ 2067 ❌ 2612 ⚠️
### POSSIBLE REGRESSIONS
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5fce7275cb84fb217236f0
history: > ✅ > ❌ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.devices-exist
last run: https://d.kernelci.org/test/maestro:6a5fcb2775cb84fb2171f7d0
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb2174530e
history: > ✅ > ❌ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb21745306
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae94400
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452ff
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452fe
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_9c0000_serial_988000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452de
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_gpu_3d00000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452d5
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_20c00000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452aa
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_26300000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452a5
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a5fef5775cb84fb21745250
history: > ✅ > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a5fb5bb75cb84fb2170b490
history: > ✅ > ❌ > ❌ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5fca6e75cb84fb2171f0ea
history: > ✅ > ❌ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5fea2375cb84fb21740729
history: > ✅ > ❌ > ❌ > ❌
### FIXED REGRESSIONS
Hardware: k3-am625-verdin-wifi-mallow
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt
last run: https://d.kernelci.org/test/maestro:6a5fcaaf75cb84fb2171f2f8
history: > ❌ > ❌ > ❌ > ❌ > ✅
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5fca7375cb84fb2171f10a
history: > ❌ > ✅ > ✅
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a5fcc4d75cb84fb21720475
history: > ❌ > ✅ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a5fcacf75cb84fb2171f3d7
history: > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a5fcf3675cb84fb21723b56
history: > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a5fcf3675cb84fb21723b57
history: > ❌ > ❌ > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a5fcab275cb84fb2171f302
history: > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452bf
history: > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a5fef9d75cb84fb2174570e
history: > ❌ > ❌ > ❌ > ✅
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a5fcace75cb84fb2171f3d0
history: > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a5fe71375cb84fb2173cb83
history: > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a5fe71375cb84fb2173cb84
history: > ❌ > ❌ > ✅
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a5fcab175cb84fb2171f2ff
history: > ❌ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a5fcacb75cb84fb2171f3bf
history: > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a5feb0175cb84fb2174209a
history: > ❌ > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a5feb0175cb84fb2174209b
history: > ❌ > ❌ > ❌ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a5fb5b875cb84fb2170b467
history: > ❌ > ❌ > ❌ > ✅
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_sound-wm8960
last run: https://d.kernelci.org/test/maestro:6a601dc275cb84fb21767856
history: > ❌ > ✅ > ✅ > ✅ > ✅
### UNSTABLE TESTS
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a5fca6275cb84fb2171f091
history: > ✅ > ✅ > ❌ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a5fcb7575cb84fb2171fea5
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_dsi_9ac0000_panel_0
last run: https://d.kernelci.org/test/maestro:6a5fce7275cb84fb217236ea
history: > ✅ > ✅ > ❌ > ✅
Hardware: meson-g12b-a311d-khadas-vim3
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a60239275cb84fb2176d3e5
history: > ❌ > ❌ > ✅ > ❌ > ❌
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a60241175cb84fb2176da6f
history: > ❌ > ❌ > ✅ > ❌ > ❌
Hardware: mt8395-genio-1200-evk
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a60239475cb84fb2176d3f2
history: > ✅ > ✅ > ✅ > ❌ > ✅
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a6028dd75cb84fb21775cd2
history: > ✅ > ✅ > ✅ > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a5fca9f75cb84fb2171f21e
history: > ❌ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb21745305
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb21745303
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb21745301
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452fb
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452f9
history: > ⚠️ > ⚠️ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a80000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452d8
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000_pcie_0_wifi_0
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452bd
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c10000
last run: https://d.kernelci.org/test/maestro:6a5fef5875cb84fb217452bc
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a5fef5775cb84fb21745251
history: > ✅ > ❌ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a5fb59675cb84fb2170b303
history: > ❌ > ✅ > ❌ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a5fca5d75cb84fb2171f073
history: > ✅ > ✅ > ❌ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a5fe6ec75cb84fb2173cb0e
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_iommu_3da0000
last run: https://d.kernelci.org/test/maestro:6a5fea2375cb84fb217406e2
history: > ✅ > ❌ > ❌ > ✅
### NEW BUILD ISSUES
- Issue: maestro:09e03f60e36b4243ba595281bf22987cb72d812d | version: 1
Build: maestro:6a5fae5b75cb84fb21705422
Comment: in expansion of macro ‘xfs_log_rtsb’ in fs/xfs/libxfs/xfs_sb.o (fs/xfs/libxfs/xfs_sb.c) [logspec:kbuild,kbuild.compiler.note]
First seen: 2026-07-21 21:58:25.868388+00:00
Culprit: code
- Issue: maestro:09e03f60e36b4243ba595281bf22987cb72d812d | version: 1
Build: maestro:6a5fae6175cb84fb21705480
Comment: in expansion of macro ‘xfs_log_rtsb’ in fs/xfs/libxfs/xfs_sb.o (fs/xfs/libxfs/xfs_sb.c) [logspec:kbuild,kbuild.compiler.note]
First seen: 2026-07-21 21:58:25.868388+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
* [REGRESSION] next/master: (build) in expansion of macro ‘xfs_log_rtsb’ in fs/xfs/libxfs/xfs_sb.o (fs...
From: KernelCI bot @ 2026-07-21 21:59 UTC (permalink / raw)
To: kernelci-results; +Cc: regressions, linux-next
New build issue found on next/master:
---
in expansion of macro ‘xfs_log_rtsb’ in fs/xfs/libxfs/xfs_sb.o (fs/xfs/libxfs/xfs_sb.c) [logspec:kbuild,kbuild.compiler.note]
---
Log excerpt:
=====================================================
/tmp/kci/linux/fs/xfs/libxfs/xfs_sb.c:1483:17: note: in expansion of macro ‘xfs_log_rtsb’
1483 | xfs_log_rtsb(tp, bp);
| ^~~~~~~~~~~~
cc1: all warnings being treated as errors
=====================================================
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/178467114526.1316.13205923514031471873@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:09e03f60e36b4243ba595281bf22987cb72d812d
- giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
- commit HEAD: 290aaf24a551d5a0dce037e3fab30820f9113a10
- tags: next-20260721
# Builds where the incident occurred:
## x86_64_defconfig+aws-ec2 on (x86_64):
- compiler: gcc-14
- config: None
- dashboard: https://d.kernelci.org/build/maestro:6a5fae5b75cb84fb21705422
#regzbot introduced: 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603..290aaf24a551d5a0dce037e3fab30820f9113a10
#regzbot link: https://d.kernelci.org/i/maestro:09e03f60e36b4243ba595281bf22987cb72d812d
#kernelci issue maestro:09e03f60e36b4243ba595281bf22987cb72d812d
--
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: conflicting changes between wireless and wireless-next
From: Jeff Johnson @ 2026-07-21 21:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Next Mailing List
In-Reply-To: <40efd021-9a65-4669-83a7-38a45c3d9846@oss.qualcomm.com>
On 7/21/2026 1:34 PM, Jeff Johnson wrote:
> On 7/21/2026 1:24 PM, Jeff Johnson wrote:
>> Johannes,
>> I'm trying to construct a new ath/main which involves combining:
>> wireless + wireless-next + ath-current + ath-next
>>
>> I'm seeing a conflict when combining wireless and wireless-next.
>>
>> There are similar patches in each tree fixing the same problem in a slightly
>> different way.
>>
>> Can you pick one over the other? I'm guessing drop the wireless-next version?
>>
>> thanks
>> /jeff
>>
>> wireless:
>> commit 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f
>> Author: Zhao Li <enderaoelyther@gmail.com>
>> Date: Sat Jun 13 02:50:45 2026 +0800
>>
>> wifi: mac80211: validate deauth frame length before reason access
>>
>> @@ -5641,13 +5641,15 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
>> struct ieee80211_mgmt *mgmt, size_t len)
>> {
>> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
>> - u16 reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
>> + u16 reason_code;
>>
>> lockdep_assert_wiphy(sdata->local->hw.wiphy);
>>
>> - if (len < 24 + 2)
>> + if (len < offsetofend(struct ieee80211_mgmt, u.deauth.reason_code))
>> return;
>>
>> + reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
>> +
>>
>> wireless-next
>> commit 8a0ed6ce39852d6a5dace3b3908c77c17468f250
>> Author: Shahar Tzarfati <shahar.tzarfati@intel.com>
>> Date: Wed Jul 15 21:27:44 2026 +0300
>>
>> wifi: mac80211: mlme: read deauth reason_code after frame length check
>>
>> @@ -5639,13 +5639,15 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
>> struct ieee80211_mgmt *mgmt, size_t len)
>> {
>> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
>> - u16 reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
>> + u16 reason_code;
>>
>> lockdep_assert_wiphy(sdata->local->hw.wiphy);
>>
>> - if (len < 24 + 2)
>> + if (len < IEEE80211_DEAUTH_FRAME_LEN)
>> return;
>>
>> + reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
>> +
>>
>>
>
> There is a second conflict, but unrelated changes
> (take both sets)
>
> wireless:
> commit 035ed430ce6a2c35b01e211844a9f0a7643e57a4
> Author: Zhao Li <enderaoelyther@gmail.com>
> Date: Fri Jun 12 23:24:41 2026 +0800
>
> wifi: mac80211: avoid non-S1G AID fallback for S1G assoc
>
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -7138,7 +7138,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
> - u16 capab_info, status_code, aid;
> + u16 capab_info, status_code, aid = 0;
> struct ieee80211_elems_parse_params parse_params = {
> .bss = NULL,
> .link_id = -1,
>
> wireless-next
> commit a607344292c2ec4546f33ed360eb713d261a7133
> Author: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
> Date: Fri Jul 17 17:10:44 2026 +0300
>
> wifi: mac80211: notify driver before destroying assoc link
>
> @@ -7138,6 +7146,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_
> sub_if_data *sdata,
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
> + enum assoc_status assoc_status = ASSOC_ABANDON;
> u16 capab_info, status_code, aid;
> struct ieee80211_elems_parse_params parse_params = {
> .bss = NULL,
>
Sigh, with those two conflicts resolved there is now a build error:
net/mac80211/mlme.c: In function ‘ieee80211_rx_mgmt_assoc_resp’:
net/mac80211/mlme.c:7279:17: error: label ‘abandon_assoc’ used but not defined
7279 | goto abandon_assoc;
| ^~~~
wireless has the following references:
035ed430ce6a2 net/mac80211/mlme.c (Zhao Li 2026-06-12 23:24:41 +0800 7225) goto abandon_assoc;
81151ce462e53 net/mac80211/mlme.c (Johannes Berg 2022-06-01 21:17:34 +0200 7284) goto abandon_assoc;
81151ce462e53 net/mac80211/mlme.c (Johannes Berg 2022-06-01 21:17:34 +0200 7295) goto abandon_assoc;
81151ce462e53 net/mac80211/mlme.c (Johannes Berg 2022-06-01 21:17:34 +0200 7371) abandon_assoc:
wireless-next removed the last 3 with:
commit a607344292c2ec4546f33ed360eb713d261a7133
Author: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Date: Fri Jul 17 17:10:44 2026 +0300
wifi: mac80211: notify driver before destroying assoc link
So in my merged tree I had to replace the 1st one, which I changed to
goto destroy_assoc_data;
/jeff
^ permalink raw reply
* Re: conflicting changes between wireless and wireless-next
From: Jeff Johnson @ 2026-07-21 20:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Next Mailing List
In-Reply-To: <d5581c2d-ec80-4698-8d2b-055e8e8e909f@oss.qualcomm.com>
On 7/21/2026 1:24 PM, Jeff Johnson wrote:
> Johannes,
> I'm trying to construct a new ath/main which involves combining:
> wireless + wireless-next + ath-current + ath-next
>
> I'm seeing a conflict when combining wireless and wireless-next.
>
> There are similar patches in each tree fixing the same problem in a slightly
> different way.
>
> Can you pick one over the other? I'm guessing drop the wireless-next version?
>
> thanks
> /jeff
>
> wireless:
> commit 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f
> Author: Zhao Li <enderaoelyther@gmail.com>
> Date: Sat Jun 13 02:50:45 2026 +0800
>
> wifi: mac80211: validate deauth frame length before reason access
>
> @@ -5641,13 +5641,15 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
> struct ieee80211_mgmt *mgmt, size_t len)
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> - u16 reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
> + u16 reason_code;
>
> lockdep_assert_wiphy(sdata->local->hw.wiphy);
>
> - if (len < 24 + 2)
> + if (len < offsetofend(struct ieee80211_mgmt, u.deauth.reason_code))
> return;
>
> + reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
> +
>
> wireless-next
> commit 8a0ed6ce39852d6a5dace3b3908c77c17468f250
> Author: Shahar Tzarfati <shahar.tzarfati@intel.com>
> Date: Wed Jul 15 21:27:44 2026 +0300
>
> wifi: mac80211: mlme: read deauth reason_code after frame length check
>
> @@ -5639,13 +5639,15 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
> struct ieee80211_mgmt *mgmt, size_t len)
> {
> struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
> - u16 reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
> + u16 reason_code;
>
> lockdep_assert_wiphy(sdata->local->hw.wiphy);
>
> - if (len < 24 + 2)
> + if (len < IEEE80211_DEAUTH_FRAME_LEN)
> return;
>
> + reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
> +
>
>
There is a second conflict, but unrelated changes
(take both sets)
wireless:
commit 035ed430ce6a2c35b01e211844a9f0a7643e57a4
Author: Zhao Li <enderaoelyther@gmail.com>
Date: Fri Jun 12 23:24:41 2026 +0800
wifi: mac80211: avoid non-S1G AID fallback for S1G assoc
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -7138,7 +7138,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
- u16 capab_info, status_code, aid;
+ u16 capab_info, status_code, aid = 0;
struct ieee80211_elems_parse_params parse_params = {
.bss = NULL,
.link_id = -1,
wireless-next
commit a607344292c2ec4546f33ed360eb713d261a7133
Author: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Date: Fri Jul 17 17:10:44 2026 +0300
wifi: mac80211: notify driver before destroying assoc link
@@ -7138,6 +7146,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_
sub_if_data *sdata,
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
+ enum assoc_status assoc_status = ASSOC_ABANDON;
u16 capab_info, status_code, aid;
struct ieee80211_elems_parse_params parse_params = {
.bss = NULL,
^ permalink raw reply
* conflicting changes between wireless and wireless-next
From: Jeff Johnson @ 2026-07-21 20:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Linux Next Mailing List
Johannes,
I'm trying to construct a new ath/main which involves combining:
wireless + wireless-next + ath-current + ath-next
I'm seeing a conflict when combining wireless and wireless-next.
There are similar patches in each tree fixing the same problem in a slightly
different way.
Can you pick one over the other? I'm guessing drop the wireless-next version?
thanks
/jeff
wireless:
commit 4a360c6e18dfa9d70006c7247a6a8cc8dfe0d60f
Author: Zhao Li <enderaoelyther@gmail.com>
Date: Sat Jun 13 02:50:45 2026 +0800
wifi: mac80211: validate deauth frame length before reason access
@@ -5641,13 +5641,15 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt, size_t len)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- u16 reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
+ u16 reason_code;
lockdep_assert_wiphy(sdata->local->hw.wiphy);
- if (len < 24 + 2)
+ if (len < offsetofend(struct ieee80211_mgmt, u.deauth.reason_code))
return;
+ reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
+
wireless-next
commit 8a0ed6ce39852d6a5dace3b3908c77c17468f250
Author: Shahar Tzarfati <shahar.tzarfati@intel.com>
Date: Wed Jul 15 21:27:44 2026 +0300
wifi: mac80211: mlme: read deauth reason_code after frame length check
@@ -5639,13 +5639,15 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt, size_t len)
{
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- u16 reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
+ u16 reason_code;
lockdep_assert_wiphy(sdata->local->hw.wiphy);
- if (len < 24 + 2)
+ if (len < IEEE80211_DEAUTH_FRAME_LEN)
return;
+ reason_code = le16_to_cpu(mgmt->u.deauth.reason_code);
+
^ permalink raw reply
* Re: linux-next: build failure after merge of the battery tree
From: Sebastian Reichel @ 2026-07-21 20:24 UTC (permalink / raw)
To: Chris Morgan
Cc: Mark Brown, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <PH0PR19MB997338AD35728E948A41A7A05AA5C22@PH0PR19MB997338.namprd19.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2628 bytes --]
Hi,
On Tue, Jul 21, 2026 at 12:15:32PM -0500, Chris Morgan wrote:
> On Tue, Jul 21, 2026 at 03:50:58PM +0100, Mark Brown wrote:
> > Hi all,
> >
> > After merging the battery tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > /tmp/next/build/drivers/power/supply/sgm41542_charger.c:209:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> > 209 | reg_val = FIELD_PREP(SGM4154X_PRECHRG_CUR_MASK, reg_val);
> > | ^
> > /tmp/next/build/drivers/power/supply/sgm41542_charger.c:249:8: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> > 249 | val = FIELD_GET(SGM4154X_ICHRG_CUR_MASK, reg);
> > | ^
> > /tmp/next/build/drivers/power/supply/sgm41542_charger.c:271:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> > 271 | reg_val = FIELD_PREP(SGM4154X_VREG_V_MASK, reg_val);
> > | ^
> > /tmp/next/build/drivers/power/supply/sgm41542_charger.c:293:8: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> > 293 | val = FIELD_GET(SGM4154X_VREG_V_MASK, reg);
> > | ^
> > /tmp/next/build/drivers/power/supply/sgm41542_charger.c:452:9: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> > 452 | time = FIELD_PREP(SGM4154X_WDT_TIMER_MASK, time);
> > | ^
> > 5 errors generated.
> >
> >
> > Caused by commit
> >
> > ac55d04627d41 (power: supply: sgm41542: Add SG Micro sgm41542 charger)
> >
> > I have used the version from next-20260720 instead.
> >
>
> Sorry, I wasn't aware this was getting pulled for Linux next or I
> would have noted that in the last revision I just sent.
mh, looks like b4 ty did not generate a response to you.
> I suspect I'm just missing a header here, which I am also missing
> in V8 just submitted. I'll add an include for linux/bitfield.h in
> revision 9 which I'll send just as soon in the next day or two
> once I can get a code review from a human and from the sashiko.dev
> code bot.
I will drop the driver for now and wait for a v9.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the battery tree
From: Chris Morgan @ 2026-07-21 17:15 UTC (permalink / raw)
To: Mark Brown
Cc: Sebastian Reichel, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <al-HUrIVJZ-vLN2n@sirena.org.uk>
On Tue, Jul 21, 2026 at 03:50:58PM +0100, Mark Brown wrote:
> Hi all,
>
> After merging the battery tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> /tmp/next/build/drivers/power/supply/sgm41542_charger.c:209:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 209 | reg_val = FIELD_PREP(SGM4154X_PRECHRG_CUR_MASK, reg_val);
> | ^
> /tmp/next/build/drivers/power/supply/sgm41542_charger.c:249:8: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 249 | val = FIELD_GET(SGM4154X_ICHRG_CUR_MASK, reg);
> | ^
> /tmp/next/build/drivers/power/supply/sgm41542_charger.c:271:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 271 | reg_val = FIELD_PREP(SGM4154X_VREG_V_MASK, reg_val);
> | ^
> /tmp/next/build/drivers/power/supply/sgm41542_charger.c:293:8: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 293 | val = FIELD_GET(SGM4154X_VREG_V_MASK, reg);
> | ^
> /tmp/next/build/drivers/power/supply/sgm41542_charger.c:452:9: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
> 452 | time = FIELD_PREP(SGM4154X_WDT_TIMER_MASK, time);
> | ^
> 5 errors generated.
>
>
> Caused by commit
>
> ac55d04627d41 (power: supply: sgm41542: Add SG Micro sgm41542 charger)
>
> I have used the version from next-20260720 instead.
>
Sorry, I wasn't aware this was getting pulled for Linux next or I
would have noted that in the last revision I just sent. I suspect
I'm just missing a header here, which I am also missing in V8 just
submitted. I'll add an include for linux/bitfield.h in revision 9
which I'll send just as soon in the next day or two once I can get
a code review from a human and from the sashiko.dev code bot.
Thank you,
Chris
^ permalink raw reply
* Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree
From: Matthew Brost @ 2026-07-21 16:55 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Christoph Hellwig, Mark Brown, Andrew Morton,
Linux Kernel Mailing List, Linux Next Mailing List, Hugh Dickins,
Baolin Wang, linux-mm, Christian Koenig, Huang Rui, dri-devel
In-Reply-To: <al6cVnNv2TuhuiV3@gsse-cloud1.jf.intel.com>
On Mon, Jul 20, 2026 at 03:08:22PM -0700, Matthew Brost wrote:
> On Mon, Jul 20, 2026 at 03:46:00PM +0100, Matthew Wilcox wrote:
> > On Mon, Jul 20, 2026 at 04:41:41PM +0200, Christoph Hellwig wrote:
> > > > /**
> > > > - * ttm_backup_backup_page() - Backup a page
> > > > + * ttm_backup_backup_folio() - Backup a folio
> > > > * @backup: The struct backup pointer to use.
> > > > - * @page: The page to back up.
> > > > - * @writeback: Whether to perform immediate writeback of the page.
> > > > + * @folio: The folio to back up.
> > > > + * @order: The allocation order of @folio. Since TTM allocates higher-order
> > > > + * pages without __GFP_COMP, folio_nr_pages(@folio) would always
> > > > + * return 1; the caller must pass the true order explicitly.
> >
> > Wait, what? This is just broken. TTM should change to allocate using
> > GFP_COMP. Why can't graphics people ask questions before writing stupid
> > patches?
> >
>
> To be honest, I have no idea why TTM doesn't set GFP_COMP. This
> predates my work in graphics by nearly a decade.
>
> I found the following comment in TTM, which was added in this patch:
> `git format-patch -1 bf9eee249ac20`
>
> As far as I can tell, setting GFP_COMP would make things a lot easier in
> a number of places.
>
> Christian, who maintains TTM, is out for a couple of weeks, but this is
> something we should probably take a closer look at.
>
I have looked into this a bit, changing TTM over to allocations with
GFP_COMP seems pretty straight forward. I have local patches that are
working with my driver (Xe), will post something shortly.
Matt
> Sorry for sending a stupid patch.
>
> Matt
^ permalink raw reply
* linux-next: Tree for Jul 21
From: Mark Brown @ 2026-07-21 16:54 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
Hi all,
Changes since 20260720:
The bpf-next tree acquired a conflict with the net tree.
The drm-misc tree acquired a build failure, I have used the version from
next-20260720 instead.
The battery tree acquired a build failure, I have used the version from
next-20260720 instead.
The tip tree acquired a conflict with the mm-hotfixes-unstable tree.
Non-merge commits (relative to Linus' tree): 7469
7082 files changed, 302697 insertions(+), 111532 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 429 trees (counting Linus' and 133 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 tip tree with the mm-hotfixes-unstable tree
From: Lorenzo Stoakes (ARM) @ 2026-07-21 16:14 UTC (permalink / raw)
To: Mark Brown
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Andrew Morton, Dave Hansen, Linux Kernel Mailing List,
Linux Next Mailing List, Mike Rapoport
In-Reply-To: <al94LynD19vVIqw6@sirena.org.uk>
On Tue, Jul 21, 2026 at 02:46:23PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/mm/pat/set_memory.c
>
> between commit:
>
> b8228ddfd0586 ("x86/mm/pat: allocate split page tables as kernel page tables")
>
> from the mm-hotfixes-unstable tree and commit:
>
> 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
>
> from the tip 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, the resolution looks correct! :)
There's some discussion on the patches themselves but that's by-the-by.
Cheers, Lorenzo
>
> diff --cc arch/x86/mm/pat/set_memory.c
> index a67ca33b9dd12,1f2a2ba9ce57d..0000000000000
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@@ -439,26 -441,12 +442,28 @@@ static void __cpa_collapse_large_pages(
>
> list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> list_del(&ptdesc->pt_list);
> - pagetable_free(ptdesc);
> +
> + if (folio_test_pgtable(ptdesc_folio(ptdesc)))
> + pagetable_dtor_free(ptdesc);
> + else
> + pagetable_free(ptdesc);
> }
> +
> + spin_unlock(&cpa_lock);
> }
>
> +static void cpa_collapse_large_pages(struct cpa_data *cpa)
> +{
> + /*
> + * Take the mmap write lock on init_mm to:
> + * - Avoid a use-after-free if raced by ptdump (which takes its own
> + * write lock on init_mm).
> + * - Serialise concurrent CPA walkers.
> + */
> + scoped_guard(mmap_write_lock, &init_mm)
> + __cpa_collapse_large_pages(cpa);
> +}
> +
> static void cpa_flush(struct cpa_data *cpa, int cache)
> {
> unsigned int i;
> @@@ -1249,18 -1237,16 +1253,16 @@@ __split_large_page(struct cpa_data *cpa
> static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
> unsigned long address)
> {
> - struct ptdesc *ptdesc;
> + pte_t *pte;
>
> - if (!debug_pagealloc_enabled())
> - spin_unlock(&cpa_lock);
> + spin_unlock(&cpa_lock);
> - ptdesc = pagetable_alloc(GFP_KERNEL, 0);
> + pte = pte_alloc_one_kernel(&init_mm);
> - if (!debug_pagealloc_enabled())
> - spin_lock(&cpa_lock);
> + spin_lock(&cpa_lock);
> - if (!ptdesc)
> + if (!pte)
> return -ENOMEM;
>
> - if (__split_large_page(cpa, kpte, address, ptdesc))
> - pagetable_free(ptdesc);
> + if (__split_large_page(cpa, kpte, address, pte))
> + pte_free_kernel(&init_mm, pte);
>
> return 0;
> }
^ permalink raw reply
* Re: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Lorenzo Stoakes (ARM) @ 2026-07-21 15:45 UTC (permalink / raw)
To: Borislav Petkov
Cc: Mike Rapoport, syzbot, Denis V. Lunev, Vishal Moola, dave.hansen,
hpa, linux-kernel, linux-next, luto, mingo, peterz, sfr,
syzkaller-bugs, tglx, x86
In-Reply-To: <20260721150547.GCal-Ky_X99ULTLK2Q@fat_crate.local>
On Tue, Jul 21, 2026 at 08:05:47AM -0700, Borislav Petkov wrote:
> On Tue, Jul 21, 2026 at 03:03:41PM +0100, Lorenzo Stoakes (ARM) wrote:
> > You mean the series that changes core mm and has strict dependencies on core mm
> > changes and solves issues elsewhere than x86 CPA, that one should have gone
> > through the x86 tree?
>
> We do immutable branches for things like that. For example.
Coming soon to mm :)
>
> Bottom line is, there needs to be synchronization across trees when they touch
> the same file.
Yeah completely agreed as discussed off list :) comms is key.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Cheers, Lorenzo
^ permalink raw reply
* Re: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Borislav Petkov @ 2026-07-21 15:05 UTC (permalink / raw)
To: Lorenzo Stoakes (ARM)
Cc: Mike Rapoport, syzbot, Denis V. Lunev, Vishal Moola, dave.hansen,
hpa, linux-kernel, linux-next, luto, mingo, peterz, sfr,
syzkaller-bugs, tglx, x86
In-Reply-To: <al97bRuyGo2UpCv3@lucifer>
On Tue, Jul 21, 2026 at 03:03:41PM +0100, Lorenzo Stoakes (ARM) wrote:
> You mean the series that changes core mm and has strict dependencies on core mm
> changes and solves issues elsewhere than x86 CPA, that one should have gone
> through the x86 tree?
We do immutable branches for things like that. For example.
Bottom line is, there needs to be synchronization across trees when they touch
the same file.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* linux-next: build failure after merge of the battery tree
From: Mark Brown @ 2026-07-21 14:50 UTC (permalink / raw)
To: Sebastian Reichel, Chris Morgan
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
Hi all,
After merging the battery tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/tmp/next/build/drivers/power/supply/sgm41542_charger.c:209:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
209 | reg_val = FIELD_PREP(SGM4154X_PRECHRG_CUR_MASK, reg_val);
| ^
/tmp/next/build/drivers/power/supply/sgm41542_charger.c:249:8: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
249 | val = FIELD_GET(SGM4154X_ICHRG_CUR_MASK, reg);
| ^
/tmp/next/build/drivers/power/supply/sgm41542_charger.c:271:12: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
271 | reg_val = FIELD_PREP(SGM4154X_VREG_V_MASK, reg_val);
| ^
/tmp/next/build/drivers/power/supply/sgm41542_charger.c:293:8: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
293 | val = FIELD_GET(SGM4154X_VREG_V_MASK, reg);
| ^
/tmp/next/build/drivers/power/supply/sgm41542_charger.c:452:9: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
452 | time = FIELD_PREP(SGM4154X_WDT_TIMER_MASK, time);
| ^
5 errors generated.
Caused by commit
ac55d04627d41 (power: supply: sgm41542: Add SG Micro sgm41542 charger)
I have used the version from next-20260720 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: test failure after merge of the kunit-next tree
From: Mark Brown @ 2026-07-21 14:45 UTC (permalink / raw)
To: Shuah Khan
Cc: David Gow, Linus Walleij, Bartosz Golaszewski,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <f54627c0-83fc-4df4-9539-e9df051cf2e8@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On Tue, Jul 21, 2026 at 08:41:29AM -0600, Shuah Khan wrote:
> On 7/20/26 03:01, David Gow wrote:
> > I'm pretty sure the fix for this is a part of:
> > gpio: kunit: add test cases verifying swnode devlink support
> > (https://lore.kernel.org/all/20260720-swnode-fw-devlink-v5-1-ec250ae6af91@oss.qualcomm.com/#r)
> Thanks David.
> Hope this makes it into linux-next soon through gpio tree.
Whatever it was the problem went away yesterday, though sometimes that
is just glitchy tests.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: test failure after merge of the kunit-next tree
From: Shuah Khan @ 2026-07-21 14:41 UTC (permalink / raw)
To: David Gow, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Shuah Khan
In-Reply-To: <60e97b0c-701e-4b32-9056-32994fb8088a@davidgow.net>
On 7/20/26 03:01, David Gow wrote:
> Le 18/07/2026 à 08:02, Mark Brown a écrit :
>> Hi all,
>>
>> After merging the kunit-next tree, today's linux-next build
>> (arm64 kunit) failed like this:
>>
>> [22:59:27] Configuring KUnit Kernel ...
>> [22:59:27] 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-
>> [22:59:30] 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
>> [23:00:36] ============================================================
>> [23:00:36] ========== gpio-unbind-with-consumers (1 subtest) ==========
>> [23:00:36] # gpio_unbind_with_consumers: ASSERTION FAILED at drivers/gpio/gpiolib-kunit.c:393
>> [23:00:36] Expected ret == 0x0001, but
>> [23:00:36] ret == 0 (0x0)
>> [23:00:36] 0x0001 == 1 (0x1)
>> [23:00:36] [FAILED] gpio_unbind_with_consumers
>> [23:00:36] # module: gpiolib_kunit
>> [23:00:36] =========== [FAILED] gpio-unbind-with-consumers ============
>> [23:00:36] # gpio-swnode-hog: # failed to initialize (-17)
>> [23:00:36] [FAILED] gpio-swnode-hog
>> [23:00:36] ============================================================
>> [23:00:36] Testing complete. Ran 9377 tests: passed: 9284, failed: 2, skipped: 91
>> [23:00:36] Failures: gpio-unbind-with-consumers, gpio-swnode-hog
>> [23:00:36] Test results stored in /tmp/next/arm64_kunit.json
>> [23:00:36] Elapsed time: 69.716s total, 0.002s configuring, 3.680s building, 66.027s running
>>
>> This is caused by commit
>>
>> a05cfd98c5eca (gpio: kunit: add test cases for software node hogs)
>>
>> which was from the gpio-brgl tree, it has only just become visible since
>>
>> 34b5c0132952c (kunit: configs: enable GPIO kunit test cases in all_tests.config)
>>
>> was added causing the gpiolib tests to actually be run though neither of
>> these commits was added today (the KUnit tree did not change for a
>> while). I'm not clear why this has started failing today, presumably
>> some third commit from another tree has started triggering a regression
>> since neither of these trees has changed.
>>
>> I have left this for today.
>
>
> I'm pretty sure the fix for this is a part of:
> gpio: kunit: add test cases verifying swnode devlink support
> (https://lore.kernel.org/all/20260720-swnode-fw-devlink-v5-1-ec250ae6af91@oss.qualcomm.com/#r)
>
Thanks David.
Hope this makes it into linux-next soon through gpio tree.
thanks,
-- Shuah
^ permalink raw reply
* Re: Missing signoff in the kvm-arm-fixes tree
From: Mark Brown @ 2026-07-21 14:24 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-kernel, linux-next
In-Reply-To: <86tspse8vo.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
On Tue, Jul 21, 2026 at 03:04:59PM +0100, Marc Zyngier wrote:
> Oliver Upton <oupton@kernel.org> and Marc Zyngier <maz@kernel.org> are
> the current tree maintainers.
Thanks for confirming, the contacts are updated now.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Lorenzo Stoakes (ARM) @ 2026-07-21 14:10 UTC (permalink / raw)
To: Mike Rapoport
Cc: Borislav Petkov, syzbot, Denis V. Lunev, Vishal Moola,
dave.hansen, hpa, linux-kernel, linux-next, luto, mingo, peterz,
sfr, syzkaller-bugs, tglx, x86
In-Reply-To: <al9jHTONTrsImlVV@lucifer>
On Tue, Jul 21, 2026 at 01:39:51PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Tue, Jul 21, 2026 at 01:35:13PM +0300, Mike Rapoport wrote:
> > On Mon, Jul 20, 2026 at 07:24:48PM -0700, Borislav Petkov wrote:
> > > Adding all folks who touched this recently.
> >
> > You forgot Lorenzo ;-)
>
> Yup :) thanks.
>
> OK so this is a screw up with merging.
Well nobody told me there was a v2 ([3]), that it was taken or thought to cc- me on
anything, so that goes some way towards explaining how this happened :)
[3]:https://lore.kernel.org/all/20260715183453.2381141-1-den@openvz.org/
Anyway as per below TL;DR is the latest revision of my series does NOT conflict
with this series and the HEAD of linux-next _is fixed_.
The commit message of that v2 is now not really accurate but it does solve
_another_ possible debug_pagealloc race.
Thanks, Lorenzo
>
> Two fixes are applied at once here and they are NOT compatible :)
>
> Denis's ([0]) holds a spin lock over the operation during which an older
> revision of mine ([1] - current, probable next revision [2]) tries to take a
> sleeping mmap lock, hence the report.
>
> But actually my + Denis's fixes, with the latest revision of mine ([2]) are fine
> - as I take the mmap lock prior to any spin locks being taken in the (newly
> renamed) __cpa_collapse_large_pages().
>
> TL;DR - not a real issue and next will get fixed when the newer version of my
> series is taken (with sensible coflict resolution).
>
> And in fact I can see it's fixed at -next master anyway :)
>
> I think actually my + Denis's fixes are actually potentially complimentary, will
> reply on that thread about that.
>
> Cheers, Lorenzo
>
> [0]:https://lore.kernel.org/all/20260626163213.2284080-1-den@openvz.org/
> [1]:https://lore.kernel.org/linux-mm/20260716-series-vmap-race-fix-v4-0-8c108c4317df@kernel.org/
> [2]:https://lore.kernel.org/all/20260714-series-vmap-race-fix-v3-0-b812eccfa0f9@kernel.org/
>
> >
> > > On Mon, Jul 20, 2026 at 09:59:25AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit: 1a1757b76427 Add linux-next specific files for 20260716
> > > > git tree: linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16c734b9580000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=8d1a274c57796a86
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=ee7ecfcd0e3f185e835a
> > > > compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> > > >
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/923ee89ba238/disk-1a1757b7.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/cb34d1bf205c/vmlinux-1a1757b7.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/bf183d434c82/bzImage-1a1757b7.xz
> > > >
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+ee7ecfcd0e3f185e835a@syzkaller.appspotmail.com
> > > >
> > > > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> > > > kfence: initialized - using 2097152 bytes for 255 objects at 0xffff88823be00000-0xffff88823c000000
> > > > Console: colour VGA+ 80x25
> > > > printk: legacy console [ttyS0] enabled
> > > > printk: legacy console [ttyS0] enabled
> > > > printk: legacy bootconsole [earlyser0] disabled
> > > > printk: legacy bootconsole [earlyser0] disabled
> > > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> > > > ... MAX_LOCKDEP_SUBCLASSES: 8
> > > > ... MAX_LOCK_DEPTH: 48
> > > > ... MAX_LOCKDEP_KEYS: 8192
> > > > ... CLASSHASH_SIZE: 4096
> > > > ... MAX_LOCKDEP_ENTRIES: 1048576
> > > > ... MAX_LOCKDEP_CHAINS: 1048576
> > > > ... CHAINHASH_SIZE: 524288
> > > > memory used by lock dependency info: 106625 kB
> > > > memory used for stack traces: 8320 kB
> > > > per task-struct memory footprint: 1920 bytes
> > > > mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
> > > > ACPI: Core revision 20260408
> > > > APIC: Switch to symmetric I/O mode setup
> > > > x2apic enabled
> > > > APIC: Switched APIC routing to: physical x2apic
> > > > ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
> > > > clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb63109b96, max_idle_ns: 440795265316 ns
> > > > Calibrating delay loop (skipped) preset value.. 4399.99 BogoMIPS (lpj=21999980)
> > > > Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
> > > > Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4
> > > > mitigations: Enabled attack vectors: user_kernel, user_user, guest_host, guest_guest, SMT mitigations: auto
> > > > Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
> > > > Spectre V2 : Mitigation: IBRS
> > > > RETBleed: Mitigation: IBRS
> > > > ITS: Mitigation: Aligned branch/return thunks
> > > > Spectre V2 : User space: Mitigation: STIBP via prctl
> > > > MDS: Mitigation: Clear CPU buffers
> > > > TAA: Mitigation: Clear CPU buffers
> > > > MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode
> > > > Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
> > > > Spectre V2 : Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT
> > > > Spectre V2 : Enabling IBPB for BPF
> > > > Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
> > > > active return thunk: its_return_thunk
> > > > Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall and VM exit
> > > > x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> > > > x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> > > > x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> > > > x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> > > > x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> > > >
> > > > =============================
> > > > [ BUG: Invalid wait context ]
> > > > syzkaller #0 Not tainted
> > > > -----------------------------
> > > > swapper/0/0 is trying to lock:
> > > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> > > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> > > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> > > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > > > other info that might help us debug this:
> > > > context-{5:5}
> > > > locks held by swapper/0/0: 1, last CPU#0:
> > > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
> > > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:421 [inline]
> > > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: change_page_attr_set_clr+0x967/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > > > stack backtrace:
> > > > CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/25/2026
> > > > Call Trace:
> > > > <TASK>
> > > > dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
> > > > print_lock_invalid_wait_context kernel/locking/lockdep.c:4846 [inline]
> > > > check_wait_context kernel/locking/lockdep.c:4918 [inline]
> > > > __lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5204
> > > > lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5906
> > > > down_read+0x4a/0x330 kernel/locking/rwsem.c:1574
> > > > mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> > > > class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> > > > cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> > > > cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > > > change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > > > set_memory_rox+0xbe/0x100 arch/x86/mm/pat/set_memory.c:2341
> > > > its_pages_protect arch/x86/kernel/alternative.c:168 [inline]
> > > > its_fini_core arch/x86/kernel/alternative.c:175 [inline]
> > > > alternative_instructions+0x95/0x100 arch/x86/kernel/alternative.c:2264
> > > > arch_cpu_finalize_init+0xb2/0x1f0 arch/x86/kernel/cpu/common.c:2633
> > > > start_kernel+0x310/0x3e0 init/main.c:1153
> > > > x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
> > > > x86_64_start_kernel+0x137/0x1b0 arch/x86/kernel/head64.c:291
> > > > common_startup_64+0x13e/0x157
> > > > </TASK>
> > > > pid_max: default: 32768 minimum: 301
> > > > landlock: Up and running.
> > > > Yama: becoming mindful.
> > > > TOMOYO Linux initialized
> > > > AppArmor: AppArmor initialized
> > > > LSM support for eBPF active
> > > > Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, vmalloc hugepage)
> > > > Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
> > > > Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> > > > Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> > > > VFS: Finished mounting rootfs on nullfs
> > > > Running RCU synchronous self tests
> > > > Running RCU synchronous self tests
> > > > numa_add_cpu cpu 1 node 0: mask now 0-1
> > > > numa_add_cpu cpu 1 node 1: mask now 0-1
> > > >
> > > >
> > > > ---
> > > > This report is generated by a bot. It may contain errors.
> > > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > > syzbot engineers can be reached at syzkaller@googlegroups.com.
> > > >
> > > > syzbot will keep track of this issue. See:
> > > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > > >
> > > > If the report is already addressed, let syzbot know by replying with:
> > > > #syz fix: exact-commit-title
> > > >
> > > > If you want to overwrite report's subsystems, reply with:
> > > > #syz set subsystems: new-subsystem
> > > > (See the list of subsystem names on the web dashboard)
> > > >
> > > > If the report is a duplicate of another one, reply with:
> > > > #syz dup: exact-subject-of-another-report
> > > >
> > > > If you want to undo deduplication, reply with:
> > > > #syz undup
> > >
> > > --
> > > Regards/Gruss,
> > > Boris.
> > >
> > > https://people.kernel.org/tglx/notes-about-netiquette
> >
> > --
> > Sincerely yours,
> > Mike.
^ permalink raw reply
* linux-next: build failure after merge of the drm-misc tree
From: Mark Brown @ 2026-07-21 14:06 UTC (permalink / raw)
To: Simona Vetter, Intel Graphics, DRI, Maxime Ripard, Albert Esteve,
Neil Armstrong
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
Hi all,
After merging the drm-misc tree, today's linux-next build
(arm64 defconfig) failed like this:
/tmp/next/build/drivers/gpu/drm/imx/dcss/dcss-kms.c: In function 'dcss_kms_bridge_connector_init':
/tmp/next/build/drivers/gpu/drm/imx/dcss/dcss-kms.c:81:17: error: implicit declaration of function 'drm_panel_put'; did you mean 'drm_dev_put'? [-Wimplicit-function-declaration]
81 | drm_panel_put(panel);
| ^~~~~~~~~~~~~
| drm_dev_put
make[8]: *** [/tmp/next/build/scripts/Makefile.build:289: drivers/gpu/drm/imx/dcss/dcss-kms.o] Error 1
make[7]: *** [/tmp/next/build/scripts/Makefile.build:549: drivers/gpu/drm/imx/dcss] Error 2
make[6]: *** [/tmp/next/build/scripts/Makefile.build:549: drivers/gpu/drm/imx] Error 2
make[6]: *** Waiting for unfinished jobs....
/tmp/next/build/drivers/gpu/drm/mxsfb/mxsfb_drv.c: In function 'mxsfb_attach_bridge':
/tmp/next/build/drivers/gpu/drm/mxsfb/mxsfb_drv.c:130:17: error: implicit declaration of function 'drm_panel_put'; did you mean 'drm_dev_put'? [-Wimplicit-function-declaration]
130 | drm_panel_put(panel);
| ^~~~~~~~~~~~~
| drm_dev_put
Caused by commit
b71a623598d31 (drm/panel: of_drm_find_panel() return a counted reference)
I have used the version from next-20260720 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Missing signoff in the kvm-arm-fixes tree
From: Marc Zyngier @ 2026-07-21 14:04 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel, linux-next
In-Reply-To: <0604b71d-5a05-47f6-949c-26e0ceaf1b78@sirena.org.uk>
On Tue, 21 Jul 2026 14:37:15 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> On Tue, Jul 21, 2026 at 01:02:19PM +0100, Marc Zyngier wrote:
>
> > BTW, could you please Cc the actual maintainers of KVM/arm64?
> > Christoffer has been out of that look for over 7 years now...
>
> Of course, I did think that - just to confirm, that's you and Oliver
> (with oupton@kernel.org as his address) since AIUI it's you two that
> manage the git tree? Usually it's the people with write access in the
> contacts list, but I can add whoever you like pretty much.
Oliver Upton <oupton@kernel.org> and Marc Zyngier <maz@kernel.org> are
the current tree maintainers.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Lorenzo Stoakes (ARM) @ 2026-07-21 14:03 UTC (permalink / raw)
To: Borislav Petkov
Cc: Mike Rapoport, syzbot, Denis V. Lunev, Vishal Moola, dave.hansen,
hpa, linux-kernel, linux-next, luto, mingo, peterz, sfr,
syzkaller-bugs, tglx, x86
In-Reply-To: <20260721135323.GAal9504VvxYHpcPtd@fat_crate.local>
On Tue, Jul 21, 2026 at 06:53:23AM -0700, Borislav Petkov wrote:
> On Tue, Jul 21, 2026 at 01:39:45PM +0100, Lorenzo Stoakes (ARM) wrote:
> > OK so this is a screw up with merging.
> >
> > Two fixes are applied at once here and they are NOT compatible :)
> >
> > Denis's ([0]) holds a spin lock over the operation during which an older
> > revision of mine ([1] - current, probable next revision [2]) tries to take a
> > sleeping mmap lock, hence the report.
>
> Lemme guess: if those were merged by the same tree - tip - where arch/x86/
> changes belong, we would've caught it, right?
>
> Pff.
You mean the series that changes core mm and has strict dependencies on core mm
changes and solves issues elsewhere than x86 CPA, that one should have gone
through the x86 tree?
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
Thanks, Lorenzo
^ permalink raw reply
* Re: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Borislav Petkov @ 2026-07-21 13:53 UTC (permalink / raw)
To: Lorenzo Stoakes (ARM)
Cc: Mike Rapoport, syzbot, Denis V. Lunev, Vishal Moola, dave.hansen,
hpa, linux-kernel, linux-next, luto, mingo, peterz, sfr,
syzkaller-bugs, tglx, x86
In-Reply-To: <al9jHTONTrsImlVV@lucifer>
On Tue, Jul 21, 2026 at 01:39:45PM +0100, Lorenzo Stoakes (ARM) wrote:
> OK so this is a screw up with merging.
>
> Two fixes are applied at once here and they are NOT compatible :)
>
> Denis's ([0]) holds a spin lock over the operation during which an older
> revision of mine ([1] - current, probable next revision [2]) tries to take a
> sleeping mmap lock, hence the report.
Lemme guess: if those were merged by the same tree - tip - where arch/x86/
changes belong, we would've caught it, right?
Pff.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Mark Brown @ 2026-07-21 13:46 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Andrew Morton, Dave Hansen, Linux Kernel Mailing List,
Linux Next Mailing List, Lorenzo Stoakes, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 2487 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/mm/pat/set_memory.c
between commit:
b8228ddfd0586 ("x86/mm/pat: allocate split page tables as kernel page tables")
from the mm-hotfixes-unstable tree and commit:
5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
from the tip 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 arch/x86/mm/pat/set_memory.c
index a67ca33b9dd12,1f2a2ba9ce57d..0000000000000
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@@ -439,26 -441,12 +442,28 @@@ static void __cpa_collapse_large_pages(
list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
list_del(&ptdesc->pt_list);
- pagetable_free(ptdesc);
+
+ if (folio_test_pgtable(ptdesc_folio(ptdesc)))
+ pagetable_dtor_free(ptdesc);
+ else
+ pagetable_free(ptdesc);
}
+
+ spin_unlock(&cpa_lock);
}
+static void cpa_collapse_large_pages(struct cpa_data *cpa)
+{
+ /*
+ * Take the mmap write lock on init_mm to:
+ * - Avoid a use-after-free if raced by ptdump (which takes its own
+ * write lock on init_mm).
+ * - Serialise concurrent CPA walkers.
+ */
+ scoped_guard(mmap_write_lock, &init_mm)
+ __cpa_collapse_large_pages(cpa);
+}
+
static void cpa_flush(struct cpa_data *cpa, int cache)
{
unsigned int i;
@@@ -1249,18 -1237,16 +1253,16 @@@ __split_large_page(struct cpa_data *cpa
static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
unsigned long address)
{
- struct ptdesc *ptdesc;
+ pte_t *pte;
- if (!debug_pagealloc_enabled())
- spin_unlock(&cpa_lock);
+ spin_unlock(&cpa_lock);
- ptdesc = pagetable_alloc(GFP_KERNEL, 0);
+ pte = pte_alloc_one_kernel(&init_mm);
- if (!debug_pagealloc_enabled())
- spin_lock(&cpa_lock);
+ spin_lock(&cpa_lock);
- if (!ptdesc)
+ if (!pte)
return -ENOMEM;
- if (__split_large_page(cpa, kpte, address, ptdesc))
- pagetable_free(ptdesc);
+ if (__split_large_page(cpa, kpte, address, pte))
+ pte_free_kernel(&init_mm, pte);
return 0;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with the net tree
From: Mark Brown @ 2026-07-21 13:46 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Jakub Kicinski, Jordan Rife, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/filter.c
between commit:
3f4920d165b29 ("bpf: Reject redirect helpers without a bpf_net_context")
from the net tree and commit:
509ca545d4255 ("bpf: Support BPF_F_EGRESS with bpf_redirect_peer")
from the bpf-next 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 net/core/filter.c
index 11bb0d236822a,0b7afdd0ae474..0000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -2575,13 -2578,12 +2580,13 @@@ static const struct bpf_func_proto bpf_
BPF_CALL_2(bpf_redirect_peer, u32, ifindex, u64, flags)
{
- struct bpf_redirect_info *ri = bpf_net_ctx_get_ri();
+ struct bpf_redirect_info *ri;
- if (unlikely(!bpf_net_ctx_get() || flags))
- if (unlikely(flags & ~BPF_F_EGRESS))
++ if (unlikely(!bpf_net_ctx_get() || flags & ~BPF_F_EGRESS))
return TC_ACT_SHOT;
+ ri = bpf_net_ctx_get_ri();
- ri->flags = BPF_F_PEER;
+ ri->flags = BPF_F_PEER | flags;
ri->tgt_index = ifindex;
return TC_ACT_REDIRECT;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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