From: Borislav Petkov <bp@alien8.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
alex@ghiti.fr, aou@eecs.berkeley.edu,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Qian Cai <cai@lca.pw>, Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
dave.jiang@intel.com, David Miller <davem@davemloft.net>,
Dmitry Vyukov <dvyukov@google.com>,
Alexander Potapenko <glider@google.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Peter Anvin <hpa@zytor.com>, James Morse <james.morse@arm.com>,
James Hogan <jhogan@kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
Linux-MM <linux-mm@kvack.org>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
Andrew Lutomirski <luto@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
mawilcox@microsoft.com, Ingo Molnar <mingo@elte.hu>,
mm-commits@vger.kernel.org, Michael Ellerman <mpe@ellerman.id.au>,
n-horiguchi@ah.jp.nec.com, Palmer Dabbelt <palmer@sifive.com>,
Paul Burton <paul.burton@mips.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
ralf@linux-mips.org, shashim@codeaurora.org,
Steven Price <steven.price@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
vgupta@synopsys.com, Will Deacon <will@kernel.org>,
zong.li@sifive.com
Subject: Re: [patch 064/158] mm: add generic ptdump
Date: Sun, 1 Dec 2019 16:45:54 +0100 [thread overview]
Message-ID: <20191201154553.GE6629@zn.tnic> (raw)
In-Reply-To: <20191201152119.GD6629@zn.tnic>
On Sun, Dec 01, 2019 at 04:21:19PM +0100, Borislav Petkov wrote:
> On Sun, Dec 01, 2019 at 04:10:11PM +0100, Borislav Petkov wrote:
> > So lemme first confirm it really is caused by those patches.
>
> Yeah, those patches are causing it. Tried your current master - it is OK
> - and then applied Andrew's patches I was CCed on, ontop, and I got in a
> VM:
>
> VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
> devtmpfs: mounted
> Freeing unused kernel image (initmem) memory: 664K
> Write protecting kernel text and read-only data: 18164k
> NX-protecting the kernel data: 7416k
> BUG: kernel NULL pointer dereference, address: 00000014
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x0000) - not-present page
> *pdpt = 0000000000000000 *pde = f000ff53f000ff53
> Oops: 0000 [#1] PREEMPT SMP PTI
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014
> EIP: __lock_acquire.isra.0+0x2e8/0x4e0
> Code: e8 bd a1 2f 00 85 c0 74 11 8b 1d 08 8f 26 c5 85 db 0f 84 05 1a 00 00 8d 76 00 31 db 8d 65 f4 89 d8 5b 5e 5f 5d c3 8d 74 26 00 <8b> 44 90 04 85 c0 0f 85 4c fd ff ff e9 33 fd ff ff 8d b4 26 00 00
> EAX: 00000010 EBX: 00000010 ECX: 00000001 EDX: 00000000
> ESI: f1070040 EDI: f1070040 EBP: f1073e04 ESP: f1073de0
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010097
> CR0: 80050033 CR2: 00000014 CR3: 05348000 CR4: 001406b0
> Call Trace:
> lock_acquire+0x42/0x60
> ? __walk_page_range+0x4d9/0x590
> _raw_spin_lock+0x22/0x40
> ? __walk_page_range+0x4d9/0x590
> __walk_page_range+0x4d9/0x590
Ok, some more staring. That offset is:
# mm/pagewalk.c:31: pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
sall $5, %eax #, tmp235
addl -64(%ebp), %eax # %sfp, tmp236
call page_address #
addl %eax, %esi # tmp306, __pte
# ./include/linux/spinlock.h:338: raw_spin_lock(&lock->rlock);
movl -76(%ebp), %eax # %sfp,
call _raw_spin_lock #
movl %edi, %edx # start, start
movl %ebx, -64(%ebp) # __boundary, %sfp
movl -80(%ebp), %edi # %sfp, ops
movl %esi, -40(%ebp) # __pte, %sfp
i.e., pte_offset_map_lock() and I *think* that ptl thing is NULL. The Code
section decodes to:
Code: e8 bd a1 2f 00 85 c0 74 11 8b 1d 08 8f 26 c5 85 db 0f 84 05 1a 00 00 8d 76 00 31 db 8d 65 f4 89 d8 5b 5e 5f 5d c3 8d 74 26 00 <8b> 44 90 04 85 c0 0f 85 4c fd ff ff e9 33 fd ff ff 8d b4 26 00 00
All code
========
0: e8 bd a1 2f 00 callq 0x2fa1c2
5: 85 c0 test %eax,%eax
7: 74 11 je 0x1a
9: 8b 1d 08 8f 26 c5 mov -0x3ad970f8(%rip),%ebx # 0xffffffffc5268f17
f: 85 db test %ebx,%ebx
11: 0f 84 05 1a 00 00 je 0x1a1c
17: 8d 76 00 lea 0x0(%rsi),%esi
1a: 31 db xor %ebx,%ebx
1c: 8d 65 f4 lea -0xc(%rbp),%esp
1f: 89 d8 mov %ebx,%eax
21: 5b pop %rbx
22: 5e pop %rsi
23: 5f pop %rdi
24: 5d pop %rbp
25: c3 retq
26: 8d 74 26 00 lea 0x0(%rsi,%riz,1),%esi
2a:* 8b 44 90 04 mov 0x4(%rax,%rdx,4),%eax <-- trapping instruction
2e: 85 c0 test %eax,%eax
30: 0f 85 4c fd ff ff jne 0xfffffffffffffd82
36: e9 33 fd ff ff jmpq 0xfffffffffffffd6e
3b: 8d .byte 0x8d
3c: b4 26
which is this corresponding piece in __lock_acquire():
call debug_locks_off #
# kernel/locking/lockdep.c:3775: if (!debug_locks_off())
testl %eax, %eax # tmp325
je .L562 #,
# kernel/locking/lockdep.c:3777: if (debug_locks_silent)
movl debug_locks_silent, %ebx # debug_locks_silent, <retval>
# kernel/locking/lockdep.c:3777: if (debug_locks_silent)
testl %ebx, %ebx # <retval>
je .L642 #,
.p2align 4,,10
.p2align 3
.L562:
# kernel/locking/lockdep.c:3826: return 0;
xorl %ebx, %ebx # <retval>
.L557:
# kernel/locking/lockdep.c:3982: }
leal -12(%ebp), %esp #,
movl %ebx, %eax # <retval>,
popl %ebx #
popl %esi #
popl %edi #
popl %ebp #
ret
.p2align 4,,10
.p2align 3
.L649:
# kernel/locking/lockdep.c:3832: class = lock->class_cache[subclass];
movl 4(%eax,%edx,4), %eax # lock_7(D)->class_cache, class
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(the LEA above is NOP padding) and %eax and %edx are both NULL.
i.e., that thing:
if (subclass < NR_LOCKDEP_CACHING_CLASSES)
class = lock->class_cache[subclass];
^^^^^^^^^^^^^^^
AFAICT, of course.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2019-12-01 15:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-01 1:53 [patch 064/158] mm: add generic ptdump akpm
2019-12-01 9:07 ` Borislav Petkov
2019-12-01 14:45 ` Linus Torvalds
2019-12-01 15:10 ` Borislav Petkov
2019-12-01 15:21 ` Borislav Petkov
2019-12-01 15:45 ` Borislav Petkov [this message]
2019-12-02 9:09 ` Steven Price
2019-12-02 15:42 ` Borislav Petkov
2019-12-03 10:47 ` David Hildenbrand
2019-12-03 11:00 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191201154553.GE6629@zn.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=cai@lca.pw \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=jhogan@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mawilcox@microsoft.com \
--cc=mingo@elte.hu \
--cc=mm-commits@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=palmer@sifive.com \
--cc=paul.burton@mips.com \
--cc=paul.walmsley@sifive.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=shashim@codeaurora.org \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vgupta@synopsys.com \
--cc=will@kernel.org \
--cc=zong.li@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).