From: Balbir Singh <bsingharora@gmail.com>
To: Reza Arbab <arbab@linux.vnet.ibm.com>
Cc: Balbir Singh <bsingharora@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Alistair Popple <apopple@au1.ibm.com>
Subject: Re: [PATCH v5 4/4] powerpc/mm: unstub radix__vmemmap_remove_mapping()
Date: Wed, 18 Jan 2017 07:23:45 +0530 [thread overview]
Message-ID: <20170118015345.GA18959@localhost.localdomain> (raw)
In-Reply-To: <20170117183653.7bd62joj5yog5yca@arbab-vm>
On Tue, Jan 17, 2017 at 12:36:53PM -0600, Reza Arbab wrote:
> On Tue, Jan 17, 2017 at 12:55:13PM +0530, Balbir Singh wrote:
> > On Mon, Jan 16, 2017 at 01:07:46PM -0600, Reza Arbab wrote:
> > > Use remove_pagetable() and friends for radix vmemmap removal.
> > >
> > > We do not require the special-case handling of vmemmap done in the x86
> > > versions of these functions. This is because vmemmap_free() has already
> > > freed the mapped pages, and calls us with an aligned address range.
> > >
> > > So, add a few failsafe WARNs, but otherwise the code to remove physical
> > > mappings is already sufficient for vmemmap.
> >
> > I wonder if we really need them?
>
> Not sure what the guideline is for a "this shouldn't happen" WARN. It could
> save us some grief, should our vmemmap code ever start calling with an
> unaligned range, like it does on x86.
>
Fair enough
Acked-by: Balbir Singh <bsingharora@gmail.com>
prev parent reply other threads:[~2017-01-18 1:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-16 19:07 [PATCH v5 0/4] powerpc/mm: enable memory hotplug on radix Reza Arbab
2017-01-16 19:07 ` [PATCH v5 1/4] powerpc/mm: refactor radix physical page mapping Reza Arbab
2017-01-17 6:46 ` Balbir Singh
2017-01-17 18:34 ` Reza Arbab
2017-01-18 1:14 ` Balbir Singh
2017-01-30 8:38 ` Michael Ellerman
2017-01-30 17:28 ` Reza Arbab
2017-01-30 21:58 ` Michael Ellerman
2017-02-01 1:05 ` [v5,1/4] " Michael Ellerman
2017-01-16 19:07 ` [PATCH v5 2/4] powerpc/mm: add radix__create_section_mapping() Reza Arbab
2017-01-17 6:48 ` Balbir Singh
2017-01-16 19:07 ` [PATCH v5 3/4] powerpc/mm: add radix__remove_section_mapping() Reza Arbab
2017-01-17 7:22 ` Balbir Singh
2017-01-17 18:36 ` Reza Arbab
2017-01-18 1:22 ` Balbir Singh
2017-01-16 19:07 ` [PATCH v5 4/4] powerpc/mm: unstub radix__vmemmap_remove_mapping() Reza Arbab
2017-01-17 7:25 ` Balbir Singh
2017-01-17 18:36 ` Reza Arbab
2017-01-18 1:53 ` Balbir Singh [this message]
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=20170118015345.GA18959@localhost.localdomain \
--to=bsingharora@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=apopple@au1.ibm.com \
--cc=arbab@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.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.