From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v31 04/12] arm64: mm: allow for unmapping part of kernel mapping
Date: Thu, 2 Feb 2017 23:01:03 +0900 [thread overview]
Message-ID: <20170202140102.GA22666@fireball> (raw)
In-Reply-To: <20170202114437.GH31394@leverpostej>
On Thu, Feb 02, 2017 at 11:44:38AM +0000, Mark Rutland wrote:
> On Thu, Feb 02, 2017 at 07:21:32PM +0900, AKASHI Takahiro wrote:
> > On Wed, Feb 01, 2017 at 04:03:54PM +0000, Mark Rutland wrote:
> > > Hi,
> > >
> > > On Wed, Feb 01, 2017 at 09:46:23PM +0900, AKASHI Takahiro wrote:
> > > > A new function, remove_pgd_mapping(), is added.
> > > > It allows us to unmap a specific portion of kernel mapping later as far as
> > > > the mapping is made using create_pgd_mapping() and unless we try to free
> > > > a sub-set of memory range within a section mapping.
> > >
> > > I'm not keen on adding more page table modification code. It was painful
> > > enough to ensure that those worked in all configurations.
> > >
> > > Why can't we reuse create_pgd_mapping()? If we pass page_mappings_only,
> > > and use an invalid prot (i.e. 0), what is the problem?
> >
> > As I did in v30?
> > (though my implementation in v30 should be improved.)
>
> Something like that. I wasn't entirely sure why we needed to change
> those functions so much, so I'm clearly missing something there. I'll go
> have another look.
I would be much easier if you see my new code.
> > > I can see that we wouldn't free/reallocate the pud or pmd entries, but
> > > the "wasted" memory should be small. If anything, I'd argue that it's
> > > preferable to keep that around so that we don't have to allocate memory
> > > when we need to map the crashkernel region.
> > >
> > > Is there another problem I'm missing?
> >
> > If we don't need to free unused page tables, that would make things
> > much simple. There are still some minor problems on the merge, but
> > we can sort it out.
>
> I'm not sure I follow what you mean by 'on merge' here. Could you
> elaborate?
What I had in mind is some changes needed to handle "__prot(0)" properly
in alloc_init_pxx(). For example, p[mu]d_set_huge() doesn't make
a "zeroed" entry.
-Takahiro AKASHI
> Thanks,
> Mark.
next prev parent reply other threads:[~2017-02-02 14:01 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-01 12:42 [PATCH v31 00/12] add kdump support AKASHI Takahiro
2017-02-01 12:45 ` [PATCH v31 01/12] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 02/12] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2017-02-01 15:07 ` Mark Rutland
2017-02-02 4:21 ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 03/12] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2017-02-01 15:26 ` Mark Rutland
2017-02-02 4:52 ` AKASHI Takahiro
2017-02-02 11:26 ` Mark Rutland
2017-02-02 13:44 ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 04/12] arm64: mm: allow for unmapping part of kernel mapping AKASHI Takahiro
2017-02-01 16:03 ` Mark Rutland
2017-02-02 10:21 ` AKASHI Takahiro
2017-02-02 11:44 ` Mark Rutland
2017-02-02 14:01 ` AKASHI Takahiro [this message]
2017-02-02 14:35 ` Mark Rutland
2017-02-02 14:55 ` AKASHI Takahiro
2017-02-03 6:13 ` AKASHI Takahiro
2017-02-03 14:22 ` Mark Rutland
2017-02-01 12:46 ` [PATCH v31 05/12] arm64: kdump: protect crash dump kernel memory AKASHI Takahiro
2017-02-01 18:00 ` Mark Rutland
2017-02-01 18:25 ` Mark Rutland
2017-02-02 10:39 ` AKASHI Takahiro
2017-02-02 11:54 ` Mark Rutland
2017-02-03 1:45 ` AKASHI Takahiro
2017-02-03 11:51 ` Mark Rutland
2017-02-02 10:45 ` James Morse
2017-02-02 11:19 ` AKASHI Takahiro
2017-02-02 11:48 ` Mark Rutland
2017-02-02 10:31 ` AKASHI Takahiro
2017-02-02 11:16 ` Mark Rutland
2017-02-02 14:36 ` AKASHI Takahiro
2017-02-02 15:36 ` Mark Rutland
2017-02-01 12:46 ` [PATCH v31 06/12] arm64: hibernate: preserve kdump image around hibernation AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 07/12] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 08/12] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 09/12] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2017-02-01 19:21 ` Mark Rutland
2017-02-02 6:24 ` AKASHI Takahiro
2017-02-02 12:03 ` Mark Rutland
2017-02-02 12:08 ` Mark Rutland
2017-02-02 14:39 ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 10/12] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 11/12] Documentation: kdump: describe arm64 port AKASHI Takahiro
2017-02-01 12:48 ` [PATCH v31 12/12] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
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=20170202140102.GA22666@fireball \
--to=takahiro.akashi@linaro.org \
--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).