* 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
* [STATUS] next/master - abe651837cb394f76d738a7a747322fca3bf17ba
From: KernelCI bot @ 2026-06-11 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/abe651837cb394f76d738a7a747322fca3bf17ba/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: abe651837cb394f76d738a7a747322fca3bf17ba
origin: maestro
test start time: 2026-06-10 16:28:53.305000+00:00
Builds: 58 ✅ 1 ❌ 0 ⚠️
Boots: 78 ✅ 74 ❌ 5 ⚠️
Tests: 12558 ✅ 2822 ❌ 548 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### 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:6a29a374dabb8c619d45376e
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:6a299f5ddabb8c619d451f46
history: > ⚠️ > ✅ > ✅ > ⚠️ > ⚠️
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a299e95dabb8c619d45136c
history: > ⚠️ > ✅ > ✅ > ⚠️ > ✅
Hardware: exynos850-e850-96
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a299f5edabb8c619d451f4c
history: > ✅ > ⚠️ > ⚠️ > ⚠️
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a299e97dabb8c619d45136f
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:6a299929dabb8c619d44db06
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: linux-next: Tree for Jun 10
From: Randy Dunlap @ 2026-06-10 22:57 UTC (permalink / raw)
To: Mark Brown, Linux Next Mailing List; +Cc: Konstantin Ryabitsev
In-Reply-To: <aimIc7ciEUrhXV23@sirena.co.uk>
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.
> 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.
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
From: Nathan Chancellor @ 2026-06-10 17:28 UTC (permalink / raw)
To: Tetsuo Handa, 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: <bbca08c9-c6bc-4109-b734-14aedc10c93b@I-love.SAKURA.ne.jp>
On Wed, Jun 10, 2026 at 09:48:05PM +0900, Tetsuo Handa wrote:
> After 10 days of untestable period, the third breakage report came from btrfs
> caused by commit 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users").
> That commit added WQ_PERCPU to fs/btrfs/disk-io.c despite the "ordered_flags" is
> passed to alloc_ordered_workqueue() which implicitly applies WQ_UNBOUND.
>
> That commit says
>
> Both flags coexist for one release cycle to allow callers to transition
> their calls.
>
> Once migration is complete, WQ_UNBOUND can be removed and unbound will
> become the implicit default.
>
> and you definitely started emitting WARNING: messages before allowing callers
> to transition their calls. I consider that commit 21c05ca88a54 ("workqueue: Add
> warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present") should be
> excluded from the linux-next and the upcoming merge window. The next one or two
> cycles for transition should be printk() without WARNING: string.
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/
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.
--
Cheers,
Nathan
^ permalink raw reply
* Re: linux-next: manual merge of the ftrace tree with the tip-fixes tree
From: Tomas Glozar @ 2026-06-10 16:47 UTC (permalink / raw)
To: Mark Brown
Cc: Steven Rostedt, Masami Hiramatsu, Costa Shulyupin, Crystal Wood,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <aimDwlNq_RRLjg6X@sirena.co.uk>
st 10. 6. 2026 v 17:43 odesílatel Mark Brown <broonie@kernel.org> napsal:
>
> Hi all,
>
> Today's linux-next merge of the ftrace tree got conflicts in:
>
> tools/tracing/rtla/src/common.c
> tools/tracing/rtla/src/common.h
> tools/tracing/rtla/src/osnoise_hist.c
> tools/tracing/rtla/src/osnoise_top.c
> tools/tracing/rtla/src/timerlat_hist.c
> tools/tracing/rtla/src/timerlat_top.c
>
> between commit:
>
> e9e41d3035032e ("rtla: Fix parsing of multi-character short options")
>
> from the tip-fixes tree and commits:
>
> 704fe8f3d97bba ("tools/rtla: Fix --dump-tasks usage in timerlat")
> f03a59f949176c ("rtla: Stop the record trace on interrupt")
> 5d9af63e80b5a2 ("rtla: Parse cmdline using libsubcmd")
> 03d745b9843560 ("rtla/timerlat: Add -A/--aligned CLI option")
>
> from the ftrace tree.
Good catch. It's actually a fix for 7.1 from our tree
(linux-trace/tools-fixes) and 7.2 queued patches from another of our
trees (linux-trace/tools-for-next). It appears that tip-fixes is based
on master, which is where the tools-fixes commit came from.
>
> 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.
>
The conflict was because I fixed a regression in 7.0/7.1 in code that
will be removed in 7.2. So it only needs at most a note to the pull
request in the 7.2 merge window, I think.
> [truncated huge diff]
Looks correct:
$ git diff rtla-v7.2 next/master tools/tracing/rtla
$
Tests pass on linux-next/master. Thanks!
Tomas
^ permalink raw reply
* linux-next: Tree for Jun 10
From: Mark Brown @ 2026-06-10 15:53 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
Hi all,
Changes since 20260609:
The hwmon-staging tree gained a build failure, I used the version from
next-20260609 instead.
The ftrace tree acquired a conflict with the tip-fixes tree.
The pinctrl tree introduced a failure in the final build.
Non-merge commits (relative to Linus' tree): 11798
12748 files changed, 785763 insertions(+), 238876 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
* linux-next: build failure in the final build
From: Mark Brown @ 2026-06-10 15:51 UTC (permalink / raw)
To: Ajay Kumar Nandam, Linus Walleij
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 512 bytes --]
Hi all,
In the final build, today's linux-next build (arm64 allyesconfig)
failed like this:
/tmp/next/build/drivers/pinctrl/qcom/pinctrl-lpass-lpi.c:82:12: error: 'lpi_gpio_write' defined but not used [-Werror=unused-function]
82 | static int lpi_gpio_write(struct lpi_pinctrl *state, unsigned int pin,
| ^~~~~~~~~~~~~~
cc1: all warnings being treated as errors make[6]:
The failure also shows up in a defconfig build but that doesn't enable
-Werror. I have ignored this issue for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox