[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251128-nennung-lernen-b84376e296cb@brauner>
Date: Fri, 28 Nov 2025 16:52:46 +0100
From: Christian Brauner <brauner@...nel.org>
To: Heiko Carstens <hca@...ux.ibm.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Linux Next Mailing List <linux-next@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [linux-next: vfs - regression] - merge error?
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?
Powered by blists - more mailing lists