mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Mike Galbraith <efault@gmx.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	lstoakes@gmail.com, wangkefeng.wang@huawei.com,
	catalin.marinas@arm.com, ardb@kernel.org
Subject: Re: arm64: perf test 26 rpi4 oops
Date: Mon, 31 Jul 2023 11:43:40 +0100	[thread overview]
Message-ID: <20230731104340.GA24767@willie-the-truck> (raw)
In-Reply-To: <8c56256399e2e6c41bc574749d6170d5529f24fc.camel@gmx.de>

[+Lorenzo, Kefeng and others]

On Sun, Jul 30, 2023 at 06:09:15PM +0200, Mike Galbraith wrote:
> On Fri, 2023-07-28 at 15:18 +0100, Will Deacon wrote:
> >
> > Looking at this quickly with Mark, the most likely explanation is that
> > a bogus kernel address is being passed as the source pointer to
> > copy_to_user().
> 
> 'start' in read_kcore_iter() is bogus a LOT when running perf test 26,
> and that back to at least 5.15.  Seems removal of bogon-proofing gave a
> toothless old bug teeth, but seemingly only to perf test 26.  Rummaging
> around with crash vmlinux /proc/kcore seems to be bogon free anyway.
> 
> Someone should perhaps take a peek at perf.  Bogons aside, it also
> doesn't seem to care deeply about kernel response.  Whether the kernel
> oops or I bat 945 bogons aside, it says 'OK'.  That seems a tad odd.

Aha, so I think I triggered the issue you're seeing under QEMU (log
below). perf (unhelpfully) doesn't have stable test numbers, so it's
test 21 in my case. However, it only explodes if I run it as root, since
/proc/kcore is 0400 on my system.

The easiest way to trigger the problem is simply:

# objdump -d /proc/kcore

Looking at the history, I wonder whether this is because of a combination
of:

e025ab842ec3 ("mm: remove kern_addr_valid() completely")

which removed the kern_addr_valid() check on the basis that kcore used
copy_from_kernel_nofault() anyway, and:

2e1c0170771e ("fs/proc/kcore: avoid bounce buffer for ktext data")

which replaced the copy_from_kernel_nofault() with _copy_to_user().

So with both of those applied, we're missing the address check on arm64.

Will

--->8

[   40.136085] Unable to handle kernel paging request at virtual address ffffffdcaabf0000
[   40.136453] Mem abort info:
[   40.136570]   ESR = 0x0000000096000006
[   40.136737]   EC = 0x25: DABT (current EL), IL = 32 bits
[   40.136946]   SET = 0, FnV = 0
[   40.137085]   EA = 0, S1PTW = 0
[   40.137232]   FSC = 0x06: level 2 translation fault
[   40.137441] Data abort info:
[   40.137573]   ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[   40.137801]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   40.138005]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   40.138257] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000e51c5000
[   40.138516] [ffffffdcaabf0000] pgd=100000023ffff003, p4d=100000023ffff003, pud=100000023ffff003, pmd=0000000000000000
[   40.139218] Internal error: Oops: 0000000096000006 [#1] SMP
[   40.139515] Modules linked in:
[   40.139780] CPU: 1 PID: 225 Comm: objdump Not tainted 6.5.0-rc3-v8 #5
[   40.140038] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
[   40.140439] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   40.140710] pc : __arch_copy_to_user+0x180/0x240
[   40.140944] lr : _copy_to_iter+0xe8/0x4b0
[   40.141115] sp : ffffffc0805b3950
[   40.141256] x29: ffffffc0805b3950 x28: ffffffdcaabf0000 x27: ffffffdcabfff228
[   40.141568] x26: ffffffdcaabf0000 x25: ffffffc0805b3d68 x24: 0000000000000001
[   40.141841] x23: ffffff80c0e2d880 x22: ffffffc0805b3d40 x21: 0000000000000400
[   40.142119] x20: ffffffdcabe9cd40 x19: 0000000000000400 x18: 0000000000000000
[   40.142385] x17: 0000000000000000 x16: 0000000000000000 x15: ffffffdcaabf0000
[   40.142665] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[   40.142933] x11: 0000008000000000 x10: ffffffdcabe9cd40 x9 : 0000000000000230
[   40.143206] x8 : 0000000000101000 x7 : 0000007e08000000 x6 : 00000055c51a9840
[   40.143479] x5 : 00000055c51a9c40 x4 : 0000000000000000 x3 : 0000000000000400
[   40.143761] x2 : 0000000000000380 x1 : ffffffdcaabf0000 x0 : 00000055c51a9840
[   40.144124] Call trace:
[   40.144258]  __arch_copy_to_user+0x180/0x240
[   40.144433]  read_kcore_iter+0x718/0x810
[   40.144564]  proc_reg_read_iter+0x8c/0xe8
[   40.144720]  vfs_read+0x204/0x2a8
[   40.144846]  ksys_read+0x74/0x108
[   40.144975]  __arm64_sys_read+0x24/0x38
[   40.145113]  invoke_syscall+0x4c/0x118
[   40.145267]  el0_svc_common.constprop.0+0x68/0x120
[   40.145437]  do_el0_svc+0x40/0xa8
[   40.145568]  el0_svc+0x30/0x98
[   40.145702]  el0t_64_sync_handler+0xc0/0xc8
[   40.145866]  el0t_64_sync+0x190/0x198
[   40.146103] Code: d503201f d503201f d503201f d503201f (a8c12027) 
[   40.146518] ---[ end trace 0000000000000000 ]---

  reply	other threads:[~2023-07-31 10:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-28  4:06 Mike Galbraith
2023-07-28 14:18 ` Will Deacon
2023-07-28 15:12   ` Mike Galbraith
2023-07-28 15:23     ` Will Deacon
2023-07-28 16:35       ` Mike Galbraith
2023-07-29 16:30     ` Mike Galbraith
2023-07-30  5:54   ` Mike Galbraith
2023-07-30 11:01     ` Mike Galbraith
2023-07-30 16:09   ` Mike Galbraith
2023-07-31 10:43     ` Will Deacon [this message]
2023-07-31 11:37       ` Mike Galbraith
2023-07-31 11:52       ` Will Deacon
2023-07-31 16:07         ` Mike Galbraith
2023-07-31 21:08         ` Lorenzo Stoakes
2023-07-31 21:54           ` Lorenzo Stoakes
2023-07-31 23:27             ` Mike Galbraith
2023-07-31 23:48               ` Mike Galbraith
2023-08-01  0:33                 ` Mike Galbraith
2023-08-01  4:34                 ` Mike Galbraith
2023-08-01  7:27                   ` Will Deacon
2023-08-01  8:39                     ` Mike Galbraith

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=20230731104340.GA24767@willie-the-truck \
    --to=will@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lstoakes@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=wangkefeng.wang@huawei.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

all inboxes | Powered by JetHome®