linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: bhe@redhat.com (Baoquan He)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] x86_64, vmcoreinfo: Append 'page_offset_base' to vmcoreinfo
Date: Tue, 30 Oct 2018 16:59:17 +0800	[thread overview]
Message-ID: <20181030085917.GC11408@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CACi5LpP0_s9zAF+QfKpU+kG6BKqqkiwQhcW-WFZ0=SnBeX7ZXA@mail.gmail.com>

Hi Bhupesh,

On 10/30/18 at 12:33pm, Bhupesh Sharma wrote:
> > Why it's broken? Have you investigated and figured out why it's broken?
> > If fix, what patch will it look like? Does the patch prove it's not
> > worth using the current way?
> >
> > Have you thought about this in advance? Or still like before, you said
> > on arm64 you found different boards have different behaviour, then
> > makedumpfile maintainer Kazu said he investigated and found it may be
> > caused by KALSR. This time, for this KCORE_REMAP adding, can you help to
> > investigate further and give an answer to the issue you found and
> > raised?
> 
> Ofcourse, the patchset which added vmcoreinfo into kcore was discussed
> and it was agreed that this was a better approach to move forward and hence
> accepted in mainline.

Currently I am wondering why x86_64 need add page_offset_base to
vmcoreinfo. Is it because any feature or userspace tool is broken if
page_offset_base is not added into vmcoreinfo? 

Why KCORE_REMAP adding broke makedumpfile, do you find out the root
cause and what it looks like if you fix it in the current way?

Can you list the reasons one by one as below with short sentence?
1)
2)
3)

> 
> Regarding the makedumpfile issue, I have already provided a detailed
> reply to Kazu (you are Cc'ed on the thread) and also proposed a
> makedumpfile approach which
> reads the 'page_offset_base' value from kcore (using the kernel
> interface provided by this patch),
> [on which you are Cc'ed as well]:

This is your replying mail link:
https://www.spinics.net/lists/kexec/msg21616.html

Then what on earth do you want to fix in this patch?

So Kazu's patch which decuding page_offset_base like x86 64 have done works.
Yes, and your way using vmcoreinfo in kcore also works, but this is not
the reason which supports you to discard the old way Kazu suggested. Now
we are talking about why you want to discard the old way, and adding
page_offset_base to vmcoreinfo.

Please elaborate and reply with simple and clear logic.

Thanks
Baoquan

  reply	other threads:[~2018-10-30  8:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26 22:43 [PATCH] x86_64, vmcoreinfo: Append 'page_offset_base' to vmcoreinfo Bhupesh Sharma
2018-10-27 10:02 ` Baoquan He
2018-10-29 10:37   ` Bhupesh Sharma
2018-10-30  2:07     ` Baoquan He
2018-10-30  7:03       ` Bhupesh Sharma
2018-10-30  8:59         ` Baoquan He [this message]
2018-11-15 21:50           ` Bhupesh Sharma
2018-11-16  3:03             ` Baoquan He
2018-10-30 11:31 ` kbuild test robot
2018-11-01 15:49   ` Bhupesh Sharma

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=20181030085917.GC11408@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).