linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>
To: Nicholas Piggin <nicholas.piggin@gmail.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
	Ananth Narayan <ananth@in.ibm.com>,
	kernelfans@gmail.com,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Hari Bathini <hbathini@linux.vnet.ibm.com>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: Re: [PATCH v4 1/7] powerpc/fadump: Move the metadata region to start of the reserved area.
Date: Mon, 23 Apr 2018 10:46:06 +0530	[thread overview]
Message-ID: <f2bbcdfd-65be-0a50-7d24-b66f101437b7@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180422115816.701d0837@roar.ozlabs.ibm.com>

On 04/22/2018 07:28 AM, Nicholas Piggin wrote:
> On Fri, 20 Apr 2018 10:34:18 +0530
> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> 
>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>
>> Currently the metadata region that holds crash info structure and ELF core
>> header is placed towards the end of reserved memory area. This patch places
>> it at the beginning of the reserved memory area. It also introduces
>> additional dump section called metadata section to communicate location
>> of metadata region to 2nd kernel. This patch also maintains the
>> compatibility between production/capture kernels irrespective of their
>> kernel versions. Both combination older/newer and newer/older works fine.
> 
> Trying to look at the patches it might help me if you document reasons
> for why this change is made changelog, even if it may be obvious to
> someone who knows the code better.

Yeah, I should have mentioned that this patch provides the foundation
for CMA patch 4. With CMA reservation we now allocate metadata region
using cma_alloc() which always allocates metadata region at the start of
CMA reserved region. Earlier in v1, I had this change included along
with CMA reservation patch. But then to make things simpler for review I
did a logical split of movement of metadata region and CMA reservation
patch separately. I think I should order patch 1, 2 and 4 in a sequence
and Move patch3 to patch 1.

> 
> I thought you could include the documentation change in this patch as
> well, but maybe that's a matter of preference.

Yeah that's how I prefer it :-), but that just me. But if it helps in
review I can fold it into 1.

Thanks,
-Mahesh.

  reply	other threads:[~2018-04-23  5:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20  5:04 [PATCH v4 0/7] powerpc/fadump: Improvements and fixes for firmware-assisted dump Mahesh J Salgaonkar
2018-04-20  5:04 ` [PATCH v4 1/7] powerpc/fadump: Move the metadata region to start of the reserved area Mahesh J Salgaonkar
2018-04-22  1:58   ` Nicholas Piggin
2018-04-23  5:16     ` Mahesh Jagannath Salgaonkar [this message]
2018-04-20  5:04 ` [PATCH v4 2/7] powerpc/fadump: Update documentation to reflect the metadata region movement Mahesh J Salgaonkar
2018-04-20  5:04 ` [PATCH v4 3/7] powerpc/fadump: un-register fadump on kexec path Mahesh J Salgaonkar
2018-04-22  1:58   ` Nicholas Piggin
2018-04-23  5:17     ` Mahesh Jagannath Salgaonkar
2018-04-20  5:04 ` [PATCH v4 4/7] powerpc/fadump: Reservationless firmware assisted dump Mahesh J Salgaonkar
2018-04-23 12:53   ` Hari Bathini
2018-04-20  5:04 ` [PATCH v4 5/7] powerpc/fadump: Update documentation to reflect CMA reservation Mahesh J Salgaonkar
2018-04-20  5:05 ` [PATCH v4 6/7] powerpc/fadump: throw proper error message on fadump registration failure Mahesh J Salgaonkar
2018-04-20  5:05 ` [PATCH v4 7/7] powerpc/fadump: Do not allow hot-remove memory from fadump reserved area Mahesh J Salgaonkar

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=f2bbcdfd-65be-0a50-7d24-b66f101437b7@linux.vnet.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=hbathini@linux.vnet.ibm.com \
    --cc=kernelfans@gmail.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=nicholas.piggin@gmail.com \
    --cc=srikar@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).