* [STATUS] next/master - c425609d6ac4012c8bbf01ec2e10e801b1923a7b
From: KernelCI bot @ 2026-06-13 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/c425609d6ac4012c8bbf01ec2e10e801b1923a7b/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: c425609d6ac4012c8bbf01ec2e10e801b1923a7b
origin: maestro
test start time: 2026-06-12 19:04:01.109000+00:00
Builds: 57 ✅ 1 ❌ 0 ⚠️
Boots: 168 ✅ 6 ❌ 5 ⚠️
Tests: 28180 ✅ 4684 ❌ 5623 ⚠️
### POSSIBLE REGRESSIONS
Hardware: glymur-crd
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2c63ccdabb8c619d54d802
history: > ✅ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2c640ddabb8c619d54dcc8
history: > ✅ > ✅ > ❌ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2c63d3dabb8c619d54d846
history: > ✅ > ✅ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2c6414dabb8c619d54dcec
history: > ✅ > ✅ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a2c637fdabb8c619d54d414
history: > ✅ > ✅ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2c6411dabb8c619d54dcde
history: > ✅ > ✅ > ❌ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2c63d2dabb8c619d54d841
history: > ✅ > ✅ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2c6413dabb8c619d54dce8
history: > ✅ > ✅ > ❌ > ❌
Hardware: x1e80100
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2c63d6dabb8c619d54d853
history: > ✅ > ✅ > ✅ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2c6417dabb8c619d54dd00
history: > ✅ > ✅ > ✅ > ❌ > ❌
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt
last run: https://d.kernelci.org/test/maestro:6a2c6408dabb8c619d54dcaa
history: > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh
last run: https://d.kernelci.org/test/maestro:6a2c68bedabb8c619d55466f
history: > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_gpu
last run: https://d.kernelci.org/test/maestro:6a2c68bedabb8c619d5546a3
history: > ✅ > ✅ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a2c638adabb8c619d54d4d5
history: > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2c6410dabb8c619d54dcd5
history: > ✅ > ✅ > ❌ > ❌
### FIXED REGRESSIONS
Hardware: cd8180-orion-o6
> Config: defconfig+netdev+nfs-root-boot+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a2c85a7dabb8c619d571043
history: > ❌ > ✅ > ✅ > ✅ > ✅
Hardware: asus-CX3402CVA-brya
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- kernelci_sleep
last run: https://d.kernelci.org/test/maestro:6a2c6086dabb8c619d5461c7
history: > ❌ > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-1
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549604
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-10
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d5495f8
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-2
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549606
history: > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-3
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549608
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-4
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549602
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-5
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d54960c
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-6
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549600
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-7
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d5495fe
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-8
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d5495fa
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-freeze-9
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d5495fc
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-1
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d54961e
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-10
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d54960a
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-2
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d54961c
history: > ❌ > ✅
- kernelci_sleep.rtcwake-mem-3
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d54961a
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-4
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549616
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-5
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549618
history: > ❌ > ✅
- kernelci_sleep.rtcwake-mem-6
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549612
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-7
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d54960e
history: > ❌ > ✅
- kernelci_sleep.rtcwake-mem-8
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549614
history: > ❌ > ❌ > ✅
- kernelci_sleep.rtcwake-mem-9
last run: https://d.kernelci.org/test/maestro:6a2c61cedabb8c619d549610
history: > ❌ > ❌ > ✅
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2c63bfdabb8c619d54d791
history: > ✅ > ✅ > ⚠️ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2c6b75dabb8c619d558c18
history: > ⚠️ > ✅ > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2c6b76dabb8c619d558c1b
history: > ✅ > ⚠️ > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2c6082dabb8c619d546196
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
* Re: [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge
From: Jakub Kicinski @ 2026-06-13 0:44 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Breno Leitao, Allison Henderson, linux-kernel, netdev, linux-rdma,
rds-devel, linux-kselftest, kernel-team, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Shuah Khan, Andy Grover,
Mark Brown, Linux Next Mailing List
In-Reply-To: <b91ff67e-ce74-4edf-a8b0-08be04586485@kernel.org>
On Fri, 12 Jun 2026 13:41:00 +0200 Matthieu Baerts wrote:
> > I was aware of the conflict but didn't realize a note would be helpful
> > for the merge. I should have included one.
> >
> > Could you point me to an example commit/patch that contains such a note so I
> > can understand the expected format and procedure?
>
> In this particular example, I think it would have been easier to have
> waited for the fix to land in net-next -- after the weekly sync with net
> -- and then send the net-next patches.
>
> When this cannot be avoided, then you can mention the conflict, and
> ideally share a diff of the resolution, plus a description, especially
> when it is not obvious, when simply saying "take the version from X" is
> helpful, when extra modifications are needed, etc. e.g. [1]. Something
> similar to what Mark is usually doing on the linux-next ML, or what I
> did here.
Thanks for explaining! This conflict was avoidable but I didn't find
the appropriately polite explanation within me :)
When conflicting code is _already committed_ to net-next we can deal
with the conflict. If there's a patch only posted but not commited and
we notice a bug - the net-next patch should be explicitly withdrawn and
reposted once the fix has propagated.
^ permalink raw reply
* Fixes tags need work in the iommu tree
From: Mark Brown @ 2026-06-12 17:17 UTC (permalink / raw)
To: Joerg Roedel; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
In commit
db50fb87015b95 ("iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path")
Fixes tag
Fixes: a25e7962db ("PCI/P2PDMA: Refactor the p2pdma mapping helpers")
has these problem(s):
- SHA1 should be at least 12 digits long
This can be fixed for the future by setting core.abbrev to 12 (or
more) or (for git v2.11 or later) just making sure it is not set
(or set to "auto").
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Missing signoff in the iommufd tree
From: Mark Brown @ 2026-06-12 17:17 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 341 bytes --]
Commits
7c224d21ed43fb ("iommu: Avoid copying the user array twice in the full-array copy helper")
6bbe55d4d6bc34 ("iommufd/selftest: Add invalidation entry_num and entry_len boundary tests")
105209a23e1120 ("iommufd: Set upper bounds on cache invalidation entry_num and entry_len")
are missing a Signed-off-by from their committers
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the vfs-brauner tree
From: Mark Brown @ 2026-06-12 17:17 UTC (permalink / raw)
To: Christian Brauner, Davide Ornaghi, Namjae Jeon, Steve French
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]
Hi all,
After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/tmp/next/build/fs/smb/server/vfs.c:1255:30: error: too many arguments to function call, expected 5, have 6
1254 | err = vfs_path_parent_lookup(filename, flags | LOOKUP_BENEATH,
| ~~~~~~~~~~~~~~~~~~~~~~
1255 | path, &last, &type, &share_conf->vfs_path);
| ^~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/namei.h:63:5: note: 'vfs_path_parent_lookup' declared here
63 | int vfs_path_parent_lookup(struct filename *filename, unsigned int flags,
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
64 | struct path *parent, struct qstr *last,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
65 | const struct path *root);
| ~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Caused by commit
f2f1dddccae50f (vfs: make LAST_XXX private to fs/namei.c)
interacting with commit
9b012f13c6b671 (ksmbd: fix path resolution in ksmbd_vfs_kern_path_create)
from the ksmbd tree. I have fixed this up as below and can carry as
needed:
diff --git a/fs/smb/server/vfs.c b/fs/smb/server/vfs.c
index da0dbf2209d28b..7e4fffc88dbd75 100644
--- a/fs/smb/server/vfs.c
+++ b/fs/smb/server/vfs.c
@@ -1246,13 +1246,13 @@ struct dentry *ksmbd_vfs_kern_path_create(struct ksmbd_work *work,
struct ksmbd_share_config *share_conf = work->tcon->share_conf;
struct qstr last;
struct dentry *dent;
- int type, err;
+ int err;
/* resolve the name beneath the share root so ".." cannot escape */
CLASS(filename_kernel, filename)(name);
err = vfs_path_parent_lookup(filename, flags | LOOKUP_BENEATH,
- path, &last, &type, &share_conf->vfs_path);
+ path, &last, &share_conf->vfs_path);
if (err)
return ERR_PTR(err);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
From: Tetsuo Handa @ 2026-06-12 13:12 UTC (permalink / raw)
To: Nathan Chancellor, Tejun Heo
Cc: Mark Brown, Linux-Next Mailing List, Linus Torvalds,
Marco Crivellari, linux-kernel, Lai Jiangshan,
Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko,
Breno Leitao
In-Reply-To: <20260610172823.GA804799@ax162>
On 2026/06/11 2:28, Nathan Chancellor wrote:
> FWIW, I sent a patch for the btrfs issue:
>
> https://lore.kernel.org/20260601-btrfs-fix-wq-warning-qgroup-rescan-v1-1-aff9a1128f27@kernel.org/
Then, please immediately add that patch and
https://lkml.kernel.org/r/20260611015545.111157-1-wuyankun@uniontech.com
to the wq tree.
>
> With that applied to next-20260610, I don't see any other instances of
> this workqueue warning on any of my test machines. I do agree that
> enabling warnings prematurely is disruptive for testing and should be
> avoided but it seems like this one is close? That change should be
> applicable to the workqueue tree, it just needs to be taken at this
> point.
>
^ permalink raw reply
* Fixes tags need work in the pmdomain tree
From: Mark Brown @ 2026-06-12 13:39 UTC (permalink / raw)
To: Ulf Hansson; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 309 bytes --]
In commit
7dbcc2b682501a ("pmdomains: core: fix unused variable warning with !PM_GENERIC_DOMAINS_OF")
Fixes tag
Fixes: 92b69eff8012 ("pmdomain: fix early domain registration")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge
From: Matthieu Baerts @ 2026-06-12 11:41 UTC (permalink / raw)
To: Breno Leitao
Cc: Allison Henderson, linux-kernel, netdev, linux-rdma, rds-devel,
linux-kselftest, kernel-team, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan,
Andy Grover, Mark Brown, Linux Next Mailing List
In-Reply-To: <aivAbAIjnTeqlsdS@gmail.com>
Hi Breno,
On 12/06/2026 10:19, Breno Leitao wrote:
> Hello Matthieu,
>
> On Thu, Jun 11, 2026 at 02:52:36PM +0200, Matthieu Baerts wrote:
>>> + /*
>>> + * iov_iter_extract_pages() pins only user-backed (ubuf) iters;
>>> + * iov_iter_extract_will_pin() reports whether an unpin is owed here.
>>> + */
>>> + if (pages && iov_iter_extract_will_pin(&opt->iter_out))
>>> unpin_user_pages(pages, nr_pages);
>>
>> FYI, we got a small conflict when merging 'net' in 'net-next' in the
>> MPTCP tree due to this patch applied in 'net':
>>
>> f512db8267b73 ("rds: mark snapshot pages dirty in rds_info_getsockopt()")
>>
>> and this one from 'net-next':
>>
>> 6e94eeb2a2a6 ("rds: convert to getsockopt_iter")
>
> I was aware of the conflict but didn't realize a note would be helpful
> for the merge. I should have included one.
>
> Could you point me to an example commit/patch that contains such a note so I
> can understand the expected format and procedure?
In this particular example, I think it would have been easier to have
waited for the fix to land in net-next -- after the weekly sync with net
-- and then send the net-next patches.
When this cannot be avoided, then you can mention the conflict, and
ideally share a diff of the resolution, plus a description, especially
when it is not obvious, when simply saying "take the version from X" is
helpful, when extra modifications are needed, etc. e.g. [1]. Something
similar to what Mark is usually doing on the linux-next ML, or what I
did here.
[1]
https://lore.kernel.org/98386125-c0bb-495e-b2ba-2765aaed19d8@oss.qualcomm.com
> Apologies for the omission.
No problem, it happens fairly regularly ;)
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge
From: Breno Leitao @ 2026-06-12 8:19 UTC (permalink / raw)
To: Matthieu Baerts
Cc: Allison Henderson, linux-kernel, netdev, linux-rdma, rds-devel,
linux-kselftest, kernel-team, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan,
Andy Grover, Mark Brown, Linux Next Mailing List
In-Reply-To: <2e1b0534-a1a0-4eb1-a5e2-d42fcf991188@kernel.org>
Hello Matthieu,
On Thu, Jun 11, 2026 at 02:52:36PM +0200, Matthieu Baerts wrote:
> > + /*
> > + * iov_iter_extract_pages() pins only user-backed (ubuf) iters;
> > + * iov_iter_extract_will_pin() reports whether an unpin is owed here.
> > + */
> > + if (pages && iov_iter_extract_will_pin(&opt->iter_out))
> > unpin_user_pages(pages, nr_pages);
>
> FYI, we got a small conflict when merging 'net' in 'net-next' in the
> MPTCP tree due to this patch applied in 'net':
>
> f512db8267b73 ("rds: mark snapshot pages dirty in rds_info_getsockopt()")
>
> and this one from 'net-next':
>
> 6e94eeb2a2a6 ("rds: convert to getsockopt_iter")
I was aware of the conflict but didn't realize a note would be helpful
for the merge. I should have included one.
Could you point me to an example commit/patch that contains such a note so I
can understand the expected format and procedure?
Apologies for the omission.
--breno
^ permalink raw reply
* [STATUS] next/master - ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
From: KernelCI bot @ 2026-06-12 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/ec039126b7fac4e3af35ebccaa7c6f9b6875ba81/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
origin: maestro
test start time: 2026-06-11 15:11:17.364000+00:00
Builds: 53 ✅ 6 ❌ 0 ⚠️
Boots: 157 ✅ 3 ❌ 4 ⚠️
Tests: 26552 ✅ 2194 ❌ 6826 ⚠️
### POSSIBLE REGRESSIONS
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2ad945dabb8c619d4aad8b
history: > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae311dabb8c619d4b4ee2
history: > ✅ > ✅ > ❌
Hardware: qcs615-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae30cdabb8c619d4b4ec8
history: > ✅ > ✅ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae30ddabb8c619d4b4ece
history: > ✅ > ✅ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a2ad8f3dabb8c619d4aaa61
history: > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae30edabb8c619d4b4ed3
history: > ✅ > ✅ > ❌
Hardware: qcs9100-ride
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae30fdabb8c619d4b4ed7
history: > ✅ > ✅ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2ad944dabb8c619d4aad83
history: > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae310dabb8c619d4b4edd
history: > ✅ > ✅ > ❌
Hardware: x1e80100
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2ad948dabb8c619d4aad9f
history: > ✅ > ✅ > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae314dabb8c619d4b4ef2
history: > ✅ > ✅ > ✅ > ✅ > ❌
Hardware: glymur-crd
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a2ad93edabb8c619d4aad56
history: > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a2ae30adabb8c619d4b4ebf
history: > ✅ > ✅ > ❌
### FIXED REGRESSIONS
Hardware: cd8180-orion-o6
> Config: defconfig+netdev+nfs-root-boot+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a2adcdfdabb8c619d4b14fa
history: > ❌ > ❌ > ✅ > ✅ > ✅
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2ad95fdabb8c619d4aae69
history: > ⚠️ > ⚠️ > ⚠️ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2adae4dabb8c619d4adab0
history: > ⚠️ > ✅ > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a2adae6dabb8c619d4adab3
history: > ✅ > ⚠️ > ✅ > ⚠️ > ✅
This branch has 6 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: linux-next: Tree for Jun 10
From: Mark Brown @ 2026-06-11 19:29 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Konstantin Ryabitsev, Linux Next Mailing List, helpdesk
In-Reply-To: <f4ca5f0b-a897-4249-8b04-759dc2d10610@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 943 bytes --]
On Thu, Jun 11, 2026 at 12:25:17PM -0700, Randy Dunlap wrote:
> On 6/11/26 11:47 AM, Mark Brown wrote:
> > I see kup running and didn't notice any errors, the output is lost to
> > scrollback now. I'm on my laptop rather than my desktop, presumably
> > there's something different though not knowingly. I'm not sure it
> > matters, I don't know that anyone but Randy even looks at the patch
> > files.
> Maybe you should just announce that they are being discontinued.
> It will alter my workflow but I can handle it.
Whatever is up should be resolved whenever I'm back on my desktop on
Monday I'd expect, like I say it's not a deliberate change. I can't
check for differences since the reason I'm using my laptop is that I'm
not near my destkop, and I won't be able to double check for any error
reports from kup until I next try to publish - I did see it running
today, don't think I stared at it until the upload was finished though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Jun 10
From: Randy Dunlap @ 2026-06-11 19:25 UTC (permalink / raw)
To: Mark Brown, Konstantin Ryabitsev; +Cc: Linux Next Mailing List, helpdesk
In-Reply-To: <aisC0nU0ZnN7wv6e@sirena.co.uk>
On 6/11/26 11:47 AM, Mark Brown wrote:
> On Thu, Jun 11, 2026 at 02:39:19PM -0400, Konstantin Ryabitsev wrote:
>> On Thu, Jun 11, 2026 at 11:24:50AM -0700, Randy Dunlap wrote:
>
>>> linux-next-20260611 is also not present.
>
>> Not anything on our end, afaict -- the latest upload I see is from 20260608:
>
> I see kup running and didn't notice any errors, the output is lost to
> scrollback now. I'm on my laptop rather than my desktop, presumably
> there's something different though not knowingly. I'm not sure it
> matters, I don't know that anyone but Randy even looks at the patch
> files.
Maybe you should just announce that they are being discontinued.
It will alter my workflow but I can handle it.
--
~Randy
^ permalink raw reply
* Re: linux-next: Tree for Jun 10
From: Mark Brown @ 2026-06-11 18:47 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Randy Dunlap, Linux Next Mailing List, helpdesk
In-Reply-To: <20260611-invincible-whale-of-progress-69ffd1@meerkat>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On Thu, Jun 11, 2026 at 02:39:19PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Jun 11, 2026 at 11:24:50AM -0700, Randy Dunlap wrote:
> > linux-next-20260611 is also not present.
> Not anything on our end, afaict -- the latest upload I see is from 20260608:
I see kup running and didn't notice any errors, the output is lost to
scrollback now. I'm on my laptop rather than my desktop, presumably
there's something different though not knowingly. I'm not sure it
matters, I don't know that anyone but Randy even looks at the patch
files.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for Jun 10
From: Konstantin Ryabitsev @ 2026-06-11 18:39 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Mark Brown, Linux Next Mailing List, helpdesk
In-Reply-To: <ac803cb5-37c8-4e41-af3b-1c15955cb219@infradead.org>
On Thu, Jun 11, 2026 at 11:24:50AM -0700, Randy Dunlap wrote:
> >> Changes since 20260609:
> >
> >> ----------------------------------------------------------------------------
> >>
> >> 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
> >
> > linux-next-202606{09,10} are *not* available at www.kernel.org/pub/linux/kernel/next/.
> > The last one there is linux-next-20260608.
>
> linux-next-20260611 is also not present.
>
Not anything on our end, afaict -- the latest upload I see is from 20260608:
2026-06-01.17:27:56 3037912 write_allowed,/pub/linux/kernel/next/patch-v7.1-rc6-next-20260601.gz
2026-06-02.16:57:34 4107511 write_allowed,/pub/linux/kernel/next/patch-v7.1-rc6-next-20260602.gz
2026-06-03.19:14:59 1096610 write_allowed,/pub/linux/kernel/next/patch-v7.1-rc6-next-20260603.gz
2026-06-04.16:19:49 2121815 write_allowed,/pub/linux/kernel/next/patch-v7.1-rc6-next-20260604.gz
2026-06-05.13:36:22 3088815 write_allowed,/pub/linux/kernel/next/patch-v7.1-rc6-next-20260605.gz
2026-06-08.14:34:58 2243345 write_allowed,/pub/linux/kernel/next/patch-v7.1-rc7-next-20260608.gz
-K
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge
From: Allison Henderson @ 2026-06-11 18:35 UTC (permalink / raw)
To: Matthieu Baerts, Breno Leitao
Cc: linux-kernel, netdev, linux-rdma, rds-devel, linux-kselftest,
kernel-team, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, Andy Grover, Mark Brown,
Linux Next Mailing List
In-Reply-To: <2e1b0534-a1a0-4eb1-a5e2-d42fcf991188@kernel.org>
On Thu, 2026-06-11 at 14:52 +0200, Matthieu Baerts wrote:
> Hi Breno, Allison,
>
> On 08/06/2026 11:44, Breno Leitao wrote:
> > Convert RDS socket's getsockopt implementation to use the new
> > getsockopt_iter callback with sockopt_t.
> >
> > Key changes:
> > - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
> > - Use opt->optlen for buffer length (input) and returned size (output)
> > - Use copy_to_iter() instead of put_user()/copy_to_user()
> >
> > The RDS_INFO_* snapshot path in rds_info_getsockopt() used to pin the
> > userspace buffer with pin_user_pages_fast() on the raw optval address;
> > the info producers then memcpy into those pages under a spinlock via
> > kmap_atomic() and so must not fault. Obtain the same page array and
> > starting offset from opt->iter_out with iov_iter_extract_pages(), which
> > pins for write because iter_out is ITER_DEST.
> >
> > The page array is preallocated here (sized with iov_iter_npages()) and
> > passed in, so iov_iter_extract_pages() fills it in place rather than
> > allocating one for us; RDS therefore keeps ownership of the array on
> > every return path and frees it itself. The rds_info_iterator /
> > rds_info_copy machinery and all producer callbacks are unchanged.
> >
> > Kernel buffers (ITER_KVEC) are not page-backed in a way the info
> > producers can use, so the RDS_INFO path returns -EOPNOTSUPP for them;
> > this matches the previous behaviour, where a kernel-buffer getsockopt
> > hit the WARN_ONCE() path in do_sock_getsockopt() and returned
> > -EOPNOTSUPP. The simple RDS_RECVERR and SO_RDS_TRANSPORT options keep
> > working for kernel buffers via copy_to_iter().
>
> (...)
>
> > diff --git a/net/rds/info.c b/net/rds/info.c
> > index f1b29994934a..499b3774860e 100644
> > --- a/net/rds/info.c
> > +++ b/net/rds/info.c
>
> (...)
>
> > @@ -230,13 +239,16 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
> > ret = lens.each;
> > }
> >
> > - if (put_user(len, optlen))
> > - ret = -EFAULT;
> > + opt->optlen = len;
> >
> > out:
> > - if (pages)
> > + /*
> > + * iov_iter_extract_pages() pins only user-backed (ubuf) iters;
> > + * iov_iter_extract_will_pin() reports whether an unpin is owed here.
> > + */
> > + if (pages && iov_iter_extract_will_pin(&opt->iter_out))
> > unpin_user_pages(pages, nr_pages);
>
> FYI, we got a small conflict when merging 'net' in 'net-next' in the
> MPTCP tree due to this patch applied in 'net':
>
> f512db8267b73 ("rds: mark snapshot pages dirty in rds_info_getsockopt()")
>
> and this one from 'net-next':
>
> 6e94eeb2a2a6 ("rds: convert to getsockopt_iter")
>
> ----- Generic Message -----
> The best is to avoid conflicts between 'net' and 'net-next' trees but if
> they cannot be avoided when preparing patches, a note about how to fix
> them is much appreciated.
>
> The conflict has been resolved on our side [1] and the resolution we
> suggest is attached to this email. Please report any issues linked to
> this conflict resolution as it might be used by others. If you worked on
> the mentioned patches, don't hesitate to ACK this conflict resolution.
> ---------------------------
>
> Regarding this conflict, I took the modification from net-next, but
> using unpin_user_pages_dirty_lock() from net.
Hi Matt,
Yes, the conflict resolution looks correct to me.
Thank you for fixing this.
Allison
>
> Rerere cache is available in [2].
>
> Cheers,
> Matt
>
> 1: https://github.com/multipath-tcp/mptcp_net-next/commit/a8d41e018cc6
> 2: https://github.com/multipath-tcp/mptcp-upstream-rr-cache/commit/88eeb
>
> Cheers,
> Matt
^ permalink raw reply
* Re: linux-next: Tree for Jun 10
From: Randy Dunlap @ 2026-06-11 18:24 UTC (permalink / raw)
To: Mark Brown, Linux Next Mailing List; +Cc: Konstantin Ryabitsev, helpdesk
In-Reply-To: <608ff135-c113-4bda-9812-26ee8f8cdf7f@infradead.org>
[adding helpdesk@]
On 6/10/26 3:57 PM, Randy Dunlap wrote:
>
>
> On 6/10/26 8:53 AM, Mark Brown wrote:
>> Hi all,
>>
>> Changes since 20260609:
>
>> ----------------------------------------------------------------------------
>>
>> 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
>
> linux-next-202606{09,10} are *not* available at www.kernel.org/pub/linux/kernel/next/.
> The last one there is linux-next-20260608.
linux-next-20260611 is also not present.
--
~Randy
^ permalink raw reply
* linux-next: Tree for Jun 11
From: Mark Brown @ 2026-06-11 14:33 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
Hi all,
Changes since 20260610:
The vfs-brauner tree acquired a conflict with the ext4 tree.
The hwmon-staging tree lost it's build failure.
The net-next tree acquired a conflict with the net tree.
The ipvs-next tree acquired a conflict with the origin tree.
The drm tree acquired a conflict with the drm-misc-fixes tree.
Non-merge commits (relative to Linus' tree): 12101
13030 files changed, 799506 insertions(+), 243839 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 425 trees (counting Linus' and 131 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 vfs-brauner tree with the ext4 tree
From: Matthew Wilcox @ 2026-06-11 14:07 UTC (permalink / raw)
To: Mark Brown
Cc: Christian Brauner, Linux Kernel Mailing List,
Linux Next Mailing List, Mike Rapoport, Theodore Ts'o
In-Reply-To: <aiq8CByJNMlXo6Be@sirena.co.uk>
On Thu, Jun 11, 2026 at 02:45:44PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the vfs-brauner tree got a conflict in:
>
> fs/jbd2/journal.c
>
> between commit:
>
> bbe9015f23432b ("jbd2: remove special jbd2 slabs")
>
> from the ext4 tree and commit:
>
> 2f6702dc6fdcf0 ("jbd2: replace __get_free_pages() with kmalloc()")
>
> from the vfs-brauner tree.
2f6702dc6fdcf0 is a subset of bbe9015f23432b and should be dropped from
vfs-brauner.
^ permalink raw reply
* linux-next: manual merge of the drm tree with the drm-misc-fixes tree
From: Mark Brown @ 2026-06-11 13:54 UTC (permalink / raw)
To: Dave Airlie, DRI
Cc: Jani Nikula, Linux Kernel Mailing List, Linux Next Mailing List,
Maxime Ripard, Melissa Wen, Melissa Wen
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_atomic.c
include/drm/drm_colorop.h
between commit:
94ff735296d371 ("drm/colorop: make lut(1/3)d_interpolation props correctly behave as mutable")
from the drm-misc-fixes tree and commits:
5164f7e7ff8ec7 ("drm: Rename struct drm_atomic_state to drm_atomic_commit")
0c44d8dc6df988 ("drm/atomic: prefer drm_printf_indent() over inline \t")
from the drm 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
* linux-next: manual merge of the vfs-brauner tree with the ext4 tree
From: Mark Brown @ 2026-06-11 13:45 UTC (permalink / raw)
To: Christian Brauner
Cc: Linux Kernel Mailing List, Linux Next Mailing List,
Matthew Wilcox, Mike Rapoport, Theodore Ts'o
[-- Attachment #1: Type: text/plain, Size: 7033 bytes --]
Hi all,
Today's linux-next merge of the vfs-brauner tree got a conflict in:
fs/jbd2/journal.c
between commit:
bbe9015f23432b ("jbd2: remove special jbd2 slabs")
from the ext4 tree and commit:
2f6702dc6fdcf0 ("jbd2: replace __get_free_pages() with kmalloc()")
from the vfs-brauner tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined fs/jbd2/journal.c
index 4fdf089500f618,e82798680109d3..00000000000000
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@@ -95,6 -95,8 +95,6 @@@ EXPORT_SYMBOL(jbd2_journal_release_jbd_
EXPORT_SYMBOL(jbd2_journal_begin_ordered_truncate);
EXPORT_SYMBOL(jbd2_inode_cache);
-static int jbd2_journal_create_slab(size_t slab_size);
-
#ifdef CONFIG_JBD2_DEBUG
void __jbd2_debug(int level, const char *file, const char *func,
unsigned int line, const char *fmt, ...)
@@@ -383,10 -385,10 +383,10 @@@ int jbd2_journal_write_metadata_buffer(
goto escape_done;
spin_unlock(&jh_in->b_state_lock);
- tmp = jbd2_alloc(bh_in->b_size, GFP_NOFS | __GFP_NOFAIL);
+ tmp = kmalloc(bh_in->b_size, GFP_NOFS | __GFP_NOFAIL);
spin_lock(&jh_in->b_state_lock);
if (jh_in->b_frozen_data) {
- jbd2_free(tmp, bh_in->b_size);
+ kfree(tmp);
goto copy_done;
}
@@@ -1818,9 -1820,7 +1818,7 @@@ static int jbd2_write_superblock(journa
}
if (jbd2_journal_has_csum_v2or3(journal))
sb->s_checksum = jbd2_superblock_csum(sb);
- get_bh(bh);
- bh->b_end_io = end_buffer_write_sync;
- submit_bh(REQ_OP_WRITE | write_flags, bh);
+ bh_submit(bh, REQ_OP_WRITE | write_flags, bh_end_write);
wait_on_buffer(bh);
if (buffer_write_io_error(bh)) {
clear_buffer_write_io_error(bh);
@@@ -2062,6 -2062,14 +2060,6 @@@ EXPORT_SYMBOL(jbd2_journal_update_sb_er
int jbd2_journal_load(journal_t *journal)
{
int err;
- journal_superblock_t *sb = journal->j_superblock;
-
- /*
- * Create a slab for this blocksize
- */
- err = jbd2_journal_create_slab(be32_to_cpu(sb->s_blocksize));
- if (err)
- return err;
/* Let the recovery code check whether it needs to recover any
* data from the journal. */
@@@ -2253,8 -2261,6 +2251,8 @@@ jbd2_journal_initialize_fast_commit(jou
unsigned long long num_fc_blks;
num_fc_blks = jbd2_journal_get_num_fc_blks(sb);
+ if (num_fc_blks > journal->j_last)
+ return -EFSCORRUPTED;
if (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS)
return -ENOSPC;
@@@ -2691,6 -2697,105 +2689,6 @@@ size_t journal_tag_bytes(journal_t *jou
return sz - sizeof(__u32);
}
-/*
- * JBD memory management
- *
- * These functions are used to allocate block-sized chunks of memory
- * used for making copies of buffer_head data. Very often it will be
- * page-sized chunks of data, but sometimes it will be in
- * sub-page-size chunks. (For example, 16k pages on Power systems
- * with a 4k block file system.) For blocks smaller than a page, we
- * use a SLAB allocator. There are slab caches for each block size,
- * which are allocated at mount time, if necessary, and we only free
- * (all of) the slab caches when/if the jbd2 module is unloaded. For
- * this reason we don't need to a mutex to protect access to
- * jbd2_slab[] allocating or releasing memory; only in
- * jbd2_journal_create_slab().
- */
-#define JBD2_MAX_SLABS 8
-static struct kmem_cache *jbd2_slab[JBD2_MAX_SLABS];
-
-static const char *jbd2_slab_names[JBD2_MAX_SLABS] = {
- "jbd2_1k", "jbd2_2k", "jbd2_4k", "jbd2_8k",
- "jbd2_16k", "jbd2_32k", "jbd2_64k", "jbd2_128k"
-};
-
-
-static void jbd2_journal_destroy_slabs(void)
-{
- int i;
-
- for (i = 0; i < JBD2_MAX_SLABS; i++) {
- kmem_cache_destroy(jbd2_slab[i]);
- jbd2_slab[i] = NULL;
- }
-}
-
-static int jbd2_journal_create_slab(size_t size)
-{
- static DEFINE_MUTEX(jbd2_slab_create_mutex);
- int i = order_base_2(size) - 10;
- size_t slab_size;
-
- if (size == PAGE_SIZE)
- return 0;
-
- if (i >= JBD2_MAX_SLABS)
- return -EINVAL;
-
- if (unlikely(i < 0))
- i = 0;
- mutex_lock(&jbd2_slab_create_mutex);
- if (jbd2_slab[i]) {
- mutex_unlock(&jbd2_slab_create_mutex);
- return 0; /* Already created */
- }
-
- slab_size = 1 << (i+10);
- jbd2_slab[i] = kmem_cache_create(jbd2_slab_names[i], slab_size,
- slab_size, 0, NULL);
- mutex_unlock(&jbd2_slab_create_mutex);
- if (!jbd2_slab[i]) {
- printk(KERN_EMERG "JBD2: no memory for jbd2_slab cache\n");
- return -ENOMEM;
- }
- return 0;
-}
-
-static struct kmem_cache *get_slab(size_t size)
-{
- int i = order_base_2(size) - 10;
-
- BUG_ON(i >= JBD2_MAX_SLABS);
- if (unlikely(i < 0))
- i = 0;
- BUG_ON(jbd2_slab[i] == NULL);
- return jbd2_slab[i];
-}
-
-void *jbd2_alloc(size_t size, gfp_t flags)
-{
- void *ptr;
-
- BUG_ON(size & (size-1)); /* Must be a power of 2 */
-
- if (size < PAGE_SIZE)
- ptr = kmem_cache_alloc(get_slab(size), flags);
- else
- ptr = kmalloc(size, flags);
-
- /* Check alignment; SLUB has gotten this wrong in the past,
- * and this can lead to user data corruption! */
- BUG_ON(((unsigned long) ptr) & (size-1));
-
- return ptr;
-}
-
-void jbd2_free(void *ptr, size_t size)
-{
- kfree(ptr);
-};
-
/*
* Journal_head storage management
*/
@@@ -2864,15 -2969,15 +2862,15 @@@ static void __journal_remove_journal_he
clear_buffer_jbd(bh);
}
-static void journal_release_journal_head(struct journal_head *jh, size_t b_size)
+static void journal_release_journal_head(struct journal_head *jh)
{
if (jh->b_frozen_data) {
printk(KERN_WARNING "%s: freeing b_frozen_data\n", __func__);
- jbd2_free(jh->b_frozen_data, b_size);
+ kfree(jh->b_frozen_data);
}
if (jh->b_committed_data) {
printk(KERN_WARNING "%s: freeing b_committed_data\n", __func__);
- jbd2_free(jh->b_committed_data, b_size);
+ kfree(jh->b_committed_data);
}
journal_free_journal_head(jh);
}
@@@ -2891,7 -2996,7 +2889,7 @@@ void jbd2_journal_put_journal_head(stru
if (!jh->b_jcount) {
__journal_remove_journal_head(bh);
jbd_unlock_bh_journal_head(bh);
- journal_release_journal_head(jh, bh->b_size);
+ journal_release_journal_head(jh);
__brelse(bh);
} else {
jbd_unlock_bh_journal_head(bh);
@@@ -3033,6 -3138,7 +3031,6 @@@ static void jbd2_journal_destroy_caches
jbd2_journal_destroy_handle_cache();
jbd2_journal_destroy_inode_cache();
jbd2_journal_destroy_transaction_cache();
- jbd2_journal_destroy_slabs();
}
static int __init journal_init(void)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Mark Brown @ 2026-06-11 13:45 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, Paolo Abeni, Networking
Cc: Jiawen Wu, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3489 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
between commit:
f2df54ddbfb04a ("net: txgbe: distinguish module types by checking identifier")
from the net tree and commit:
f67aead16e85f7 ("net: txgbe: rework service event handling")
from the net-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 --combined drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
index 8fc32df8e49a44,72712cee1ab834..00000000000000
--- a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
+++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
@@@ -186,25 -186,21 +186,21 @@@ static void txgbe_get_mac_link(struct w
*speed = SPEED_UNKNOWN;
}
- int txgbe_set_phy_link(struct wx *wx)
+ void txgbe_set_phy_link(struct wx *wx)
{
int speed, autoneg, duplex, err;
txgbe_get_link_capabilities(wx, &speed, &autoneg, &duplex);
err = txgbe_set_phy_link_hostif(wx, speed, autoneg, duplex);
- if (err) {
+ if (err)
wx_err(wx, "Failed to setup link\n");
- return err;
- }
-
- return 0;
}
static int txgbe_sfp_to_linkmodes(struct wx *wx, struct txgbe_sff_id *id)
{
__ETHTOOL_DECLARE_LINK_MODE_MASK(modes) = { 0, };
- DECLARE_PHY_INTERFACE_MASK(interfaces);
+ DECLARE_PHY_INTERFACE_MASK_ZERO(interfaces);
struct txgbe *txgbe = wx->priv;
if (id->cable_tech & TXGBE_SFF_DA_PASSIVE_CABLE) {
@@@ -271,7 -267,7 +267,7 @@@
static int txgbe_qsfp_to_linkmodes(struct wx *wx, struct txgbe_sff_id *id)
{
__ETHTOOL_DECLARE_LINK_MODE_MASK(modes) = { 0, };
- DECLARE_PHY_INTERFACE_MASK(interfaces);
+ DECLARE_PHY_INTERFACE_MASK_ZERO(interfaces);
struct txgbe *txgbe = wx->priv;
if (id->transceiver_type & TXGBE_SFF_ETHERNET_40G_CR4) {
@@@ -335,7 -331,7 +331,7 @@@
int txgbe_identify_module(struct wx *wx)
{
- struct txgbe_hic_get_module_info buffer;
+ struct txgbe_hic_get_module_info buffer = { 0 };
struct txgbe_sff_id *id;
int err = 0;
u32 mod_abs;
@@@ -357,16 -353,18 +353,16 @@@
}
id = &buffer.id;
- if (id->identifier != TXGBE_SFF_IDENTIFIER_SFP &&
- id->identifier != TXGBE_SFF_IDENTIFIER_QSFP &&
- id->identifier != TXGBE_SFF_IDENTIFIER_QSFP_PLUS &&
- id->identifier != TXGBE_SFF_IDENTIFIER_QSFP28) {
- wx_err(wx, "Invalid module\n");
- return -EINVAL;
- }
-
- if (id->transceiver_type == 0xFF)
+ if (id->identifier == TXGBE_SFF_IDENTIFIER_SFP)
return txgbe_sfp_to_linkmodes(wx, id);
- return txgbe_qsfp_to_linkmodes(wx, id);
+ if (id->identifier == TXGBE_SFF_IDENTIFIER_QSFP ||
+ id->identifier == TXGBE_SFF_IDENTIFIER_QSFP_PLUS ||
+ id->identifier == TXGBE_SFF_IDENTIFIER_QSFP28)
+ return txgbe_qsfp_to_linkmodes(wx, id);
+
+ wx_err(wx, "Invalid module\n");
+ return -EINVAL;
}
void txgbe_setup_link(struct wx *wx)
@@@ -519,6 -517,7 +515,7 @@@ int txgbe_phylink_init_aml(struct txgb
err = phylink_set_fixed_link(phylink, &state);
if (err) {
wx_err(wx, "Failed to set fixed link\n");
+ phylink_destroy(phylink);
return err;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the ipvs-next tree with the origin tree
From: Mark Brown @ 2026-06-11 13:45 UTC (permalink / raw)
To: Simon Horman
Cc: Linux Kernel Mailing List, Linux Next Mailing List,
Luiz Augusto von Dentz, Marco Elver, Siwei Zhang
[-- Attachment #1: Type: text/plain, Size: 5386 bytes --]
Hi all,
Today's linux-next merge of the ipvs-next tree got a conflict in:
net/bluetooth/l2cap_core.c
between commit:
9dbd84990394c5 ("Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn")
from the origin tree and commit:
06528e2f5fc933 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref")
from the ipvs-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 --combined net/bluetooth/l2cap_core.c
index c4ccfbda9d7890,62133eef9d2fea..00000000000000
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@@ -1,3 -1,4 +1,4 @@@
+ // SPDX-License-Identifier: GPL-2.0
/*
BlueZ - Bluetooth protocol stack for Linux
Copyright (C) 2000-2001 Qualcomm Incorporated
@@@ -8,10 -9,6 +9,6 @@@
Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License version 2 as
- published by the Free Software Foundation;
-
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
@@@ -411,7 -408,7 +408,7 @@@ static void l2cap_chan_timeout(struct w
BT_DBG("chan %p state %s", chan, state_to_string(chan->state));
- if (!conn) {
+ if (test_bit(FLAG_DEL, &chan->flags)) {
l2cap_chan_put(chan);
return;
}
@@@ -422,6 -419,9 +419,9 @@@
*/
l2cap_chan_lock(chan);
+ if (test_bit(FLAG_DEL, &chan->flags))
+ goto unlock;
+
if (chan->state == BT_CONNECTED || chan->state == BT_CONFIG)
reason = ECONNREFUSED;
else if (chan->state == BT_CONNECT &&
@@@ -434,10 -434,10 +434,10 @@@
chan->ops->close(chan);
+ unlock:
l2cap_chan_unlock(chan);
- l2cap_chan_put(chan);
-
mutex_unlock(&conn->lock);
+ l2cap_chan_put(chan);
}
struct l2cap_chan *l2cap_chan_create(void)
@@@ -490,6 -490,9 +490,9 @@@ static void l2cap_chan_destroy(struct k
list_del(&chan->global_l);
write_unlock(&chan_list_lock);
+ if (chan->conn)
+ l2cap_conn_put(chan->conn);
+
kfree(chan);
}
@@@ -593,7 -596,7 +596,7 @@@ void __l2cap_chan_add(struct l2cap_con
conn->disc_reason = HCI_ERROR_REMOTE_USER_TERM;
- chan->conn = conn;
+ chan->conn = l2cap_conn_get(conn);
switch (chan->chan_type) {
case L2CAP_CHAN_CONN_ORIENTED:
@@@ -648,30 -651,26 +651,26 @@@ void l2cap_chan_add(struct l2cap_conn *
void l2cap_chan_del(struct l2cap_chan *chan, int err)
{
- struct l2cap_conn *conn = chan->conn;
-
__clear_chan_timer(chan);
- BT_DBG("chan %p, conn %p, err %d, state %s", chan, conn, err,
+ BT_DBG("chan %p, err %d, state %s", chan, err,
state_to_string(chan->state));
chan->ops->teardown(chan, err);
- if (conn) {
+ if (!test_and_set_bit(FLAG_DEL, &chan->flags)) {
/* Delete from channel list */
list_del(&chan->list);
l2cap_chan_put(chan);
- chan->conn = NULL;
-
/* Reference was only held for non-fixed channels or
* fixed channels that explicitly requested it using the
* FLAG_HOLD_HCI_CONN flag.
*/
if (chan->chan_type != L2CAP_CHAN_FIXED ||
test_bit(FLAG_HOLD_HCI_CONN, &chan->flags))
- hci_conn_drop(conn->hcon);
+ hci_conn_drop(chan->conn->hcon);
}
if (test_bit(CONF_NOT_COMPLETE, &chan->conf_state))
@@@ -1903,7 -1902,7 +1902,7 @@@ static void l2cap_monitor_timeout(struc
l2cap_chan_lock(chan);
- if (!chan->conn) {
+ if (test_bit(FLAG_DEL, &chan->flags)) {
l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
return;
@@@ -1924,7 -1923,7 +1923,7 @@@ static void l2cap_retrans_timeout(struc
l2cap_chan_lock(chan);
- if (!chan->conn) {
+ if (test_bit(FLAG_DEL, &chan->flags)) {
l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
return;
@@@ -2565,7 -2564,7 +2564,7 @@@ int l2cap_chan_send(struct l2cap_chan *
int err;
struct sk_buff_head seg_queue;
- if (!chan->conn)
+ if (test_bit(FLAG_DEL, &chan->flags))
return -ENOTCONN;
/* Connectionless channel */
@@@ -3160,12 -3159,16 +3159,16 @@@ static void l2cap_ack_timeout(struct wo
l2cap_chan_lock(chan);
+ if (test_bit(FLAG_DEL, &chan->flags))
+ goto unlock;
+
frames_to_ack = __seq_offset(chan, chan->buffer_seq,
chan->last_acked_seq);
if (frames_to_ack)
l2cap_send_rr_or_rnr(chan, 0);
+ unlock:
l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
}
@@@ -7026,6 -7029,11 +7029,11 @@@ static void l2cap_recv_frame(struct l2c
break;
case L2CAP_CID_CONN_LESS:
+ if (skb->len < L2CAP_PSMLEN_SIZE) {
+ kfree_skb(skb);
+ break;
+ }
+
psm = get_unaligned((__le16 *) skb->data);
skb_pull(skb, L2CAP_PSMLEN_SIZE);
l2cap_conless_channel(conn, psm, skb);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge
From: Matthieu Baerts @ 2026-06-11 12:52 UTC (permalink / raw)
To: Breno Leitao, Allison Henderson
Cc: linux-kernel, netdev, linux-rdma, rds-devel, linux-kselftest,
kernel-team, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan, Andy Grover, Mark Brown,
Linux Next Mailing List
In-Reply-To: <20260608-getsock_more-v3-2-706ecf2ea332@debian.org>
[-- Attachment #1: Type: text/plain, Size: 3346 bytes --]
Hi Breno, Allison,
On 08/06/2026 11:44, Breno Leitao wrote:
> Convert RDS socket's getsockopt implementation to use the new
> getsockopt_iter callback with sockopt_t.
>
> Key changes:
> - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
> - Use opt->optlen for buffer length (input) and returned size (output)
> - Use copy_to_iter() instead of put_user()/copy_to_user()
>
> The RDS_INFO_* snapshot path in rds_info_getsockopt() used to pin the
> userspace buffer with pin_user_pages_fast() on the raw optval address;
> the info producers then memcpy into those pages under a spinlock via
> kmap_atomic() and so must not fault. Obtain the same page array and
> starting offset from opt->iter_out with iov_iter_extract_pages(), which
> pins for write because iter_out is ITER_DEST.
>
> The page array is preallocated here (sized with iov_iter_npages()) and
> passed in, so iov_iter_extract_pages() fills it in place rather than
> allocating one for us; RDS therefore keeps ownership of the array on
> every return path and frees it itself. The rds_info_iterator /
> rds_info_copy machinery and all producer callbacks are unchanged.
>
> Kernel buffers (ITER_KVEC) are not page-backed in a way the info
> producers can use, so the RDS_INFO path returns -EOPNOTSUPP for them;
> this matches the previous behaviour, where a kernel-buffer getsockopt
> hit the WARN_ONCE() path in do_sock_getsockopt() and returned
> -EOPNOTSUPP. The simple RDS_RECVERR and SO_RDS_TRANSPORT options keep
> working for kernel buffers via copy_to_iter().
(...)
> diff --git a/net/rds/info.c b/net/rds/info.c
> index f1b29994934a..499b3774860e 100644
> --- a/net/rds/info.c
> +++ b/net/rds/info.c
(...)
> @@ -230,13 +239,16 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
> ret = lens.each;
> }
>
> - if (put_user(len, optlen))
> - ret = -EFAULT;
> + opt->optlen = len;
>
> out:
> - if (pages)
> + /*
> + * iov_iter_extract_pages() pins only user-backed (ubuf) iters;
> + * iov_iter_extract_will_pin() reports whether an unpin is owed here.
> + */
> + if (pages && iov_iter_extract_will_pin(&opt->iter_out))
> unpin_user_pages(pages, nr_pages);
FYI, we got a small conflict when merging 'net' in 'net-next' in the
MPTCP tree due to this patch applied in 'net':
f512db8267b73 ("rds: mark snapshot pages dirty in rds_info_getsockopt()")
and this one from 'net-next':
6e94eeb2a2a6 ("rds: convert to getsockopt_iter")
----- Generic Message -----
The best is to avoid conflicts between 'net' and 'net-next' trees but if
they cannot be avoided when preparing patches, a note about how to fix
them is much appreciated.
The conflict has been resolved on our side [1] and the resolution we
suggest is attached to this email. Please report any issues linked to
this conflict resolution as it might be used by others. If you worked on
the mentioned patches, don't hesitate to ACK this conflict resolution.
---------------------------
Regarding this conflict, I took the modification from net-next, but
using unpin_user_pages_dirty_lock() from net.
Rerere cache is available in [2].
Cheers,
Matt
1: https://github.com/multipath-tcp/mptcp_net-next/commit/a8d41e018cc6
2: https://github.com/multipath-tcp/mptcp-upstream-rr-cache/commit/88eeb
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
[-- Attachment #2: a8d41e018cc69a6546ef6acc4a97bcbeb3e75d43.patch --]
[-- Type: text/x-patch, Size: 643 bytes --]
diff --cc net/rds/info.c
index 499b3774860e,17061f6ff74e..21b32eb16559
--- a/net/rds/info.c
+++ b/net/rds/info.c
@@@ -239,16 -230,13 +239,16 @@@ call_func
ret = lens.each;
}
- if (put_user(len, optlen))
- ret = -EFAULT;
+ opt->optlen = len;
out:
- if (pages)
+ /*
+ * iov_iter_extract_pages() pins only user-backed (ubuf) iters;
+ * iov_iter_extract_will_pin() reports whether an unpin is owed here.
+ */
+ if (pages && iov_iter_extract_will_pin(&opt->iter_out))
- unpin_user_pages(pages, nr_pages);
+ unpin_user_pages_dirty_lock(pages, nr_pages, true);
- kfree(pages);
+ kvfree(pages);
return ret;
}
^ permalink raw reply
* Re: linux-next crashes in scheduler on s390
From: Peter Zijlstra @ 2026-06-11 11:08 UTC (permalink / raw)
To: Sven Schnelle
Cc: Alexander Gordeev, Ingo Molnar, Juri Lelli, Vincent Guittot,
K Prateek Nayak, Mark Brown, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Valentin Schneider, John Stultz,
Vineeth Pillai, Joel Fernandes, Heiko Carstens, Vasily Gorbik,
linux-s390, linux-kernel, linux-next, Aaron Lu
In-Reply-To: <yt9dmrx2wns1.fsf@linux.ibm.com>
On Wed, Jun 10, 2026 at 03:03:26PM +0200, Sven Schnelle wrote:
> Alexander Gordeev <agordeev@linux.ibm.com> writes:
>
> > Hi All,
> >
> > Since about June 1st we're getting strace test suite (make -j$(nproc) check)
> > crashes on s390 in linux-next. Those are pretty easy to reproduce, but I
> > have not been able to nail it down to the particular commit/merge.
> >
> > I am going to bisect it, but since we are approaching v7.1 release, any
> > hint would be greatly appreciated!
> > [..]
>
> I bisected it to
> https://lore.kernel.org/all/20260511120627.944705718@infradead.org/
> ("[PATCH v2 08/10] sched/fair: Add newidle balance to pick_task_fair()")
>
> Adding the patch proposed in
> https://lore.kernel.org/all/20260603095108.GA1684319@bytedance.com/
> fixes the issue for me.
>
> To reproduce, running the strace test suite seems enough. If required, I
> can try to figure out the exact test that crashes the kernel.
Oh sorry for the borkage and thanks for the pointer -- I clearly missed
that :-(.
I've just been staring at all this and while I think I prefer a slightly
different solution, I think I'm going to just apply that patch since its
fairly trivial and you've confirmed it works. And then I can go do the
alternative for the next cycle -- and hopefully not wreck it again :-).
^ permalink raw reply
* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
From: Mark Brown @ 2026-06-11 10:28 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Tetsuo Handa, Tejun Heo, Linux-Next Mailing List, Linus Torvalds,
Marco Crivellari, linux-kernel, Lai Jiangshan,
Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko,
Breno Leitao
In-Reply-To: <20260610172823.GA804799@ax162>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Wed, Jun 10, 2026 at 10:28:23AM -0700, Nathan Chancellor wrote:
> With that applied to next-20260610, I don't see any other instances of
> this workqueue warning on any of my test machines. I do agree that
> enabling warnings prematurely is disruptive for testing and should be
> avoided but it seems like this one is close? That change should be
> applicable to the workqueue tree, it just needs to be taken at this
> point.
Yeah, if things are directly applicable to the workqueue tree they
should just go there - I was assuming the fixes that were causing issues
were ones that were for things newly added in -next.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older)
- 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