Re: [linux-next: vfs - regression] - merge error?

[Christian Brauner <brauner@kernel.org>]

On Fri, Nov 28, 2025 at 02:11:44PM +0100, Heiko Carstens wrote:
> On Fri, Nov 28, 2025 at 04:29:28PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20251127:
> > 
> > This kernel produces a warning at boot time.
> > 
> > The vfs-brauner tree still had its build failure so I used a supplied
> > patch.
> 
> ltp's mq_notify03 test case causes this on linux-next as of 20251128:
> 
> Unable to handle kernel pointer dereference in virtual kernel address space
> Failing address: 0000000000000000 TEID: 0000000000000803

Wrong conflict resolution in vfs.all on my part. This is a merge
conflict due to the locking changes for directories that Neil
introduced. I'll adapt the merge conflict resolution I'll provide to
Linus accordingly. Thanks for reporting this!

> Fault in home space mode while using kernel ASCE.
> AS:0000000002528007 R3:00000001ffffc007 S:00000001ffffb801 P:0000000000000400 
> Oops: 0011 ilc:3 [#1]SMP 
> Modules linked in:
> CPU: 2 UID: 0 PID: 702 Comm: mq_notify03 Not tainted 6.18.0-rc7-00495-g73612a36da1a #17 NONE 
> Hardware name: IBM 3931 A01 704 (z/VM 7.4.0)
> Krnl PSW : 0704e00180000000 000003ffe04f2baa (__fput+0x5a/0x2e0)
>            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
> Krnl GPRS: 0000000080000000 000003ffe1a25200 0000000000000008 000003ffe04f2ea0
>            000003ffe1a2531d 0000000000000000 00000000899e2300 00000000815e2a20
>            000000008ce3c008 0000000088789140 00000000040b801f 00000000827ef800
>            000003ff00000000 00000000899e2300 0000037fe0af3c00 0000037fe0af3b98
> Krnl Code: 000003ffe04f2b9c: a7a00600            tmlh    %r10,1536
>            000003ffe04f2ba0: a744002e            brc     4,000003ffe04f2bfc
>           #000003ffe04f2ba4: e35090300004        lg      %r5,48(%r9)
>           >000003ffe04f2baa: e31050280004        lg      %r1,40(%r5)
>            000003ffe04f2bb0: e33013b80004        lg      %r3,952(%r1)
>            000003ffe04f2bb6: ec380023007c        cgij    %r3,0,8,000003ffe04f2bfc
>            000003ffe04f2bbc: e30030080004        lg      %r0,8(%r3)
>            000003ffe04f2bc2: ec08001d007c        cgij    %r0,0,8,000003ffe04f2bfc
> Call Trace:
>  [<000003ffe04f2baa>] __fput+0x5a/0x2e0 
> ([<000003ffe047d38a>] kmem_cache_free+0x40a/0x4a0)
>  [<000003ffe0199408>] task_work_run+0x88/0xd0 
>  [<000003ffe0174d1a>] do_exit+0x18a/0x4d0 
>  [<000003ffe0175220>] do_group_exit+0x40/0xc0 
>  [<000003ffe018525a>] get_signal+0x80a/0x840 
>  [<000003ffe011e35c>] arch_do_signal_or_restart+0x6c/0x2f0 
>  [<000003ffe0228fc2>] exit_to_user_mode_loop+0xd2/0x190 
>  [<000003ffe0f52154>] __do_syscall+0x324/0x340 
>  [<000003ffe0f5e9fe>] system_call+0x6e/0x90 
> Last Breaking-Event-Address:
>  [<000003ffe04f2eac>] ____fput+0xc/0x20
> ---[ end trace 0000000000000000 ]---
> 
> I could bisect this to
> 
> commit 73612a36da1a ("Merge branch 'vfs-6.19.fd_prepare' into vfs.all")
> 
> which also resolves a merge conflict in ipc/mqueue.c. Looks like the conflict
> resolution might not be correct?