lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 16 Nov 2018 03:20:50 +0530
From:   Bhupesh Sharma <bhsharma@...hat.com>
To:     Baoquan He <bhe@...hat.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bhupesh SHARMA <bhupesh.linux@...il.com>,
        Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kazuhito Hagio <k-hagio@...jp.nec.com>,
        Dave Anderson <anderson@...hat.com>,
        James Morse <james.morse@....com>,
        Omar Sandoval <osandov@...com>, x86@...nel.org,
        kexec mailing list <kexec@...ts.infradead.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] x86_64, vmcoreinfo: Append 'page_offset_base' to vmcoreinfo

Hi Baoquan,

On Tue, Oct 30, 2018 at 2:29 PM Baoquan He <bhe@...hat.com> wrote:
>
> 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.

I have sent a v2 patch with a much simpler git log message. Hopefully
that should clarify the intent behind the patch.
Also lets see what views the x86 maintainers have on the v2 patch.

Regards,
Bhupesh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ