* linux-next: manual merge of the bpf-next tree with the net tree
From: Mark Brown @ 2026-07-21 13:46 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Jakub Kicinski, Jordan Rife, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/filter.c
between commit:
3f4920d165b29 ("bpf: Reject redirect helpers without a bpf_net_context")
from the net tree and commit:
509ca545d4255 ("bpf: Support BPF_F_EGRESS with bpf_redirect_peer")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc net/core/filter.c
index 11bb0d236822a,0b7afdd0ae474..0000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -2575,13 -2578,12 +2580,13 @@@ static const struct bpf_func_proto bpf_
BPF_CALL_2(bpf_redirect_peer, u32, ifindex, u64, flags)
{
- struct bpf_redirect_info *ri = bpf_net_ctx_get_ri();
+ struct bpf_redirect_info *ri;
- if (unlikely(!bpf_net_ctx_get() || flags))
- if (unlikely(flags & ~BPF_F_EGRESS))
++ if (unlikely(!bpf_net_ctx_get() || flags & ~BPF_F_EGRESS))
return TC_ACT_SHOT;
+ ri = bpf_net_ctx_get_ri();
- ri->flags = BPF_F_PEER;
+ ri->flags = BPF_F_PEER | flags;
ri->tgt_index = ifindex;
return TC_ACT_REDIRECT;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Missing signoff in the kvm-arm-fixes tree
From: Mark Brown @ 2026-07-21 13:37 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-kernel, linux-next
In-Reply-To: <86wluoeek4.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 655 bytes --]
On Tue, Jul 21, 2026 at 01:02:19PM +0100, Marc Zyngier wrote:
> BTW, could you please Cc the actual maintainers of KVM/arm64?
> Christoffer has been out of that look for over 7 years now...
Of course, I did think that - just to confirm, that's you and Oliver
(with oupton@kernel.org as his address) since AIUI it's you two that
manage the git tree? Usually it's the people with write access in the
contacts list, but I can add whoever you like pretty much.
-next has it's own contacts database since there's frequent enough
divergence and I figured there must be some reason it was that way given
how long it's been. I guess it's just bitrot though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Lorenzo Stoakes (ARM) @ 2026-07-21 12:39 UTC (permalink / raw)
To: Mike Rapoport
Cc: Borislav Petkov, syzbot, Denis V. Lunev, Vishal Moola,
dave.hansen, hpa, linux-kernel, linux-next, luto, mingo, peterz,
sfr, syzkaller-bugs, tglx, x86
In-Reply-To: <al9LYQPufAfqvMYT@kernel.org>
On Tue, Jul 21, 2026 at 01:35:13PM +0300, Mike Rapoport wrote:
> On Mon, Jul 20, 2026 at 07:24:48PM -0700, Borislav Petkov wrote:
> > Adding all folks who touched this recently.
>
> You forgot Lorenzo ;-)
Yup :) thanks.
OK so this is a screw up with merging.
Two fixes are applied at once here and they are NOT compatible :)
Denis's ([0]) holds a spin lock over the operation during which an older
revision of mine ([1] - current, probable next revision [2]) tries to take a
sleeping mmap lock, hence the report.
But actually my + Denis's fixes, with the latest revision of mine ([2]) are fine
- as I take the mmap lock prior to any spin locks being taken in the (newly
renamed) __cpa_collapse_large_pages().
TL;DR - not a real issue and next will get fixed when the newer version of my
series is taken (with sensible coflict resolution).
And in fact I can see it's fixed at -next master anyway :)
I think actually my + Denis's fixes are actually potentially complimentary, will
reply on that thread about that.
Cheers, Lorenzo
[0]:https://lore.kernel.org/all/20260626163213.2284080-1-den@openvz.org/
[1]:https://lore.kernel.org/linux-mm/20260716-series-vmap-race-fix-v4-0-8c108c4317df@kernel.org/
[2]:https://lore.kernel.org/all/20260714-series-vmap-race-fix-v3-0-b812eccfa0f9@kernel.org/
>
> > On Mon, Jul 20, 2026 at 09:59:25AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: 1a1757b76427 Add linux-next specific files for 20260716
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16c734b9580000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=8d1a274c57796a86
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=ee7ecfcd0e3f185e835a
> > > compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/923ee89ba238/disk-1a1757b7.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/cb34d1bf205c/vmlinux-1a1757b7.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/bf183d434c82/bzImage-1a1757b7.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+ee7ecfcd0e3f185e835a@syzkaller.appspotmail.com
> > >
> > > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> > > kfence: initialized - using 2097152 bytes for 255 objects at 0xffff88823be00000-0xffff88823c000000
> > > Console: colour VGA+ 80x25
> > > printk: legacy console [ttyS0] enabled
> > > printk: legacy console [ttyS0] enabled
> > > printk: legacy bootconsole [earlyser0] disabled
> > > printk: legacy bootconsole [earlyser0] disabled
> > > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> > > ... MAX_LOCKDEP_SUBCLASSES: 8
> > > ... MAX_LOCK_DEPTH: 48
> > > ... MAX_LOCKDEP_KEYS: 8192
> > > ... CLASSHASH_SIZE: 4096
> > > ... MAX_LOCKDEP_ENTRIES: 1048576
> > > ... MAX_LOCKDEP_CHAINS: 1048576
> > > ... CHAINHASH_SIZE: 524288
> > > memory used by lock dependency info: 106625 kB
> > > memory used for stack traces: 8320 kB
> > > per task-struct memory footprint: 1920 bytes
> > > mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
> > > ACPI: Core revision 20260408
> > > APIC: Switch to symmetric I/O mode setup
> > > x2apic enabled
> > > APIC: Switched APIC routing to: physical x2apic
> > > ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
> > > clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb63109b96, max_idle_ns: 440795265316 ns
> > > Calibrating delay loop (skipped) preset value.. 4399.99 BogoMIPS (lpj=21999980)
> > > Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
> > > Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4
> > > mitigations: Enabled attack vectors: user_kernel, user_user, guest_host, guest_guest, SMT mitigations: auto
> > > Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
> > > Spectre V2 : Mitigation: IBRS
> > > RETBleed: Mitigation: IBRS
> > > ITS: Mitigation: Aligned branch/return thunks
> > > Spectre V2 : User space: Mitigation: STIBP via prctl
> > > MDS: Mitigation: Clear CPU buffers
> > > TAA: Mitigation: Clear CPU buffers
> > > MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode
> > > Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
> > > Spectre V2 : Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT
> > > Spectre V2 : Enabling IBPB for BPF
> > > Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
> > > active return thunk: its_return_thunk
> > > Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall and VM exit
> > > x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> > > x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> > > x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> > > x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> > > x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> > >
> > > =============================
> > > [ BUG: Invalid wait context ]
> > > syzkaller #0 Not tainted
> > > -----------------------------
> > > swapper/0/0 is trying to lock:
> > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > > other info that might help us debug this:
> > > context-{5:5}
> > > locks held by swapper/0/0: 1, last CPU#0:
> > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
> > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:421 [inline]
> > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: change_page_attr_set_clr+0x967/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > > stack backtrace:
> > > CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/25/2026
> > > Call Trace:
> > > <TASK>
> > > dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
> > > print_lock_invalid_wait_context kernel/locking/lockdep.c:4846 [inline]
> > > check_wait_context kernel/locking/lockdep.c:4918 [inline]
> > > __lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5204
> > > lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5906
> > > down_read+0x4a/0x330 kernel/locking/rwsem.c:1574
> > > mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> > > class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> > > cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> > > cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > > change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > > set_memory_rox+0xbe/0x100 arch/x86/mm/pat/set_memory.c:2341
> > > its_pages_protect arch/x86/kernel/alternative.c:168 [inline]
> > > its_fini_core arch/x86/kernel/alternative.c:175 [inline]
> > > alternative_instructions+0x95/0x100 arch/x86/kernel/alternative.c:2264
> > > arch_cpu_finalize_init+0xb2/0x1f0 arch/x86/kernel/cpu/common.c:2633
> > > start_kernel+0x310/0x3e0 init/main.c:1153
> > > x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
> > > x86_64_start_kernel+0x137/0x1b0 arch/x86/kernel/head64.c:291
> > > common_startup_64+0x13e/0x157
> > > </TASK>
> > > pid_max: default: 32768 minimum: 301
> > > landlock: Up and running.
> > > Yama: becoming mindful.
> > > TOMOYO Linux initialized
> > > AppArmor: AppArmor initialized
> > > LSM support for eBPF active
> > > Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, vmalloc hugepage)
> > > Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
> > > Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> > > Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> > > VFS: Finished mounting rootfs on nullfs
> > > Running RCU synchronous self tests
> > > Running RCU synchronous self tests
> > > numa_add_cpu cpu 1 node 0: mask now 0-1
> > > numa_add_cpu cpu 1 node 1: mask now 0-1
> > >
> > >
> > > ---
> > > This report is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkaller@googlegroups.com.
> > >
> > > syzbot will keep track of this issue. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > >
> > > If the report is already addressed, let syzbot know by replying with:
> > > #syz fix: exact-commit-title
> > >
> > > If you want to overwrite report's subsystems, reply with:
> > > #syz set subsystems: new-subsystem
> > > (See the list of subsystem names on the web dashboard)
> > >
> > > If the report is a duplicate of another one, reply with:
> > > #syz dup: exact-subject-of-another-report
> > >
> > > If you want to undo deduplication, reply with:
> > > #syz undup
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > https://people.kernel.org/tglx/notes-about-netiquette
>
> --
> Sincerely yours,
> Mike.
^ permalink raw reply
* Re: Missing signoff in the kvm-arm-fixes tree
From: Marc Zyngier @ 2026-07-21 12:02 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-kernel, linux-next
In-Reply-To: <al9cA4bfywF11OmQ@sirena.org.uk>
On Tue, 21 Jul 2026 12:46:11 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> [1 <text/plain; us-ascii (7bit)>]
> Commit
>
> 6c13643a6f392 ("KVM: arm64: Fix hyp_trace clock disabling")
>
> is missing a Signed-off-by from its committer
Amusing:
maz@valley-girl:~/hot-poop/arm-platforms$ b4 am -lsto - 20260715105100.3178255-1-vdonnefort@google.com | git am
Grabbing thread from lore.kernel.org/all/20260715105100.3178255-1-vdonnefort@google.com/t.mbox.gz
Analyzing 4 messages in the thread
Looking for additional code-review trailers on lore.kernel.org
Analyzing 0 code-review messages
Checking attestation on all messages, may take a moment...
---
✓ [PATCH v2] KVM: arm64: Fix hyp_trace clock disabling
+ Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> (✓ DKIM/linux.dev)
+ Link: https://patch.msgid.link/20260715105100.3178255-1-vdonnefort@google.com
+ Signed-off-by: Marc Zyngier <maz@kernel.org>
---
✓ Signed: DKIM/google.com
---
Total patches: 1
---
Link: https://patch.msgid.link/20260715105100.3178255-1-vdonnefort@google.com
Base: using specified base-commit a13c140cc289c0b7b3770bce5b3ad42ab35074aa
git checkout -b v2_20260715_vdonnefort_google_com a13c140cc289c0b7b3770bce5b3ad42ab35074aa
Applying: KVM: arm64: Fix hyp_trace clock disabling
maz@valley-girl:~/hot-poop/arm-platforms$ git show
commit ffb57162cb4e20971ea41320f8dd9fad7d141e9f (HEAD)
Author: Vincent Donnefort <vdonnefort@google.com>
Date: Wed Jul 15 11:51:00 2026 +0100
KVM: arm64: Fix hyp_trace clock disabling
Fix the disable path in hyp_trace_clock_enable(), which fell through to
re-initialize and reschedule the clock after cancelling the work. Return
early instead.
While at it, cleanup hyp_trace_clock::lock which is unused and
hyp_trace_clock::running which is redundant: the trace_remote framework
already serializes calls to the callback enable_tracing.
Fixes: b22888917fa4 ("KVM: arm64: Sync boot clock with the nVHE/pKVM hyp")
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
No RB, no SoB, no Link. Guess b4 is busted in some way...
BTW, could you please Cc the actual maintainers of KVM/arm64?
Christoffer has been out of that look for over 7 years now...
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-21 11:48 UTC (permalink / raw)
To: Alexander Potapenko, Aleksandr Nogikh
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <CAG_fn=Vf==zhGjSNPcFC0=n9cw+NrBp+AqXgcmcV0uQBAcL9TA@mail.gmail.com>
On 2026/07/21 18:38, Alexander Potapenko wrote:
> Hi Tetsuo,
>
> You can send patches to syzbot@lists.linux.dev.
>
> E.g. I ran
>
> $ git send-email --suppress-cc=all --to=syzbot@lists.linux.dev
> patches/kcov-tetsuo-v7/0001-kcov-fix-data-corruption-and-race-conditions-on-PREE.patch
>
> to test your latest kcov patch and got the results here:
> https://ci.syzbot.org/series/33930a89-bb2a-4c5a-b6c5-d45829d5c94c
>
> The fuzzing ran on 8 VMs for 3 hours, and there were no new reports.
>
> Please let us know what you think of this workflow.
Unfortunately, 8 VMs for 3 hours would be too little to stop my linux-next only patches.
syzbot took more than one month in linux-next until I was able to report
https://lkml.kernel.org/r/73ed3aa5-f6e1-47b6-9e5d-428ac1f4cbf3@I-love.SAKURA.ne.jp .
I could have reported within 24 hours if all VMs (I don't know how many VMs are assigned)
for networking trees were tested with my linux-next only patch.
syzbot was not able to trigger
"BUG: %s/%u is doing I/O request on loop%d in Lo_rundown state.\n" message
using https://lkml.kernel.org/r/30ccdd3c-6353-4a0f-bdc7-230ec3bf4765@I-love.SAKURA.ne.jp
in linux-next tree. syzbot could have triggered this message within 24 hours if all VMs
for upstream trees were tested with my linux-next only patch.
What I want is a workflow that can test with patches for many days and many VMs.
^ permalink raw reply
* Unexpected files in the drm-misc tree
From: Mark Brown @ 2026-07-21 11:46 UTC (permalink / raw)
To: Simona Vetter, Intel Graphics, DRI; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 154 bytes --]
Commit
ac3baea883dab ("drm/panel: find_panel_by_fwnode() return a counted reference")
added this unexpected file:
drivers/gpu/drm/drm_panel.c.orig
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Missing signoff in the kvm-arm-fixes tree
From: Mark Brown @ 2026-07-21 11:46 UTC (permalink / raw)
To: Christoffer Dall, Marc Zyngier; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 117 bytes --]
Commit
6c13643a6f392 ("KVM: arm64: Fix hyp_trace clock disabling")
is missing a Signed-off-by from its committer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the kvm-fixes tree
From: Mark Brown @ 2026-07-21 11:46 UTC (permalink / raw)
To: Paolo Bonzini, KVM; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
In commit
e800decd9c0ac ("KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN")
Fixes tag
Fixes: ae95f566b3d2 ("KVM: X86: TSCDEADLINE MSR emulation fastpath", 2020-05-15)
has these problem(s):
- Subject has leading but no trailing quotes
- 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: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Mike Rapoport @ 2026-07-21 10:35 UTC (permalink / raw)
To: Borislav Petkov, Lorenzo Stoakes
Cc: syzbot, Denis V. Lunev, Vishal Moola, dave.hansen, hpa,
linux-kernel, linux-next, luto, mingo, peterz, sfr,
syzkaller-bugs, tglx, x86
In-Reply-To: <20260721022448.GDal7YcN_64rndpnHI@fat_crate.local>
On Mon, Jul 20, 2026 at 07:24:48PM -0700, Borislav Petkov wrote:
> Adding all folks who touched this recently.
You forgot Lorenzo ;-)
> On Mon, Jul 20, 2026 at 09:59:25AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 1a1757b76427 Add linux-next specific files for 20260716
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16c734b9580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=8d1a274c57796a86
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ee7ecfcd0e3f185e835a
> > compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/923ee89ba238/disk-1a1757b7.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/cb34d1bf205c/vmlinux-1a1757b7.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/bf183d434c82/bzImage-1a1757b7.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+ee7ecfcd0e3f185e835a@syzkaller.appspotmail.com
> >
> > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> > kfence: initialized - using 2097152 bytes for 255 objects at 0xffff88823be00000-0xffff88823c000000
> > Console: colour VGA+ 80x25
> > printk: legacy console [ttyS0] enabled
> > printk: legacy console [ttyS0] enabled
> > printk: legacy bootconsole [earlyser0] disabled
> > printk: legacy bootconsole [earlyser0] disabled
> > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> > ... MAX_LOCKDEP_SUBCLASSES: 8
> > ... MAX_LOCK_DEPTH: 48
> > ... MAX_LOCKDEP_KEYS: 8192
> > ... CLASSHASH_SIZE: 4096
> > ... MAX_LOCKDEP_ENTRIES: 1048576
> > ... MAX_LOCKDEP_CHAINS: 1048576
> > ... CHAINHASH_SIZE: 524288
> > memory used by lock dependency info: 106625 kB
> > memory used for stack traces: 8320 kB
> > per task-struct memory footprint: 1920 bytes
> > mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
> > ACPI: Core revision 20260408
> > APIC: Switch to symmetric I/O mode setup
> > x2apic enabled
> > APIC: Switched APIC routing to: physical x2apic
> > ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
> > clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb63109b96, max_idle_ns: 440795265316 ns
> > Calibrating delay loop (skipped) preset value.. 4399.99 BogoMIPS (lpj=21999980)
> > Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
> > Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4
> > mitigations: Enabled attack vectors: user_kernel, user_user, guest_host, guest_guest, SMT mitigations: auto
> > Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
> > Spectre V2 : Mitigation: IBRS
> > RETBleed: Mitigation: IBRS
> > ITS: Mitigation: Aligned branch/return thunks
> > Spectre V2 : User space: Mitigation: STIBP via prctl
> > MDS: Mitigation: Clear CPU buffers
> > TAA: Mitigation: Clear CPU buffers
> > MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode
> > Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
> > Spectre V2 : Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT
> > Spectre V2 : Enabling IBPB for BPF
> > Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
> > active return thunk: its_return_thunk
> > Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall and VM exit
> > x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> > x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> > x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> > x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> > x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> >
> > =============================
> > [ BUG: Invalid wait context ]
> > syzkaller #0 Not tainted
> > -----------------------------
> > swapper/0/0 is trying to lock:
> > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > other info that might help us debug this:
> > context-{5:5}
> > locks held by swapper/0/0: 1, last CPU#0:
> > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
> > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:421 [inline]
> > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: change_page_attr_set_clr+0x967/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > stack backtrace:
> > CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/25/2026
> > Call Trace:
> > <TASK>
> > dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
> > print_lock_invalid_wait_context kernel/locking/lockdep.c:4846 [inline]
> > check_wait_context kernel/locking/lockdep.c:4918 [inline]
> > __lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5204
> > lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5906
> > down_read+0x4a/0x330 kernel/locking/rwsem.c:1574
> > mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> > class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> > cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> > cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> > change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> > set_memory_rox+0xbe/0x100 arch/x86/mm/pat/set_memory.c:2341
> > its_pages_protect arch/x86/kernel/alternative.c:168 [inline]
> > its_fini_core arch/x86/kernel/alternative.c:175 [inline]
> > alternative_instructions+0x95/0x100 arch/x86/kernel/alternative.c:2264
> > arch_cpu_finalize_init+0xb2/0x1f0 arch/x86/kernel/cpu/common.c:2633
> > start_kernel+0x310/0x3e0 init/main.c:1153
> > x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
> > x86_64_start_kernel+0x137/0x1b0 arch/x86/kernel/head64.c:291
> > common_startup_64+0x13e/0x157
> > </TASK>
> > pid_max: default: 32768 minimum: 301
> > landlock: Up and running.
> > Yama: becoming mindful.
> > TOMOYO Linux initialized
> > AppArmor: AppArmor initialized
> > LSM support for eBPF active
> > Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, vmalloc hugepage)
> > Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
> > Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> > Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> > VFS: Finished mounting rootfs on nullfs
> > Running RCU synchronous self tests
> > Running RCU synchronous self tests
> > numa_add_cpu cpu 1 node 0: mask now 0-1
> > numa_add_cpu cpu 1 node 1: mask now 0-1
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> >
> > If the report is already addressed, let syzbot know by replying with:
> > #syz fix: exact-commit-title
> >
> > If you want to overwrite report's subsystems, reply with:
> > #syz set subsystems: new-subsystem
> > (See the list of subsystem names on the web dashboard)
> >
> > If the report is a duplicate of another one, reply with:
> > #syz dup: exact-subject-of-another-report
> >
> > If you want to undo deduplication, reply with:
> > #syz undup
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Alexander Potapenko @ 2026-07-21 9:38 UTC (permalink / raw)
To: Tetsuo Handa, Aleksandr Nogikh
Cc: Boqun Feng, Gary Guo, Mark Brown, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <2d0d3f6b-4392-4081-9390-9b588e38de7a@I-love.SAKURA.ne.jp>
On Mon, Jul 20, 2026 at 12:06 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2026/07/04 21:06, Miguel Ojeda wrote:
> > I understand it may be nice to use such resources, but the solution is
> > to talk to both sides, as you do in that thread. From what I see, they
> > even offered to add a mailing list for those patches:
> >
> > "Aleksandr says we can create a special mailing list to test draft
> > patches, so the series sent to that list is fuzzed for some time,
> > similarly to how upstream patch testing works now.
> > Do you think that would help you to debug these issues? "
> >
> > So what happened with that? It seems there was a way forward there,
> > no? (Cc'ing Alexander from that thread)
>
> Alexander, was there any progress?
>
Hi Tetsuo,
You can send patches to syzbot@lists.linux.dev.
E.g. I ran
$ git send-email --suppress-cc=all --to=syzbot@lists.linux.dev
patches/kcov-tetsuo-v7/0001-kcov-fix-data-corruption-and-race-conditions-on-PREE.patch
to test your latest kcov patch and got the results here:
https://ci.syzbot.org/series/33930a89-bb2a-4c5a-b6c5-d45829d5c94c
The fuzzing ran on 8 VMs for 3 hours, and there were no new reports.
Please let us know what you think of this workflow.
^ permalink raw reply
* Re: linux-next: manual merge of the char-misc tree with the char-misc.current tree
From: Alice Ryhl @ 2026-07-21 8:28 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Arnd Bergmann, Greg Kroah-Hartman, Jahnavi MN,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <al40WiyRukYGQ68S@sirena.org.uk>
On Mon, Jul 20, 2026 at 03:44:42PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/android/binder/thread.rs
>
> between commit:
>
> bb66b1a345253 ("rust_binder: only print failure if error has source")
>
> from the char-misc.current tree and commit:
>
> c61f3ad2213cf ("rust_binder: Implement BINDER_DEBUG_FAILED_TRANSACTION")
>
> from the char-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/android/binder/thread.rs
> index bc0ef8927905c,a51821dde0adf..0000000000000
> --- a/drivers/android/binder/thread.rs
> +++ b/drivers/android/binder/thread.rs
> @@@ -1273,14 -1295,25 +1295,24 @@@ impl Thread
> inner.extended_error =
> ExtendedError::new(info.debug_id as u32, err.reply, source.to_errno());
> }
> - }
>
> - pr_warn!(
> - "{}:{} transaction to {} failed: {err:?}",
> - info.from_pid,
> - info.from_tid,
> - info.to_pid
> - binder_debug!(
> - FailedTransaction,
> - "transaction {} to {}:{} failed {:?}, code {} size {}-{}",
> - if info.is_reply {
> - "reply"
> - } else if info.is_oneway() {
> - "async"
> - } else {
> - "call"
> - },
> - info.to_pid,
> - info.to_tid,
> - err,
> - info.code,
> - info.data_size,
> - info.offsets_size
> - );
> ++ binder_debug!(
> ++ FailedTransaction,
> ++ "transaction {} to {}:{} failed {:?}, code {} size {}-{}",
> ++ if info.is_reply {
> ++ "reply"
> ++ } else if info.is_oneway() {
> ++ "async"
> ++ } else {
> ++ "call"
> ++ },
> ++ info.to_pid,
> ++ info.to_tid,
> ++ err,
> ++ info.code,
> ++ info.data_size,
> ++ info.offsets_size
> + );
> - }
> }
> }
I think you're missing a closing } after the binder_debug! call.
Otherwise LGTM.
error: this file contains an unclosed delimiter
--> drivers/android/binder/thread.rs:1743:3
|
453 | impl Thread {
| - unclosed delimiter
...
1290 | if let Some(source) = &err.source {
| - this delimiter might not be properly closed...
...
1316 | }
| - ...as it matches this but it has different indentation
...
1743 | }
| ^
error: aborting due to 1 previous error
Alice
^ permalink raw reply
* Re: linux-next: manual merge of the char-misc tree with the security tree
From: Alice Ryhl @ 2026-07-21 8:18 UTC (permalink / raw)
To: Paul Moore
Cc: Mark Brown, Greg KH, Arnd Bergmann, Greg Kroah-Hartman,
Jahnavi MN, Jann Horn, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <CAHC9VhQAYWzzcd6KnbCg+nNAfSHVBetgOnzd5axnL2_6E+wL5g@mail.gmail.com>
On Mon, Jul 20, 2026 at 06:45:23PM -0400, Paul Moore wrote:
> On Mon, Jul 20, 2026 at 10:48 AM Mark Brown <broonie@kernel.org> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the char-misc tree got a conflict in:
> >
> > rust/kernel/task.rs
> >
> > between commits:
> >
> > ef2d3e4635761 ("rust: task: clarify comments on task UID accessors")
> > 15c1f17979712 ("cred: delete task_euid()")
> >
> > from the security tree and commit:
> >
> > 2847d9ab088bb ("rust_binder: Add dynamic debug logging mask")
> >
> > from the char-misc tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > diff --cc rust/kernel/task.rs
> > index c2b3457b700c1,1b290c61714db..0000000000000
> > --- a/rust/kernel/task.rs
> > +++ b/rust/kernel/task.rs
> > @@@ -210,7 -210,14 +210,14 @@@ impl Task
> > unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
> > }
> >
> > + /// Returns the TGID (Thread Group ID / Process ID) of the given task.
> > + pub fn tgid(&self) -> Pid {
> > + // SAFETY: The tgid of a task never changes after initialization, so reading this field is
> > + // not a data race.
> > + unsafe { *ptr::addr_of!((*self.as_ptr()).tgid) }
> > + }
> > +
> > - /// Returns the UID of the given task.
> > + /// Returns the objective real UID of the given task.
> > #[inline]
> > pub fn uid(&self) -> Kuid {
> > // SAFETY: It's always safe to call `task_uid` on a valid task.
>
> Thanks Mark, that fixup looks reasonable to me.
Looks good to me as well.
Alice
^ permalink raw reply
* Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree
From: Matthew Brost @ 2026-07-21 6:06 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Brown, Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Hugh Dickins, Baolin Wang, linux-mm
In-Reply-To: <20260721045416.GA6737@lst.de>
On Tue, Jul 21, 2026 at 06:54:16AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 20, 2026 at 02:58:34PM -0700, Matthew Brost wrote:
> > Do you have a suggestion of what parts to move over to shmem.c?
> >
> > Pretty much all of this?
>
> That's my first guess. Basically when using a shmem folio to store
> data we should have the code dealing with it contained in the shmem
> code except for well-defined APIs.
>
After quickly typing something - I'm landing on basically everything in
shmem.c.
> > I can take a look at this in a follow up?
>
> That would be great.
Will share something shortly.
Matt
^ permalink raw reply
* Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree
From: Christoph Hellwig @ 2026-07-21 4:54 UTC (permalink / raw)
To: Matthew Brost
Cc: Christoph Hellwig, Mark Brown, Andrew Morton,
Linux Kernel Mailing List, Linux Next Mailing List, Hugh Dickins,
Baolin Wang, linux-mm
In-Reply-To: <al6aCizqqilqQGZ4@gsse-cloud1.jf.intel.com>
On Mon, Jul 20, 2026 at 02:58:34PM -0700, Matthew Brost wrote:
> Do you have a suggestion of what parts to move over to shmem.c?
>
> Pretty much all of this?
That's my first guess. Basically when using a shmem folio to store
data we should have the code dealing with it contained in the shmem
code except for well-defined APIs.
> I can take a look at this in a follow up?
That would be great.
^ permalink raw reply
* [STATUS] next/master - 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603
From: KernelCI bot @ 2026-07-21 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/3fe08b9796f36ef437ab9328e7dd1e5ff2d66603/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603
origin: maestro
test start time: 2026-07-20 16:58:07.112000+00:00
Builds: 71 ✅ 2 ❌ 0 ⚠️
Boots: 150 ✅ 2 ❌ 0 ⚠️
Tests: 28133 ✅ 2506 ❌ 6635 ⚠️
### POSSIBLE REGRESSIONS
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a5e8af875cb84fb216772c5
history: > ✅ > ✅ > ❌
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a5e8c3875cb84fb2167ce41
history: > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5e8f1475cb84fb2167f8f4
history: > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_dsi_9ac0000_panel_0
last run: https://d.kernelci.org/test/maestro:6a5e8f1475cb84fb2167f8ee
history: > ✅ > ✅ > ❌
Hardware: mt8395-genio-1200-evk
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a5e913f75cb84fb21682225
history: > ✅ > ✅ > ✅ > ✅ > ❌
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a5ea33775cb84fb2168f78f
history: > ✅ > ✅ > ✅ > ✅ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21693004
history: > ✅ > ❌ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5e8b0775cb84fb21677506
history: > ✅ > ❌ > ❌
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a5e8cbc75cb84fb2167da79
history: > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5e8eb375cb84fb2167e4a6
history: > ✅ > ❌ > ❌
Hardware: x1e80100
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5e984e75cb84fb2168b2ba
history: > ✅ > ❌ > ❌
Hardware: bcm2837-rpi-3-b-plus
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device_error_logs
last run: https://d.kernelci.org/test/maestro:6a5e8e1a75cb84fb2167e1cc
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.device_error_logs.devices_error_logs_test_device_error_logs_py
last run: https://d.kernelci.org/test/maestro:6a5ebc8475cb84fb21692f17
history: > ✅ > ✅ > ✅ > ✅ > ❌
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5ea80675cb84fb2169038b
history: > ✅ > ❌ > ❌
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a5e8b8975cb84fb2167c2f7
history: > ✅ > ❌ > ❌
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5e8b0275cb84fb216774e0
history: > ✅ > ❌ > ❌
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a5eb28975cb84fb21691372
history: > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5ebf0d75cb84fb216933b9
history: > ✅ > ❌ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a5e8af475cb84fb21677108
history: > ✅ > ✅ > ❌
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a5e8c7a75cb84fb2167d648
history: > ✅ > ✅ > ❌
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5e8b0475cb84fb216774e4
history: > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5e8ee175cb84fb2167e8fd
history: > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_iommu_3da0000
last run: https://d.kernelci.org/test/maestro:6a5e8ee175cb84fb2167e8b5
history: > ✅ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_crypto_1dfa000
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834d9
history: > ✅ > ❌ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a5e63c675cb84fb216611be
history: > ✅ > ❌ > ❌
### FIXED REGRESSIONS
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5e8b0875cb84fb2167750d
history: > ❌ > ✅
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a5e8d3975cb84fb2167dd12
history: > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a5e8b3b75cb84fb21677e57
history: > ❌ > ❌ > ✅
### UNSTABLE TESTS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_sound-wm8960
last run: https://d.kernelci.org/test/maestro:6a5e95d175cb84fb21689071
history: > ✅ > ❌ > ✅ > ✅ > ✅
Hardware: imx8mp-verdin-nonwifi-dahlia
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_bus_30800000_i2c_30a50000_eeprom_50
last run: https://d.kernelci.org/test/maestro:6a5e981175cb84fb2168afae
history: > ✅ > ✅ > ❌ > ❌ > ✅
Hardware: meson-g12b-a311d-khadas-vim3
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a5e913b75cb84fb21682217
history: > ❌ > ❌ > ❌ > ✅ > ❌
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a5e95b775cb84fb21688e4c
history: > ❌ > ❌ > ❌ > ✅ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_displayport-controller_22154000
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692fff
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_displayport-controller_2215c000
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692ffe
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_phy_220c2a00
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692ffd
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_phy_220c5a00
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692ffc
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692ff8
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af5c000
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692ff6
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692ff0
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec5a00
last run: https://d.kernelci.org/test/maestro:6a5ebc9275cb84fb21692fef
history: > ✅ > ❌ > ✅
Hardware: x1e80100
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.capabilities
last run: https://d.kernelci.org/test/maestro:6a5e8b2675cb84fb21677bc0
history: > ✅ > ❌ > ✅
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_eeprom_50_nvmem-layout
last run: https://d.kernelci.org/test/maestro:6a5ea80675cb84fb21690365
history: > ⚠️ > ✅ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834d0
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834ce
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834cc
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834c6
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834c4
history: > ⚠️ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a80000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb216834a4
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000_pcie_0_wifi_0
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb21683489
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a5e92b375cb84fb21683419
history: > ✅ > ❌ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a5e63a975cb84fb216610e8
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: [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: Borislav Petkov @ 2026-07-21 2:24 UTC (permalink / raw)
To: syzbot, Denis V. Lunev, Mike Rapoport, Vishal Moola
Cc: dave.hansen, hpa, linux-kernel, linux-next, luto, mingo, peterz,
sfr, syzkaller-bugs, tglx, x86
In-Reply-To: <6a5e53ed.f1649fcc.2a4208.0574.GAE@google.com>
Adding all folks who touched this recently.
On Mon, Jul 20, 2026 at 09:59:25AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 1a1757b76427 Add linux-next specific files for 20260716
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16c734b9580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8d1a274c57796a86
> dashboard link: https://syzkaller.appspot.com/bug?extid=ee7ecfcd0e3f185e835a
> compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/923ee89ba238/disk-1a1757b7.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/cb34d1bf205c/vmlinux-1a1757b7.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/bf183d434c82/bzImage-1a1757b7.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ee7ecfcd0e3f185e835a@syzkaller.appspotmail.com
>
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> kfence: initialized - using 2097152 bytes for 255 objects at 0xffff88823be00000-0xffff88823c000000
> Console: colour VGA+ 80x25
> printk: legacy console [ttyS0] enabled
> printk: legacy console [ttyS0] enabled
> printk: legacy bootconsole [earlyser0] disabled
> printk: legacy bootconsole [earlyser0] disabled
> Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> ... MAX_LOCKDEP_SUBCLASSES: 8
> ... MAX_LOCK_DEPTH: 48
> ... MAX_LOCKDEP_KEYS: 8192
> ... CLASSHASH_SIZE: 4096
> ... MAX_LOCKDEP_ENTRIES: 1048576
> ... MAX_LOCKDEP_CHAINS: 1048576
> ... CHAINHASH_SIZE: 524288
> memory used by lock dependency info: 106625 kB
> memory used for stack traces: 8320 kB
> per task-struct memory footprint: 1920 bytes
> mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
> ACPI: Core revision 20260408
> APIC: Switch to symmetric I/O mode setup
> x2apic enabled
> APIC: Switched APIC routing to: physical x2apic
> ..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
> clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb63109b96, max_idle_ns: 440795265316 ns
> Calibrating delay loop (skipped) preset value.. 4399.99 BogoMIPS (lpj=21999980)
> Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
> Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4
> mitigations: Enabled attack vectors: user_kernel, user_user, guest_host, guest_guest, SMT mitigations: auto
> Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
> Spectre V2 : Mitigation: IBRS
> RETBleed: Mitigation: IBRS
> ITS: Mitigation: Aligned branch/return thunks
> Spectre V2 : User space: Mitigation: STIBP via prctl
> MDS: Mitigation: Clear CPU buffers
> TAA: Mitigation: Clear CPU buffers
> MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode
> Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
> Spectre V2 : Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT
> Spectre V2 : Enabling IBPB for BPF
> Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
> active return thunk: its_return_thunk
> Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall and VM exit
> x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
> x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
>
> =============================
> [ BUG: Invalid wait context ]
> syzkaller #0 Not tainted
> -----------------------------
> swapper/0/0 is trying to lock:
> ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> other info that might help us debug this:
> context-{5:5}
> locks held by swapper/0/0: 1, last CPU#0:
> #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
> #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:421 [inline]
> #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> #0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: change_page_attr_set_clr+0x967/0x1010 arch/x86/mm/pat/set_memory.c:2142
> stack backtrace:
> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/25/2026
> Call Trace:
> <TASK>
> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
> print_lock_invalid_wait_context kernel/locking/lockdep.c:4846 [inline]
> check_wait_context kernel/locking/lockdep.c:4918 [inline]
> __lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5204
> lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5906
> down_read+0x4a/0x330 kernel/locking/rwsem.c:1574
> mmap_read_lock include/linux/mmap_lock.h:600 [inline]
> class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
> cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
> cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
> change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
> set_memory_rox+0xbe/0x100 arch/x86/mm/pat/set_memory.c:2341
> its_pages_protect arch/x86/kernel/alternative.c:168 [inline]
> its_fini_core arch/x86/kernel/alternative.c:175 [inline]
> alternative_instructions+0x95/0x100 arch/x86/kernel/alternative.c:2264
> arch_cpu_finalize_init+0xb2/0x1f0 arch/x86/kernel/cpu/common.c:2633
> start_kernel+0x310/0x3e0 init/main.c:1153
> x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
> x86_64_start_kernel+0x137/0x1b0 arch/x86/kernel/head64.c:291
> common_startup_64+0x13e/0x157
> </TASK>
> pid_max: default: 32768 minimum: 301
> landlock: Up and running.
> Yama: becoming mindful.
> TOMOYO Linux initialized
> AppArmor: AppArmor initialized
> LSM support for eBPF active
> Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, vmalloc hugepage)
> Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
> Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
> VFS: Finished mounting rootfs on nullfs
> Running RCU synchronous self tests
> Running RCU synchronous self tests
> numa_add_cpu cpu 1 node 0: mask now 0-1
> numa_add_cpu cpu 1 node 1: mask now 0-1
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* -next status as at v7.2-rc4
From: Mark Brown @ 2026-07-21 0:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi Linus,
We're getting the peak conflicts phase of development, but not in a
particularly unusual or remarkable manner - things seem to be ticking
along fairly smoothly. There was a bit of faff with things ending up in
-next that shouldn't have been there but that sorted itself out easily
enough, and we had a surprisingly large number of breaks in the final
builds but those are all fixed as of today.
No trees are held at old versions.
Trees with signoff problems:
ntfs3 (missing author)
rdma (missing committer)
Non-merge commits relative to Linus' tree: 7105
6767 files changed, 287833 insertions(+), 107538 deletions(-)
Top trees adding commits to -next:
1307 drm
521 mm-unstable
327 qcom
231 tip
220 sound-asoc
198 net-next
172 v4l-dvb
154 vfs-brauner
152 staging
138 iio
Thanks,
Mark
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Missing signoff in the ntfs3 tree
From: Mark Brown @ 2026-07-21 0:08 UTC (permalink / raw)
To: Konstantin Komarov; +Cc: linux-kernel, linux-next
In-Reply-To: <aldqIGRdMoJgNkER@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Wed, Jul 15, 2026 at 12:08:16PM +0100, Mark Brown wrote:
> Commit
>
> f023839df8010 ("fs/ntfs3: fix out-of-bounds read of INDEX_ROOT in reparse/objid init")
>
> is missing a Signed-off-by from its author
This issue is still present today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 20
From: Mark Brown @ 2026-07-20 23:55 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi all,
Changes since 20260717:
The mm-unstable tree acquired a conflict with the drm-misc-fixes tree.
The qcom tree lost it's build failure.
The rdma tree acquired a conflict with the origin tree.
The drm tree acquired multiple conflicts with the origin tree.
The drm-xe tree acquired a conflict with the origin tree.
The char-misc tree acquired multiple conflicts with the char-misc.current tree.
The char-misc tree acquired a conflict with the security tree.
The nvmem tree acquired a conflict with the char-misc tree.
Non-merge commits (relative to Linus' tree): 7105
6767 files changed, 287833 insertions(+), 107538 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 429 trees (counting Linus' and 133 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the char-misc tree with the security tree
From: Paul Moore @ 2026-07-20 22:45 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Arnd Bergmann, Alice Ryhl, Greg Kroah-Hartman,
Jahnavi MN, Jann Horn, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <al41SRxNtHYU5coA@sirena.org.uk>
On Mon, Jul 20, 2026 at 10:48 AM Mark Brown <broonie@kernel.org> wrote:
>
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> rust/kernel/task.rs
>
> between commits:
>
> ef2d3e4635761 ("rust: task: clarify comments on task UID accessors")
> 15c1f17979712 ("cred: delete task_euid()")
>
> from the security tree and commit:
>
> 2847d9ab088bb ("rust_binder: Add dynamic debug logging mask")
>
> from the char-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc rust/kernel/task.rs
> index c2b3457b700c1,1b290c61714db..0000000000000
> --- a/rust/kernel/task.rs
> +++ b/rust/kernel/task.rs
> @@@ -210,7 -210,14 +210,14 @@@ impl Task
> unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
> }
>
> + /// Returns the TGID (Thread Group ID / Process ID) of the given task.
> + pub fn tgid(&self) -> Pid {
> + // SAFETY: The tgid of a task never changes after initialization, so reading this field is
> + // not a data race.
> + unsafe { *ptr::addr_of!((*self.as_ptr()).tgid) }
> + }
> +
> - /// Returns the UID of the given task.
> + /// Returns the objective real UID of the given task.
> #[inline]
> pub fn uid(&self) -> Kuid {
> // SAFETY: It's always safe to call `task_uid` on a valid task.
Thanks Mark, that fixup looks reasonable to me.
--
paul-moore.com
^ permalink raw reply
* Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree
From: Matthew Brost @ 2026-07-20 22:08 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Christoph Hellwig, Mark Brown, Andrew Morton,
Linux Kernel Mailing List, Linux Next Mailing List, Hugh Dickins,
Baolin Wang, linux-mm, Christian Koenig, Huang Rui, dri-devel
In-Reply-To: <al40qCMTxhEP3Kx8@casper.infradead.org>
On Mon, Jul 20, 2026 at 03:46:00PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 20, 2026 at 04:41:41PM +0200, Christoph Hellwig wrote:
> > > /**
> > > - * ttm_backup_backup_page() - Backup a page
> > > + * ttm_backup_backup_folio() - Backup a folio
> > > * @backup: The struct backup pointer to use.
> > > - * @page: The page to back up.
> > > - * @writeback: Whether to perform immediate writeback of the page.
> > > + * @folio: The folio to back up.
> > > + * @order: The allocation order of @folio. Since TTM allocates higher-order
> > > + * pages without __GFP_COMP, folio_nr_pages(@folio) would always
> > > + * return 1; the caller must pass the true order explicitly.
>
> Wait, what? This is just broken. TTM should change to allocate using
> GFP_COMP. Why can't graphics people ask questions before writing stupid
> patches?
>
To be honest, I have no idea why TTM doesn't set GFP_COMP. This
predates my work in graphics by nearly a decade.
I found the following comment in TTM, which was added in this patch:
`git format-patch -1 bf9eee249ac20`
As far as I can tell, setting GFP_COMP would make things a lot easier in
a number of places.
Christian, who maintains TTM, is out for a couple of weeks, but this is
something we should probably take a closer look at.
Sorry for sending a stupid patch.
Matt
^ permalink raw reply
* Re: linux-next: manual merge of the mm-unstable tree with the drm-misc-fixes tree
From: Matthew Brost @ 2026-07-20 21:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Brown, Andrew Morton, Linux Kernel Mailing List,
Linux Next Mailing List, Hugh Dickins, Baolin Wang, linux-mm
In-Reply-To: <20260720144141.GA16699@lst.de>
On Mon, Jul 20, 2026 at 04:41:41PM +0200, Christoph Hellwig wrote:
> On Mon, Jul 20, 2026 at 02:31:04PM +0100, Mark Brown wrote:
> > Hi all,
> >
> > Today's linux-next merge of the mm-unstable tree got a conflict in:
> >
> > drivers/gpu/drm/ttm/ttm_backup.c
> >
> > between commit:
> >
> > a3fdf74ffa596 ("drm/ttm/pool: back up at native page order")
> >
> > from the drm-misc-fixes tree and commit:
> >
> > c6bfdcf16f131 ("shmem: provide a shmem_write_folio wrapper")
> >
> > from the mm-unstable 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.
>
> Much of the code here really should sit in shmem.c instead of having
> random drivers/subsystems poke into the internals of shmem mappings
> and folios. But I feel like a broken record for saying that again
> and again without any action :(
>
Do you have a suggestion of what parts to move over to shmem.c?
Pretty much all of this? I can take a look at this in a follow up?
Matt
> >
> > diff --combined drivers/gpu/drm/ttm/ttm_backup.c
> > index 3c067aadc52de,c5b813a563e7f..0000000000000
> > --- a/drivers/gpu/drm/ttm/ttm_backup.c
> > +++ b/drivers/gpu/drm/ttm/ttm_backup.c
> > @@@ -6,10 -6,9 +6,10 @@@
> > #include <drm/ttm/ttm_backup.h>
> >
> > #include <linux/export.h>
> > -#include <linux/page-flags.h>
> > #include <linux/swap.h>
> >
> > +#include "ttm_pool_internal.h"
> > +
> > /*
> > * Need to map shmem indices to handle since a handle value
> > * of 0 means error, following the swp_entry_t convention.
> > @@@ -69,23 -68,17 +69,23 @@@ int ttm_backup_copy_page(struct file *b
> > }
> >
> > /**
> > - * ttm_backup_backup_page() - Backup a page
> > + * ttm_backup_backup_folio() - Backup a folio
> > * @backup: The struct backup pointer to use.
> > - * @page: The page to back up.
> > - * @writeback: Whether to perform immediate writeback of the page.
> > + * @folio: The folio to back up.
> > + * @order: The allocation order of @folio. Since TTM allocates higher-order
> > + * pages without __GFP_COMP, folio_nr_pages(@folio) would always
> > + * return 1; the caller must pass the true order explicitly.
> > + * @writeback: Whether to perform immediate writeback of the folio's pages.
> > * This may have performance implications.
> > - * @idx: A unique integer for each page and each struct backup.
> > + * @idx: A unique integer for the first page of the folio and each struct backup.
> > * This allows the backup implementation to avoid managing
> > * its address space separately.
> > - * @page_gfp: The gfp value used when the page was allocated.
> > - * This is used for accounting purposes.
> > + * @folio_gfp: The gfp value used when the folio was allocated.
> > + * Currently unused.
> > * @alloc_gfp: The gfp to be used when allocating memory.
> > + * @nr_pages_backed: Output. On a successful return, set to the number of
> > + * pages actually backed up, which may be less than (1 << @order)
> > + * if an -ENOMEM was encountered mid-folio.
> > *
> > * Context: If called from reclaim context, the caller needs to
> > * assert that the shrinker gfp has __GFP_FS set, to avoid
> > @@@ -94,87 -87,53 +94,87 @@@
> > * that the shrinker gfp has __GFP_IO set, since without it,
> > * we're not allowed to start backup IO.
> > *
> > - * Return: A handle on success. Negative error code on failure.
> > - *
> > - * Note: This function could be extended to back up a folio and
> > - * implementations would then split the folio internally if needed.
> > - * Drawback is that the caller would then have to keep track of
> > - * the folio size- and usage.
> > + * Return: A handle for the first backed-up page on success (handles for
> > + * subsequent pages follow sequentially). -ENOMEM if no pages could be backed
> > + * up. Any other negative error code if a non-ENOMEM failure occurred; in that
> > + * case any pages backed up so far are truncated before returning.
> > */
> > s64
> > -ttm_backup_backup_page(struct file *backup, struct page *page,
> > - bool writeback, pgoff_t idx, gfp_t page_gfp,
> > - gfp_t alloc_gfp)
> > +ttm_backup_backup_folio(struct file *backup, struct folio *folio,
> > + unsigned int order, bool writeback, pgoff_t idx,
> > + gfp_t folio_gfp, gfp_t alloc_gfp,
> > + pgoff_t *nr_pages_backed)
> > {
> > struct address_space *mapping = backup->f_mapping;
> > - unsigned long handle = 0;
> > + int nr_pages = 1 << order;
> > struct folio *to_folio;
> > - int ret;
> > + int ret, i;
> >
> > - to_folio = shmem_read_folio_gfp(mapping, idx, alloc_gfp);
> > - if (IS_ERR(to_folio))
> > - return PTR_ERR(to_folio);
> > + *nr_pages_backed = 0;
> >
> > - folio_mark_accessed(to_folio);
> > - folio_lock(to_folio);
> > - folio_mark_dirty(to_folio);
> > - copy_highpage(folio_file_page(to_folio, idx), page);
> > - handle = ttm_backup_shmem_idx_to_handle(idx);
> > + for (i = 0; i < nr_pages; ) {
> > + int to_nr, j;
> >
> > - if (writeback && !folio_mapped(to_folio) &&
> > - folio_clear_dirty_for_io(to_folio)) {
> > - folio_set_reclaim(to_folio);
> > - ret = shmem_write_folio(to_folio);
> > - if (!folio_test_writeback(to_folio))
> > - folio_clear_reclaim(to_folio);
> > /*
> > - * If writeout succeeds, it unlocks the folio. errors
> > - * are otherwise dropped, since writeout is only best
> > - * effort here.
> > + * Only inject past the first subpage so *nr_pages_backed is
> > + * always > 0 here, matching a genuine mid-compound -ENOMEM
> > + * and driving the caller's reactive split fallback instead
> > + * of an early, no-progress failure.
> > */
> > - if (ret)
> > + if (IS_ENABLED(CONFIG_FAULT_INJECTION) && i &&
> > + ttm_backup_fault_inject_folio())
> > + to_folio = ERR_PTR(-ENOMEM);
> > + else
> > + to_folio = shmem_read_folio_gfp(mapping, idx + i, alloc_gfp);
> > + if (IS_ERR(to_folio)) {
> > + int err = PTR_ERR(to_folio);
> > +
> > + if (err == -ENOMEM && *nr_pages_backed)
> > + return ttm_backup_shmem_idx_to_handle(idx);
> > +
> > + if (*nr_pages_backed) {
> > + shmem_truncate_range(file_inode(backup),
> > + (loff_t)idx << PAGE_SHIFT,
> > + ((loff_t)(idx + i) << PAGE_SHIFT) - 1);
> > + /*
> > + * The pages just truncated are no longer
> > + * backed up; don't let the caller mistake
> > + * them for valid handles.
> > + */
> > + *nr_pages_backed = 0;
> > + }
> > + return err;
> > + }
> > +
> > + to_nr = min_t(int, nr_pages - i,
> > + folio_next_index(to_folio) - (idx + i));
> > +
> > + folio_mark_accessed(to_folio);
> > + folio_lock(to_folio);
> > + folio_mark_dirty(to_folio);
> > +
> > + for (j = 0; j < to_nr; j++)
> > + copy_highpage(folio_file_page(to_folio, idx + i + j),
> > + folio_page(folio, i + j));
> > +
> > + if (writeback && !folio_mapped(to_folio) &&
> > + folio_clear_dirty_for_io(to_folio)) {
> > + folio_set_reclaim(to_folio);
> > ++ ret = shmem_write_folio(to_folio);
> > + if (!folio_test_writeback(to_folio))
> > + folio_clear_reclaim(to_folio);
> > + if (ret == AOP_WRITEPAGE_ACTIVATE)
> > + folio_unlock(to_folio);
> > + } else {
> > folio_unlock(to_folio);
> > - } else {
> > - folio_unlock(to_folio);
> > + }
> > +
> > + folio_put(to_folio);
> > + i += to_nr;
> > + *nr_pages_backed = i;
> > }
> >
> > - folio_put(to_folio);
> > -
> > - return handle;
> > + return ttm_backup_shmem_idx_to_handle(idx);
> > }
> >
> > /**
>
>
> ---end quoted text---
^ permalink raw reply
* Re: [next-20260717] ufshcd issues on Pixel 3
From: David Heidelberg @ 2026-07-20 21:01 UTC (permalink / raw)
To: Linux Next Mailing List, linux-arm-msm
In-Reply-To: <fb3bf040-7049-40be-a7e0-54fa624f134d@ixit.cz>
On 19/07/2026 20:14, David Heidelberg wrote:
> Hello!
>
> With next-20260717 I'm receiving these errors on Pixel 3. Previous kernel was
> running there just fine (I think around next-20260703).
I can confirm also with Xiaomi Mi 8 (dipper) so I assume these issues are at
least sdm845-wide.
>
> Dropping the log here, in case someone encounter similar issue.
>
> David
> ---
>
> [ 38.963072] ufshcd-qcom 1d84000.ufshc: ufshcd_abort: Device abort task at tag 13
> [ 38.974926] sd 0:0:0:0: [sda] tag#13 CDB: opcode=0x28 28 00 00 24 bd 2c 00 00
> 4d 00
[...]
^ permalink raw reply
* [syzbot] [kernel?] linux-next test error: WARNING: locking bug in change_page_attr_set_clr
From: syzbot @ 2026-07-20 16:59 UTC (permalink / raw)
To: bp, dave.hansen, hpa, linux-kernel, linux-next, luto, mingo,
peterz, sfr, syzkaller-bugs, tglx, x86
Hello,
syzbot found the following issue on:
HEAD commit: 1a1757b76427 Add linux-next specific files for 20260716
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c734b9580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8d1a274c57796a86
dashboard link: https://syzkaller.appspot.com/bug?extid=ee7ecfcd0e3f185e835a
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/923ee89ba238/disk-1a1757b7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/cb34d1bf205c/vmlinux-1a1757b7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/bf183d434c82/bzImage-1a1757b7.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ee7ecfcd0e3f185e835a@syzkaller.appspotmail.com
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
kfence: initialized - using 2097152 bytes for 255 objects at 0xffff88823be00000-0xffff88823c000000
Console: colour VGA+ 80x25
printk: legacy console [ttyS0] enabled
printk: legacy console [ttyS0] enabled
printk: legacy bootconsole [earlyser0] disabled
printk: legacy bootconsole [earlyser0] disabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 48
... MAX_LOCKDEP_KEYS: 8192
... CLASSHASH_SIZE: 4096
... MAX_LOCKDEP_ENTRIES: 1048576
... MAX_LOCKDEP_CHAINS: 1048576
... CHAINHASH_SIZE: 524288
memory used by lock dependency info: 106625 kB
memory used for stack traces: 8320 kB
per task-struct memory footprint: 1920 bytes
mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
ACPI: Core revision 20260408
APIC: Switch to symmetric I/O mode setup
x2apic enabled
APIC: Switched APIC routing to: physical x2apic
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x1fb63109b96, max_idle_ns: 440795265316 ns
Calibrating delay loop (skipped) preset value.. 4399.99 BogoMIPS (lpj=21999980)
Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
Last level dTLB entries: 4KB 64, 2MB 32, 4MB 32, 1GB 4
mitigations: Enabled attack vectors: user_kernel, user_user, guest_host, guest_guest, SMT mitigations: auto
Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
Spectre V2 : Mitigation: IBRS
RETBleed: Mitigation: IBRS
ITS: Mitigation: Aligned branch/return thunks
Spectre V2 : User space: Mitigation: STIBP via prctl
MDS: Mitigation: Clear CPU buffers
TAA: Mitigation: Clear CPU buffers
MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no microcode
Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Spectre V2 : Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT
Spectre V2 : Enabling IBPB for BPF
Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
active return thunk: its_return_thunk
Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall and VM exit
x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
=============================
[ BUG: Invalid wait context ]
syzkaller #0 Not tainted
-----------------------------
swapper/0/0 is trying to lock:
ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: mmap_read_lock include/linux/mmap_lock.h:600 [inline]
ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
ffffffff8f088c78 ((init_mm).mmap_lock){....}-{4:4}, at: change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
other info that might help us debug this:
context-{5:5}
locks held by swapper/0/0: 1, last CPU#0:
#0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
#0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:421 [inline]
#0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
#0: ffffffff8edc2078 (cpa_lock){+.+.}-{3:3}, at: change_page_attr_set_clr+0x967/0x1010 arch/x86/mm/pat/set_memory.c:2142
stack backtrace:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/25/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_lock_invalid_wait_context kernel/locking/lockdep.c:4846 [inline]
check_wait_context kernel/locking/lockdep.c:4918 [inline]
__lock_acquire+0xef0/0x2e50 kernel/locking/lockdep.c:5204
lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5906
down_read+0x4a/0x330 kernel/locking/rwsem.c:1574
mmap_read_lock include/linux/mmap_lock.h:600 [inline]
class_mmap_read_lock_constructor include/linux/mmap_lock.h:631 [inline]
cpa_collapse_large_pages arch/x86/mm/pat/set_memory.c:448 [inline]
cpa_flush arch/x86/mm/pat/set_memory.c:494 [inline]
change_page_attr_set_clr+0xc2c/0x1010 arch/x86/mm/pat/set_memory.c:2142
set_memory_rox+0xbe/0x100 arch/x86/mm/pat/set_memory.c:2341
its_pages_protect arch/x86/kernel/alternative.c:168 [inline]
its_fini_core arch/x86/kernel/alternative.c:175 [inline]
alternative_instructions+0x95/0x100 arch/x86/kernel/alternative.c:2264
arch_cpu_finalize_init+0xb2/0x1f0 arch/x86/kernel/cpu/common.c:2633
start_kernel+0x310/0x3e0 init/main.c:1153
x86_64_start_reservations+0x24/0x30 arch/x86/kernel/head64.c:310
x86_64_start_kernel+0x137/0x1b0 arch/x86/kernel/head64.c:291
common_startup_64+0x13e/0x157
</TASK>
pid_max: default: 32768 minimum: 301
landlock: Up and running.
Yama: becoming mindful.
TOMOYO Linux initialized
AppArmor: AppArmor initialized
LSM support for eBPF active
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, vmalloc hugepage)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
VFS: Finished mounting rootfs on nullfs
Running RCU synchronous self tests
Running RCU synchronous self tests
numa_add_cpu cpu 1 node 0: mask now 0-1
numa_add_cpu cpu 1 node 1: mask now 0-1
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: linux-next: manual merge of the rdma tree with the origin tree
From: Leon Romanovsky @ 2026-07-20 15:03 UTC (permalink / raw)
To: Mark Brown, Jason Gunthorpe
Cc: Jacob Moroni, Jason Gunthorpe, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <al40KAaJ0Qiy-lTs@sirena.org.uk>
On Mon, Jul 20, 2026 at 03:43:52PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/hw/irdma/verbs.c
>
> between commit:
>
> b9b0889071569 ("RDMA/irdma: Prevent user-triggered null deref on QP create")
>
> from the origin tree and commit:
>
> d83bf998f719d ("RDMA/irdma: Prevent user-triggered null deref on QP create")
Jason,
By mistake, we ended up with two identical commits: one applied by
you to rdma-rc, and the other applied by me to rdma-next.
Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).