From: Pratyush Anand <panand@redhat.com>
To: Baoquan He <bhe@redhat.com>, Dave Young <dyoung@redhat.com>,
ats-kumagai@wm.jp.nec.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, akpm@linux-foundation.org, mingo@redhat.com,
hpa@zytor.com, tonli@redhat.com, keescook@chromium.org,
takahiro.akashi@linaro.org, thgarnie@google.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo
Date: Wed, 12 Oct 2016 14:39:45 +0530 [thread overview]
Message-ID: <256e8ba2-4f92-36cf-ec5c-2502113922c6@redhat.com> (raw)
In-Reply-To: <20161012002613.GB21477@x1>
On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote:
>> PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
>> > VMALLOC_BASE and VMEMMAP_BASE is necessary..
> Well, yes, I was wrong. I wrongly thought of kernel text virtual address
> when I wrote the reply
So, if you can get PAGE_OFFSET then, probably you do not need to know
anything else.
I think, we can simplify makedumpfile code, where we do not need to
depend on VMALLOC_START or VMEMMAP_START etc.
"If we know PAGE_OFFSET, we can read from swapper space. If we can read
from swapper space, then we can know PA of any kernel VA, whether it is
VMALLOC, or vmemmap or module or kernel text area."
In fact, I have cleanup patches for ARM64 [1], which take above approach
and get rid of need of VMALLOC_START or VMEMMAP_START etc. I will be
sending them upstream soon.
Probably, x86 can take the similar approach.
~Pratyush
[1]
https://github.com/pratyushanand/makedumpfile/blob/arm64_devel/arch/arm64.c#L228
next prev parent reply other threads:[~2016-10-12 9:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 8:46 Baoquan He
2016-10-06 20:07 ` Eric W. Biederman
2016-10-11 7:41 ` Baoquan He
2016-10-11 8:19 ` Dave Young
2016-10-11 8:43 ` Dave Young
2016-10-12 0:26 ` Baoquan He
2016-10-12 9:09 ` Pratyush Anand [this message]
2016-10-13 8:53 ` Baoquan He
2016-10-14 3:13 ` Dave Young
2016-11-01 5:10 ` Dave Young
2016-11-01 5:33 ` Baoquan He
2016-11-01 14:13 ` Dave Anderson
2016-11-02 1:34 ` Baoquan He
2016-11-02 13:29 ` Dave Anderson
2016-11-02 13:48 ` 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=256e8ba2-4f92-36cf-ec5c-2502113922c6@redhat.com \
--to=panand@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ats-kumagai@wm.jp.nec.com \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=takahiro.akashi@linaro.org \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=tonli@redhat.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®