All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Brennan <stephen.s.brennan@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org
Subject: /proc/kcore reads 0's for vmap_block
Date: Wed, 26 Oct 2022 16:15:25 -0700	[thread overview]
Message-ID: <87ilk6gos2.fsf@oracle.com> (raw)

Hi all,

The /proc/kcore interface uses vread() to read memory addresses which
are in the vmalloc region, and it seems that vread() doesn't support
vmap_areas which are associated with a vmap_block. As far as I can tell,
those have vmap_area.vm == NULL, and get skipped during vread()'s
iteration. So the end result is that the read simply returns 0's.

This impacts live debuggers like gdb and drgn, which is how I stumbled
upon it[1]. It looks like crash avoids the issue by doing a page table
walk and reading the physical address.

I'm wondering if there's any rationale for this omission from vread():
is it a simple oversight, or was it omitted due to the difficulty? Is
it possible for /proc/kcore to simply take the page faults when it reads
unmapped memory and handle them? (I'm sure that's already discussed or
is obviously infeasible for some reason beyond me.)

Ideally, I'm just looking for a way forward that allows the debugger to
*work* as expected, meaning either that /proc/kcore always reads the
correct data, or that the debugger can know ahead of time that it will
need to do some processing (like a page table walk) first. 

Thanks,
Stephen

[1]: https://github.com/osandov/drgn/issues/217


             reply	other threads:[~2022-10-26 23:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26 23:15 Stephen Brennan [this message]
2022-10-27  8:54 ` /proc/kcore reads 0's for vmap_block Baoquan He
2022-10-27 18:07   ` Stephen Brennan
2022-10-28  7:52   ` Uladzislau Rezki
2022-10-31  7:12     ` Baoquan He

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=87ilk6gos2.fsf@oracle.com \
    --to=stephen.s.brennan@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.