* linux-next: Tree for Jul 16
From: Mark Brown @ 2026-07-17 13:30 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
Hi all,
Changes since 20260715:
None.
Non-merge commits (relative to Linus' tree): 6313
6142 files changed, 255877 insertions(+), 101466 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
* Missing signoff in the iommufd tree
From: Mark Brown @ 2026-07-17 13:30 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
Commits
b737ad0b96a6e ("Documentation: Update VFIO NOIOMMU mode")
2406daf5fd3df ("vfio: Enable cdev noiommu mode under iommufd")
are missing a Signed-off-by from their committers
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the tty tree
From: Greg KH @ 2026-07-17 10:58 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Mark Brown, Praveen Talari, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <20260716040347.GA1744016@ax162>
On Thu, Jul 16, 2026 at 12:03:47AM -0400, Nathan Chancellor wrote:
> On Tue, Jul 14, 2026 at 11:26:02AM +0100, Mark Brown wrote:
> > On Tue, Jul 14, 2026 at 08:45:54AM +0200, Greg KH wrote:
> > > On Tue, Jul 14, 2026 at 11:36:44AM +0530, Praveen Talari wrote:
> >
> > > > I don't see these errors in my local build. Is there any specific way to
> > > > build to see these errors?
> >
> > > Nope, I can't duplicate this either on my side just by building this
> > > branch. Is this coming from a change somewhere else that modifies
> > > PM_RUNTIME_ACQUIRE_IF_ENABLED()?
> >
> > It's something clang reports.
>
> Right, this change is broken, as the cleanup function will be called
> with an uninitialized pointer on any of the 'goto error' paths before
> the PM_RUNTIME_ACQUIRE_IF_ENABLED(). This goes against the documentation
> in include/linux/cleanup.h:
>
> Lastly, given that the benefit of cleanup helpers is removal of
> “goto”, and that the “goto” statement can jump between scopes, the
> expectation is that usage of “goto” and cleanup helpers is never mixed
> in the same function. I.e. for a given routine, convert all resources
> that need a “goto” cleanup to scope-based cleanup, or convert none of
> them.
Ok, thanks, I'll go revert the offending commit now, sorry for the
delay.
greg k-h
^ permalink raw reply
* [STATUS] next/master - 1a1757b76427f6201bfe0bf1bea9f7574f332a93
From: KernelCI bot @ 2026-07-17 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/1a1757b76427f6201bfe0bf1bea9f7574f332a93/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 1a1757b76427f6201bfe0bf1bea9f7574f332a93
origin: maestro
test start time: 2026-07-16 16:02:07.983000+00:00
Builds: 72 ✅ 2 ❌ 0 ⚠️
Boots: 169 ✅ 3 ❌ 0 ⚠️
Tests: 30584 ✅ 5581 ❌ 5627 ⚠️
### POSSIBLE REGRESSIONS
Hardware: imx8mp-verdin-nonwifi-dahlia
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_bus_30800000_i2c_30a50000_eeprom_50
last run: https://d.kernelci.org/test/maestro:6a59531f3427a5b0fbe97cb3
history: > ✅ > ✅ > ✅ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a591f2d3427a5b0fbe5d0e2
history: > ✅ > ❌
- kselftest.arm64.arm64_hwcap_sigbus_LSE2
last run: https://d.kernelci.org/test/maestro:6a592bc23427a5b0fbe6947e
history: > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a5912dc3427a5b0fbe54308
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a591f3b3427a5b0fbe5d24f
history: > ❌ > ❌ > ✅
Hardware: cd8180-orion-o6
> Config: defconfig+netdev+nfs-root-boot+kselftest
- Architecture/compiler: arm64/gcc-15
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a5909fa3427a5b0fbe4fc71
history: > ❌ > ✅ > ✅
- ltp
last run: https://d.kernelci.org/test/maestro:6a5909fa3427a5b0fbe4fc68
history: > ❌ > ✅ > ✅
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa
last run: https://d.kernelci.org/test/maestro:6a591f693427a5b0fbe5fb2e
history: > ❌ > ❌ > ❌ > ❌ > ✅
- kselftest.alsa.alsa_pcm-test
last run: https://d.kernelci.org/test/maestro:6a597d803427a5b0fbeabdc5
history: > ❌ > ✅ > ✅ > ✅ > ✅
Hardware: qcs8300-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a5912fa3427a5b0fbe5448d
history: > ❌ > ✅
### UNSTABLE TESTS
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a800000_hub_2
last run: https://d.kernelci.org/test/maestro:6a5985173427a5b0fbeb7c67
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:6a5980ff3427a5b0fbeb32ab
history: > ❌ > ✅ > ✅ > ❌ > ✅
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_dma-controller0_14001000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec31
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_dsi_14014000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec2d
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_i2c_11008000_anx7625_58
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec25
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_i2c_11008000_anx7625_58_aux-bus_panel
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec24
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_14008000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec08
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_14009000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec07
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_1400a000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ec06
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_rdma_1400b000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ebfb
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_rdma_1400c000
last run: https://d.kernelci.org/test/maestro:6a5909a73427a5b0fbe4ebfa
history: > ❌ > ✅ > ❌ > ✅
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
* warnings from validate_blend_mode_for_alpha_formats() in next-20260715
From: Bert Karwatzki @ 2026-07-16 15:29 UTC (permalink / raw)
To: Alex Deucher
Cc: Bert Karwatzki, Leandro Ribeiro, linux-kernel, amd-gfx,
linux-next, Jesse Zhang, Amber Lin, Mario Limonciello
commit 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
introduces validate_blend_mode_for_alpha_formats() which prints warnings for amdpgu as
amdgpu only set blend_mode_property for planes of type DRM_PLANE_TYPE_OVERLAY. I tried to fix
this by removing he (plane->type == DRM_PLANE_TYPE_OVERLAY) check in amdgpu_dm_plane_init():
printk(KERN_INFO "%s: plane=%px plane->type=0x%x plane_cap=%px\n", __func__, plane, plane->type, plane_cap);
if (plane_cap)
printk(KERN_INFO "%s: per_pixel_alpha =%u\n", __func__, plane_cap->per_pixel_alpha);
if (plane_cap && plane_cap->per_pixel_alpha) {
unsigned int blend_caps = BIT(DRM_MODE_BLEND_PIXEL_NONE) |
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE);
printk(KERN_INFO "%s: creating alpha and blend mode properties for plane %px\n", __func__, plane);
drm_plane_create_alpha_property(plane);
drm_plane_create_blend_mode_property(plane, blend_caps);
}
But this does not completely silence the warnings becuase for planes of type DRM_PLANE_TYPE_CURSOR plane_cap is NULL.
Is this a problem that should be fixed in amdgpu or is should validate_blend_mode_for_alpha_formats() only be called
for planes of certain types?
Bert Karwatzki
^ permalink raw reply
* Re: linux-next: manual merge of the scsi-mkp tree with the origin tree
From: Mark Brown @ 2026-07-16 13:20 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Uwe Kleine-König, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <yq15x2f84ki.fsf@ca-mkp.ca.oracle.com>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Thu, Jul 16, 2026 at 09:09:14AM -0400, Martin K. Petersen wrote:
> > It's also got an arm64 allyesconfig build failure which is what's
> > keeping it out of -next, the submitter of the offending patch asked for
> > their patches to be dropped but I've seen no response from Martin.
> I've been traveling for a couple of days. Will resolve this later today.
Ah, excellent - thanks! That will also resolve the issue with the fixup
from Uwe so we should be good.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the scsi-mkp tree with the origin tree
From: Martin K. Petersen @ 2026-07-16 13:09 UTC (permalink / raw)
To: Mark Brown
Cc: Uwe Kleine-König, Martin K. Petersen,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <c3a949bf-4d78-402b-b474-db92f0613c6f@sirena.org.uk>
Mark,
> It's also got an arm64 allyesconfig build failure which is what's
> keeping it out of -next, the submitter of the offending patch asked for
> their patches to be dropped but I've seen no response from Martin.
I've been traveling for a couple of days. Will resolve this later today.
--
Martin K. Petersen
^ permalink raw reply
* Re: linux-next: manual merge of the scsi-mkp tree with the origin tree
From: Mark Brown @ 2026-07-16 13:03 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Martin K. Petersen, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <alirExca4fzB-fr8@monoceros>
[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]
On Thu, Jul 16, 2026 at 12:13:59PM +0200, Uwe Kleine-König wrote:
> So the fixup is applied to the merge of the scsi tree and not the
> scsi-mkp tree. The latter wasn't pulled into next-20260715 at all. Given
> that e73ba3d6ed03b isn't in next, the fixup shouldn't be there either.
> Looking at merge.log I see merging scsi-mkp is tried, the fixup is
> applied, yielding 0fd66dadace89 and then `git reset --hard HEAD^`
> follows throwing away that commit to replace it by
> next-20260714/scsi-mkp which is already included and thus the
> patches/device-id-zorro fixup is applied to the wrong commit.
Right, the fixups don't differentiate between versions of the tree and
the fact that scsi-mkp is broken and never had a version that was merged
this cycle means that the tooling gets confused about the fixup. We
need the fixup to try the build on the off chance that there's a fix,
but then it's not needed if the fix failed and since it's not dependent
on any context added by the merge it doesn't get skipped.
> Having said that e73ba3d6ed03b is still in
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
> without the patch preparing drivers/ata/pata_buddha.c for that change
> and thus resulting in a build failure on m68k.
It's also got an arm64 allyesconfig build failure which is what's
keeping it out of -next, the submitter of the offending patch asked for
their patches to be dropped but I've seen no response from Martin.
Hopefully at some point the various build failures will be addressed and
this will all get sorted.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [linux-next:master] [loop] d908729e74: stress-ng.umount.ops_per_sec 100.0% regression
From: Mark Brown @ 2026-07-16 12:16 UTC (permalink / raw)
To: Christoph Hellwig, Tetsuo Handa
Cc: kernel test robot, oe-lkp, lkp, linux-block, linux-fsdevel,
linux-next, axboe, Paul Moore, James Morris, Serge E. Hallyn
In-Reply-To: <c625eb50-e474-4966-bf3b-e83d7e7d1750@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]
On Wed, Jul 15, 2026 at 03:57:22PM +0100, Mark Brown wrote:
> On Wed, Jul 15, 2026 at 07:30:02AM -0700, Christoph Hellwig wrote:
> point where I think I have to do as Christoph suggests. Looking at the
> current contents of the tomoyo tree all I see is:
> Tetsuo Handa (6):
> lib/Kconfig.debug: add CONFIG_DEBUG_AID_FOR_SYZBOT option
> net: update dev_put()/dev_hold() debugging
> net: add "struct dst_entry" debugging
> loop: Fix NULL pointer dereference in lo_rw_aio()
> kcov: fix data corruption and race conditions on PREEMPT_RT by moving saved remote state to task_struct
> apparmor: temporarily disable in syzbot kernels.
> Absolutely none of which are obviously on topic for the tomoyo tree and
> some of which are patches that people have previously raised concerns
> with. This is very disappointing to see. I will check the status again
> tomorrow but as things stand I think I need to drop the tomoyo
> tree from -next.
Looking today I see that all these patches were dropped from the tree so
I've left tomoyo in place, thanks for taking care of this Tetsuo.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the scsi-mkp tree with the origin tree
From: Uwe Kleine-König @ 2026-07-16 10:13 UTC (permalink / raw)
To: Mark Brown
Cc: Martin K. Petersen, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <alUAlBfA42zAOZ3c@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3701 bytes --]
Hello Mark,
On Mon, Jul 13, 2026 at 04:13:24PM +0100, Mark Brown wrote:
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> include/linux/mod_devicetable.h
>
> between commit:
>
> ad428f5811bd7 ("mod_devicetable.h: Split into per subsystem headers")
>
> from the origin tree and commit:
>
> e73ba3d6ed03b ("scsi: zorro: Simplify storing pointers in device id struct")
>
> from the scsi-mkp 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 include/linux/mod_devicetable.h
> index a397213bedace,2673a1bd82c45..0000000000000
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> diff --git a/include/linux/device-id/zorro.h b/include/linux/device-id/zorro.h
> index 5fdac81689839..26827b9b90b67 100644
> --- a/include/linux/device-id/zorro.h
> +++ b/include/linux/device-id/zorro.h
> @@ -13,7 +13,11 @@ typedef unsigned long kernel_ulong_t;
>
> struct zorro_device_id {
> __u32 id; /* Device ID or ZORRO_WILDCARD */
> - kernel_ulong_t driver_data; /* Data private to the driver */
> + union {
> + /* Data private to the driver */
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
While this looks right, I think it's wrong in git:
$ git show next-20260715~32
commit b36e50419ebc00bef45b574c6ce3e7edbbda5eb9
Merge: 20361c12febf cf1af0ccca54
Author: Mark Brown <broonie@kernel.org>
Date: Wed Jul 15 14:23:48 2026 +0100
Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
diff --cc include/linux/device-id/zorro.h
index 5fdac8168983,000000000000..26827b9b90b6
mode 100644,000000..100644
--- a/include/linux/device-id/zorro.h
+++ b/include/linux/device-id/zorro.h
@@@ -1,19 -1,0 +1,23 @@@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef LINUX_DEVICE_ID_ZORRO_H
+#define LINUX_DEVICE_ID_ZORRO_H
+
+#ifdef __KERNEL__
+#include <linux/types.h>
+typedef unsigned long kernel_ulong_t;
+#endif
+
+#define ZORRO_WILDCARD (0xffffffff) /* not official */
+
+#define ZORRO_DEVICE_MODALIAS_FMT "zorro:i%08X"
+
+struct zorro_device_id {
+ __u32 id; /* Device ID or ZORRO_WILDCARD */
- kernel_ulong_t driver_data; /* Data private to the driver */
++ union {
++ /* Data private to the driver */
++ kernel_ulong_t driver_data;
++ const void *driver_data_ptr;
++ };
+};
+
+#endif /* ifndef LINUX_DEVICE_ID_ZORRO_H */
So the fixup is applied to the merge of the scsi tree and not the
scsi-mkp tree. The latter wasn't pulled into next-20260715 at all. Given
that e73ba3d6ed03b isn't in next, the fixup shouldn't be there either.
Looking at merge.log I see merging scsi-mkp is tried, the fixup is
applied, yielding 0fd66dadace89 and then `git reset --hard HEAD^`
follows throwing away that commit to replace it by
next-20260714/scsi-mkp which is already included and thus the
patches/device-id-zorro fixup is applied to the wrong commit.
Having said that e73ba3d6ed03b is still in
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next
without the patch preparing drivers/ata/pata_buddha.c for that change
and thus resulting in a build failure on m68k.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the tty tree
From: Nathan Chancellor @ 2026-07-16 4:03 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Praveen Talari, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <7fc86c5f-289c-4b77-b3f8-98dc30d89c28@sirena.org.uk>
On Tue, Jul 14, 2026 at 11:26:02AM +0100, Mark Brown wrote:
> On Tue, Jul 14, 2026 at 08:45:54AM +0200, Greg KH wrote:
> > On Tue, Jul 14, 2026 at 11:36:44AM +0530, Praveen Talari wrote:
>
> > > I don't see these errors in my local build. Is there any specific way to
> > > build to see these errors?
>
> > Nope, I can't duplicate this either on my side just by building this
> > branch. Is this coming from a change somewhere else that modifies
> > PM_RUNTIME_ACQUIRE_IF_ENABLED()?
>
> It's something clang reports.
Right, this change is broken, as the cleanup function will be called
with an uninitialized pointer on any of the 'goto error' paths before
the PM_RUNTIME_ACQUIRE_IF_ENABLED(). This goes against the documentation
in include/linux/cleanup.h:
Lastly, given that the benefit of cleanup helpers is removal of
“goto”, and that the “goto” statement can jump between scopes, the
expectation is that usage of “goto” and cleanup helpers is never mixed
in the same function. I.e. for a given routine, convert all resources
that need a “goto” cleanup to scope-based cleanup, or convert none of
them.
--
Cheers,
Nathan
^ permalink raw reply
* Re: Missing signoff in the realtek tree
From: Yu-Chun Lin @ 2026-07-16 2:48 UTC (permalink / raw)
To: broonie; +Cc: eleanor.lin, james.tai, linux-kernel, linux-next
In-Reply-To: <aldqwEDCi6Ae9qOn@sirena.org.uk>
> [-- Attachment #1: Type: text/plain, Size: 128 bytes --]
>
> Commit
>
> 18a9dade373ef ("arm64: dts: realtek: Add EL2 virtual timer interrupt")
>
> is missing a Signed-off-by from its committer
>
> [-- Attachment #2: signature.asc --]
> [-- Type: application/pgp-signature, Size: 488 bytes --]
Sorry about that.
I've added SoB to the commit and pushed the update.
Best Regards,
Yu-Chun
^ permalink raw reply
* [STATUS] next/master - b8809969e1d7a591e0f49dd464a5d04b3cf02ab1
From: KernelCI bot @ 2026-07-16 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/b8809969e1d7a591e0f49dd464a5d04b3cf02ab1/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: b8809969e1d7a591e0f49dd464a5d04b3cf02ab1
origin: maestro
test start time: 2026-07-15 15:43:28.290000+00:00
Builds: 72 ✅ 2 ❌ 0 ⚠️
Boots: 163 ✅ 3 ❌ 0 ⚠️
Tests: 27829 ✅ 5184 ❌ 4978 ⚠️
### POSSIBLE REGRESSIONS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.shardfile-kvm
last run: https://d.kernelci.org/test/maestro:6a57bd6318a4add1354c2218
history: > ✅ > ❌ > ❌ > ❌
Hardware: k3-am625-verdin-wifi-mallow
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.shardfile-kvm
last run: https://d.kernelci.org/test/maestro:6a57b78e18a4add1354bd381
history: > ✅ > ❌ > ❌ > ❌
Hardware: sun50i-a64-pine64-plus
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.shardfile-kvm
last run: https://d.kernelci.org/test/maestro:6a57b67418a4add1354b983f
history: > ✅ > ❌ > ❌ > ❌
Hardware: sc7180-trogdor-kingoftown
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_4080000
last run: https://d.kernelci.org/test/maestro:6a57b64918a4add1354b912e
history: > ✅ > ❌ > ❌ > ❌
### FIXED REGRESSIONS
Hardware: bcm2837-rpi-3-b-plus
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device_error_logs
last run: https://d.kernelci.org/test/maestro:6a57bc4a18a4add1354c157d
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.device_error_logs.devices_error_logs_test_device_error_logs_py
last run: https://d.kernelci.org/test/maestro:6a57c0bc18a4add1354c5672
history: > ❌ > ✅ > ✅ > ✅ > ✅
Hardware: cd8180-orion-o6
> Config: defconfig+netdev+nfs-root-boot+kselftest
- Architecture/compiler: arm64/gcc-15
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a57b61318a4add1354b9008
history: > ❌ > ✅
- ltp
last run: https://d.kernelci.org/test/maestro:6a57b61218a4add1354b8fff
history: > ❌ > ✅
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a57bd5118a4add1354c1b84
history: > ❌ > ✅ > ✅ > ✅ > ✅
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a57bd5118a4add1354c1b92
history: > ❌ > ✅ > ✅ > ✅ > ✅
### UNSTABLE TESTS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_pcm-test
last run: https://d.kernelci.org/test/maestro:6a57bd5018a4add1354c198c
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_sound-wm8960
last run: https://d.kernelci.org/test/maestro:6a57bfdb18a4add1354c4e9e
history: > ✅ > ❌ > ✅ > ✅ > ❌
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_dma-controller0_14001000
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd12f
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_dsi_14014000
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd12b
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_i2c_11008000_anx7625_58
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd123
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_i2c_11008000_anx7625_58_aux-bus_panel
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd122
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_14008000
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd106
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_14009000
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd105
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_1400a000
last run: https://d.kernelci.org/test/maestro:6a57b74118a4add1354bd104
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_rdma_1400b000
last run: https://d.kernelci.org/test/maestro:6a57b74018a4add1354bd0f9
history: > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_rdma_1400c000
last run: https://d.kernelci.org/test/maestro:6a57b74018a4add1354bd0f8
history: > ✅ > ❌ > ✅ > ❌
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
* [PATCH v5] loop: Fix NULL pointer dereference in lo_rw_aio()
From: Tetsuo Handa @ 2026-07-16 0:05 UTC (permalink / raw)
To: Jens Axboe, Bart Van Assche, Damien Le Moal, Al Viro
Cc: Christoph Hellwig, linux-block, LKML, Linus Torvalds, linux-btrfs,
linux-fsdevel, Christian Brauner, Christoph Hellwig, Mark Brown,
Linux-Next Mailing List, oe-lkp, kernel test robot,
kbuild test robot, Hillf Danton
In-Reply-To: <20260714043834.554-1-hdanton@sina.com>
syzbot is reporting NULL pointer dereference in lo_rw_aio() [1][2].
An analysis by the Gemini AI collaborator [3] considers that this problem
is caused by a timing shift primarily exposed by commit 65565ca5f99b
("block: unify the synchronous bi_end_io callbacks"), along with helper
refactorings like commit 92c3737a2473 ("block: add a bio_submit_or_kill
helper").
But due to difficulty of reproducing this race, discussion about what is
happening and how to fix this problem is stalling. Also, we haven't
identified how many filesystems are subjected to this problem.
Therefore, this patch introduces a grace period for flushing pending I/O
requests (which should be a good thing from the perspective of defensive
programming) so that we won't hit NULL pointer dereference problem, and
also emits BUG: message in order to help filesystem developers identify
the caller of an I/O request that failed to wait for completion so that
filesystem developers can fix such caller to wait for completion.
Note that emitting BUG: message is enabled only if CONFIG_KCOV=y, for
this check is a waste of computation resources for almost all users.
Link: https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28 [1]
Link: https://syzkaller.appspot.com/bug?extid=bc273027d5643e48e5b3 [2]
Link: https://lkml.kernel.org/r/fbb3edda-f108-4e5b-acf2-266f043f8125@I-love.SAKURA.ne.jp [3]
Fixes: 65565ca5f99b ("block: unify the synchronous bi_end_io callbacks")
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
syzbot has tested this patch (with debug printk() added) using linux-next,
and I confirmed that this patch does not cause new problems for syzbot.
I was expecting that Al Viro can reproduce xfs/259 problem with debug printk(),
but I have to remove this patch (with debug printk() added) from linux-next
because the debug printk() causes performance problem for unmount stress tests
( https://lkml.kernel.org/r/202607151655.9d74999d-lkp@intel.com ).
Anyway, like I have explained in
https://lkml.kernel.org/r/9f8b5ab0-efbc-4cf3-a1f8-b43377416946@I-love.SAKURA.ne.jp ,
I think that the xfs/259 problem should be addressed by updating the "umount" user,
for the "target is busy" problem can be reproduced with 7.0 and 7.1 kernels if
delay injection is used.
Therefore, I think that we should proceed to the next step; i.e. identify
who is issuing I/O requests too late and fix such users. But I had to stop
testing this patch using linux-next before syzbot succeeds to find such users.
We can't use "#syz test" because this problem has no reproducers. Since I can
no longer continue floating debug printk() for this problem, sending this patch
to upstream will become the only way to identify who is issuing I/O requests
too late.
drivers/block/loop.c | 83 ++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 310de0463beb..c3b607a3ddc4 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -85,8 +85,27 @@ struct loop_cmd {
struct bio_vec *bvec;
struct cgroup_subsys_state *blkcg_css;
struct cgroup_subsys_state *memcg_css;
+#ifdef CONFIG_KCOV
+ unsigned long stack_entries[30];
+ int stack_nr;
+ pid_t pid;
+ char comm[TASK_COMM_LEN];
+#endif
};
+static void loop_check_io_race(struct loop_device *lo, struct loop_cmd *cmd)
+{
+#ifdef CONFIG_KCOV
+ if (unlikely(data_race(READ_ONCE(lo->lo_state)) == Lo_rundown &&
+ disk_openers(lo->lo_disk) == 0)) {
+ pr_err("BUG: %s/%u is doing I/O request on loop%d in Lo_rundown state.\n",
+ cmd->comm, cmd->pid, lo->lo_number);
+ printk("Call Trace:\n");
+ stack_trace_print(cmd->stack_entries, cmd->stack_nr, 4);
+ }
+#endif
+}
+
#define LOOP_IDLE_WORKER_TIMEOUT (60 * HZ)
#define LOOP_DEFAULT_HW_Q_DEPTH 128
@@ -1743,8 +1762,59 @@ static void lo_release(struct gendisk *disk)
need_clear = (lo->lo_state == Lo_rundown);
mutex_unlock(&lo->lo_mutex);
- if (need_clear)
+ if (need_clear) {
+ /*
+ * Temporarily release disk->open_mutex in order to flush pending I/O
+ * requests before clearing the backing device.
+ *
+ * This is a layering violation. But since bdev->bd_disk->fops->release()
+ * (which is mapped to lo_release()) is the final function which
+ * blkdev_put_whole() from bdev_release() calls immediately before
+ * releasing disk->open_mutex, this changes nothing except opens a new
+ * race window for allowing disk->fops->open() (which is mapped to
+ * lo_open()) to be called.
+ *
+ * Even if lo_open() is called from blkdev_get_whole() due to this race,
+ * the Lo_rundown state guarantees that lo_open() will fail with -ENXIO.
+ * Thus, there will be effectively no change caused by this violation.
+ */
+ mutex_unlock(&lo->lo_disk->open_mutex);
+ /*
+ * Now that loop_queue_rq() sees lo->lo_state != Lo_bound,
+ * wait for already started loop_queue_rq() to complete.
+ */
+ synchronize_rcu();
+ /*
+ * Now that no more works are scheduled by loop_queue_rq(),
+ * wait for already scheduled works to complete.
+ */
+ drain_workqueue(lo->workqueue);
+ /*
+ * Now that no more AIO requests are scheduled by lo_rw_aio(),
+ * wait for already started AIO to complete.
+ *
+ * Due to synchronize_rcu() + drain_workqueue() sequence above,
+ * calling blk_mq_unfreeze_queue() immediately after blk_mq_freeze_queue()
+ * returns has to be safe, for loop_queue_rq() no longer schedules new
+ * lo_rw_aio() works and lo_rw_aio() no longer submits new AIO requests.
+ *
+ * Deferring blk_mq_unfreeze_queue() does not help because we are about
+ * to clear the backing device and drop the refcount for the backing device.
+ * There is nothing we can do if blk_mq_freeze_queue() fails to flush.
+ */
+ blk_mq_unfreeze_queue(lo->lo_queue, blk_mq_freeze_queue(lo->lo_queue));
+ /*
+ * Perform remaining cleanup, with disk->open_mutex held.
+ *
+ * The lo->lo_state should remain Lo_rundown despite we temporarily
+ * released disk->open_mutex, for I am the only and the last user of
+ * this loop device because lo_open() cannot succeed.
+ */
+ mutex_lock(&lo->lo_disk->open_mutex);
+ if (WARN_ON(data_race(READ_ONCE(lo->lo_state)) != Lo_rundown))
+ return;
__loop_clr_fd(lo);
+ }
}
static void lo_free_disk(struct gendisk *disk)
@@ -1851,10 +1921,18 @@ static blk_status_t loop_queue_rq(struct blk_mq_hw_ctx *hctx,
struct loop_cmd *cmd = blk_mq_rq_to_pdu(rq);
struct loop_device *lo = rq->q->queuedata;
+#ifdef CONFIG_KCOV
+ cmd->stack_nr = stack_trace_save(cmd->stack_entries, ARRAY_SIZE(cmd->stack_entries), 0);
+ cmd->pid = current->pid;
+ get_task_comm(cmd->comm, current);
+#endif
+
blk_mq_start_request(rq);
- if (data_race(READ_ONCE(lo->lo_state)) != Lo_bound)
+ if (data_race(READ_ONCE(lo->lo_state)) != Lo_bound) {
+ loop_check_io_race(lo, cmd);
return BLK_STS_IOERR;
+ }
switch (req_op(rq)) {
case REQ_OP_FLUSH:
@@ -1897,6 +1975,7 @@ static void loop_handle_cmd(struct loop_cmd *cmd)
int ret = 0;
struct mem_cgroup *old_memcg = NULL;
+ loop_check_io_race(lo, cmd);
if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY)) {
ret = -EIO;
goto failed;
--
2.52.0
^ permalink raw reply related
* Re: Missing signoff in the ntfs3 tree
From: Mark Brown @ 2026-07-15 17:10 UTC (permalink / raw)
To: Konstantin Komarov; +Cc: linux-kernel, linux-next
In-Reply-To: <50304fd4-d8af-424c-ae8d-efe31e77c76b@paragon-software.com>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Wed, Jul 15, 2026 at 06:54:21PM +0200, Konstantin Komarov wrote:
> On 7/15/26 13:08, Mark Brown wrote:
> > f023839df8010 ("fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init")
> > is missing a Signed-off-by from its author
> What do you mean by "missing a Signed-off-by from its author"?
> It's signed off here - "Signed-off-by: Weiming Shi <bestswngs@gmail.com>".
> Or did I not include another author of the patch?
We have
Author: Weiming Wu <weiming3@asu.edu>
but
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Neither name nor email is the same (git show --pretty=fuller), if it's
the same person tooling isn't going to be able to figure that out.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Missing signoff in the ntfs3 tree
From: Konstantin Komarov @ 2026-07-15 16:54 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel, linux-next
In-Reply-To: <aldqIGRdMoJgNkER@sirena.org.uk>
On 7/15/26 13:08, Mark Brown wrote:
> Commit
>
> f023839df8010 ("fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init")
>
> is missing a Signed-off-by from its author
What do you mean by "missing a Signed-off-by from its author"?
It's signed off here - "Signed-off-by: Weiming Shi <bestswngs@gmail.com>".
Or did I not include another author of the patch?
Regards,
Konstantin
^ permalink raw reply
* Re: linux-next: manual merge of the jc_docs tree with the mm-unstable tree
From: Jonathan Corbet @ 2026-07-15 16:53 UTC (permalink / raw)
To: Andrew Morton, Mark Brown
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Manuel Ebner,
Stanislav Kinsburskii
In-Reply-To: <20260715092029.18a9334f73e3b1517f3d47b3@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Wed, 15 Jul 2026 16:40:19 +0100 Mark Brown <broonie@kernel.org> wrote:
>
>> Hi all,
>>
>> Today's linux-next merge of the jc_docs tree got a conflict in:
>>
>> Documentation/mm/hmm.rst
>>
>> between commits:
>>
>> 3862d3b51eb1f ("mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support")
>> 94e4afa33bac3 ("mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix")
>>
>> from the mm-unstable tree and commit:
>>
>> e834ee8e571d5 ("docs/mm: Fix braces")
>>
>> from the jc_docs 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.
>
> There was no "see below".
>
> Jon, that little patch is being a problem. Maybe drop it and I can fix
> it up and carry it in mm.git?
OK, I've dropped it, it's all yours.
jon
^ permalink raw reply
* Re: linux-next: manual merge of the jc_docs tree with the mm-unstable tree
From: Mark Brown @ 2026-07-15 16:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Jonathan Corbet, Linux Kernel Mailing List,
Linux Next Mailing List, Manuel Ebner, Stanislav Kinsburskii
In-Reply-To: <20260715092029.18a9334f73e3b1517f3d47b3@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Wed, Jul 15, 2026 at 09:20:29AM -0700, Andrew Morton wrote:
> On Wed, 15 Jul 2026 16:40:19 +0100 Mark Brown <broonie@kernel.org> wrote:
> > 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.
> There was no "see below".
It was a noop resolution (just take your copy) so didn't generate a diff
and I forgot to do a diff -c instead, sorry.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the jc_docs tree with the mm-unstable tree
From: Andrew Morton @ 2026-07-15 16:20 UTC (permalink / raw)
To: Mark Brown
Cc: Jonathan Corbet, Linux Kernel Mailing List,
Linux Next Mailing List, Manuel Ebner, Stanislav Kinsburskii
In-Reply-To: <alep4zhJYFTXqBe9@sirena.org.uk>
On Wed, 15 Jul 2026 16:40:19 +0100 Mark Brown <broonie@kernel.org> wrote:
> Hi all,
>
> Today's linux-next merge of the jc_docs tree got a conflict in:
>
> Documentation/mm/hmm.rst
>
> between commits:
>
> 3862d3b51eb1f ("mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support")
> 94e4afa33bac3 ("mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix")
>
> from the mm-unstable tree and commit:
>
> e834ee8e571d5 ("docs/mm: Fix braces")
>
> from the jc_docs 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.
There was no "see below".
Jon, that little patch is being a problem. Maybe drop it and I can fix
it up and carry it in mm.git?
^ permalink raw reply
* Re: [linux-next:master] [loop] d908729e74: stress-ng.umount.ops_per_sec 100.0% regression
From: Mark Brown @ 2026-07-15 16:02 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Christoph Hellwig, kernel test robot, oe-lkp, lkp, linux-block,
linux-fsdevel, linux-next, axboe
In-Reply-To: <4ea4703c-7385-4f75-aee2-f21a6c8cce82@I-love.SAKURA.ne.jp>
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
On Wed, Jul 15, 2026 at 11:45:41PM +0900, Tetsuo Handa wrote:
> Then, can we please keep discussion on
> https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28 alive?
> I am asking Al Viro to reproduce xfs/259 problem, but it seems that
> Al is too busy to respond. I can drop this patch if somebody is
> interested in fixing this bug which became visible in 7.1. Current
> state is a result of insufficient interests/resources for debugging.
I would recommend a combination of having more patience and, if things
really do seem stuck (eg, after several reasonably spaced resends)
copying in Andrew Morton on any patches for other subsystems. If the
other tree is pulled by someone else on it's way to Linus then whoever
pulls it might also be worth copying. Andrew generally picks up patches
that are for things that don't have an obvious route to mainline or are
getting dropped on the floor for some reason.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 15
From: Mark Brown @ 2026-07-15 15:40 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
Hi all,
Changes since 20260714:
The realtek tree was added.
The jc_docs tree acquired a conflict with the mm-unstable tree.
Non-merge commits (relative to Linus' tree): 6058
5833 files changed, 245746 insertions(+), 96566 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
* linux-next: manual merge of the jc_docs tree with the mm-unstable tree
From: Mark Brown @ 2026-07-15 15:40 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List,
Manuel Ebner, Stanislav Kinsburskii
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
Hi all,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/mm/hmm.rst
between commits:
3862d3b51eb1f ("mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support")
94e4afa33bac3 ("mm-hmm-add-hmm_range_fault_unlocked_timeout-for-mmap-lock-drop-support-fix")
from the mm-unstable tree and commit:
e834ee8e571d5 ("docs/mm: Fix braces")
from the jc_docs 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: build failure in the final build
From: Mark Brown @ 2026-07-15 15:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, Johan Hovold
Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <alUk8OTfE-f9oQo8@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 4985 bytes --]
On Mon, Jul 13, 2026 at 06:48:32PM +0100, Mark Brown wrote:
> Hi all,
>
> In the final builds, today's linux-next build (arm64 allyesconfig)
> failed like this:
This error is due to a71f5aef1be98 (USB: gadget: fsl-udc: enable compile
testing) from the usb tree, a dependency change as expected. I'll do
something about this tomorrow.
>
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:105:5: error: no previous
> prototype for 'write_ulpi' [-Werror=missing-prototypes]
> 105 | int write_ulpi(u8 addr, u8 data)
> | ^~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:118:6: error: no previous
> prototype for 'fsl_otg_chrg_vbus' [-Werror=missing-prototypes]
> 118 | void fsl_otg_chrg_vbus(struct otg_fsm *fsm, int on)
> | ^~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:136:6: error: no previous
> prototype for 'fsl_otg_dischrg_vbus' [-Werror=missing-prototypes]
> 136 | void fsl_otg_dischrg_vbus(int on)
> | ^~~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:154:6: error: no previous
> prototype for 'fsl_otg_drv_vbus' [-Werror=missing-prototypes]
> 154 | void fsl_otg_drv_vbus(struct otg_fsm *fsm, int on)
> | ^~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:172:6: error: no previous
> prototype for 'fsl_otg_loc_conn' [-Werror=missing-prototypes]
> 172 | void fsl_otg_loc_conn(struct otg_fsm *fsm, int on)
> | ^~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:191:6: error: no previous
> prototype for 'fsl_otg_loc_sof' [-Werror=missing-prototypes]
> 191 | void fsl_otg_loc_sof(struct otg_fsm *fsm, int on)
> | ^~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:206:6: error: no previous
> prototype for 'fsl_otg_start_pulse' [-Werror=missing-prototypes]
> 206 | void fsl_otg_start_pulse(struct otg_fsm *fsm)
> | ^~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:222:6: error: no previous
> prototype for 'b_data_pulse_end' [-Werror=missing-prototypes]
> 222 | void b_data_pulse_end(unsigned long foo)
> | ^~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:241:6: error: no previous
> prototype for 'b_vbus_pulse_end' [-Werror=missing-prototypes]
> 241 | void b_vbus_pulse_end(unsigned long foo)
> | ^~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:254:6: error: no previous
> prototype for 'b_srp_end' [-Werror=missing-prototypes]
> 254 | void b_srp_end(unsigned long foo)
> | ^~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:269:6: error: no previous
> prototype for 'a_wait_enum' [-Werror=missing-prototypes]
> 269 | void a_wait_enum(unsigned long foo)
> | ^~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:279:6: error: no previous
> prototype for 'set_tmout' [-Werror=missing-prototypes]
> 279 | void set_tmout(unsigned long indicator)
> | ^~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:285:5: error: no previous
> prototype for 'fsl_otg_init_timers' [-Werror=missing-prototypes]
> 285 | int fsl_otg_init_timers(struct otg_fsm *fsm)
> | ^~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:342:6: error: no previous
> prototype for 'fsl_otg_uninit_timers' [-Werror=missing-prototypes]
> 342 | void fsl_otg_uninit_timers(void)
> | ^~~~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:446:6: error: no previous
> prototype for 'otg_reset_controller' [-Werror=missing-prototypes]
> 446 | void otg_reset_controller(void)
> | ^~~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:458:5: error: no previous
> prototype for 'fsl_otg_start_host' [-Werror=missing-prototypes]
> 458 | int fsl_otg_start_host(struct otg_fsm *fsm, int on)
> | ^~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:525:5: error: no previous
> prototype for 'fsl_otg_start_gadget' [-Werror=missing-prototypes]
> 525 | int fsl_otg_start_gadget(struct otg_fsm *fsm, int on)
> | ^~~~~~~~~~~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:707:13: error: no previous
> prototype for 'fsl_otg_isr' [-Werror=missing-prototypes]
> 707 | irqreturn_t fsl_otg_isr(int irq, void *dev_id)
> | ^~~~~~~~~~~
> /tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:833:5: error: no previous
> prototype for 'usb_otg_start' [-Werror=missing-prototypes]
> 833 | int usb_otg_start(struct platform_device *pdev)
> | ^~~~~~~~~~~~~
> cc1: all warnings being treated as errors make[6]:
>
> It looks like this is a change in dependencies which has allowed this to
> be built from today, I didn't isolate exactly what - it looks like the
> issue is missing statics on all these function definitions, making them
> global. I have ignored this for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [linux-next:master] [loop] d908729e74: stress-ng.umount.ops_per_sec 100.0% regression
From: Mark Brown @ 2026-07-15 14:57 UTC (permalink / raw)
To: Christoph Hellwig, Tetsuo Handa
Cc: kernel test robot, oe-lkp, lkp, linux-block, linux-fsdevel,
linux-next, axboe, Paul Moore, James Morris, Serge E. Hallyn
In-Reply-To: <aleZammRRSVN4dl0@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
On Wed, Jul 15, 2026 at 07:30:02AM -0700, Christoph Hellwig wrote:
[Adding security maintainers for visibility.]
> It's also a patch that has never been added to the maintainer
> tree for goot reson. Tetsuo keeps doing this, so can we please
> stop including their trees in linux-next as there seems to be
> no other way to stop this?
Tetsuo, there was a discusion about this in the past month which seemed
to result in an agreement that you'd stop doing this and work more
closely with maintainers. What's the story here? It is getting to the
point where I think I have to do as Christoph suggests. Looking at the
current contents of the tomoyo tree all I see is:
Tetsuo Handa (6):
lib/Kconfig.debug: add CONFIG_DEBUG_AID_FOR_SYZBOT option
net: update dev_put()/dev_hold() debugging
net: add "struct dst_entry" debugging
loop: Fix NULL pointer dereference in lo_rw_aio()
kcov: fix data corruption and race conditions on PREEMPT_RT by moving saved remote state to task_struct
apparmor: temporarily disable in syzbot kernels.
Absolutely none of which are obviously on topic for the tomoyo tree and
some of which are patches that people have previously raised concerns
with. This is very disappointing to see. I will check the status again
tomorrow but as things stand I think I need to drop the tomoyo
tree from -next.
To repeat the conclusion of the previous discussion you need to be
coordinating with the maintainers of other trees when adding changes for
their trees, and nobody should be adding changes not inteded for the
next merge window during the normal course of affairs.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [linux-next:master] [loop] d908729e74: stress-ng.umount.ops_per_sec 100.0% regression
From: Christoph Hellwig @ 2026-07-15 14:53 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Christoph Hellwig, kernel test robot, oe-lkp, lkp, linux-block,
linux-fsdevel, Mark Brown, linux-next, axboe
In-Reply-To: <4ea4703c-7385-4f75-aee2-f21a6c8cce82@I-love.SAKURA.ne.jp>
On Wed, Jul 15, 2026 at 11:45:41PM +0900, Tetsuo Handa wrote:
> On 2026/07/15 23:30, Christoph Hellwig wrote:
> > It's also a patch that has never been added to the maintainer
> > tree for goot reson. Tetsuo keeps doing this, so can we please
> > stop including their trees in linux-next as there seems to be
> > no other way to stop this?
>
> Then, can we please keep discussion on
> https://syzkaller.appspot.com/bug?extid=cd8a9a308e879a4e2c28 alive?
> I am asking Al Viro to reproduce xfs/259 problem, but it seems that
> Al is too busy to respond. I can drop this patch if somebody is
> interested in fixing this bug which became visible in 7.1. Current
> state is a result of insufficient interests/resources for debugging.
Not my business. But adding random patches affecting other subsystems
without any buy in is a no-go. Doing this repeatedly after beeing
reminded not to do it and for multiple subsystems is a red flag.
^ 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