public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v31 04/12] arm64: mm: allow for unmapping part of kernel mapping
Date: Fri, 3 Feb 2017 14:22:16 +0000	[thread overview]
Message-ID: <20170203142216.GF30497@leverpostej> (raw)
In-Reply-To: <20170203061317.GC29585@linaro.org>

Hi,

On Fri, Feb 03, 2017 at 03:13:18PM +0900, AKASHI Takahiro wrote:
> On Thu, Feb 02, 2017 at 11:55:54PM +0900, AKASHI Takahiro wrote:
> > On Thu, Feb 02, 2017 at 02:35:35PM +0000, Mark Rutland wrote:

> > > I think that if we only allow ourselves to make PTEs invalid, we don't
> > > have to handle that case. If we use page_mappings_only, we should only
> > > check pgattr_change_is_safe() for the pte level, and the {pmd,pud,pgd}
> > > entries shouldn't change.
> > > 
> > > Is the below sufficient to allow that, or have I missed something?
> > 
> > I think it will be OK, but will double-check tomorrow.
> > However, is is acceptable that create_pgd_mapping( __prot(0) ) can
> > only handle the cases of page-mapping-only?
> > That would be fine to kdump, but in general?

Given we're only going to use this for page mappings, I think it's fine
(and preferable) to restrict it to page mappings for now. Until we need
to do this for the pmd/pud/pgd levels, those won't see any testing, and
it will be very easy for us to accidentally break this.

> My proposed code is attached below.
> I think that the changes are quite trivial and it works even if
> there is a section mapping as far as we refrain from reclaiming
> unsed p[ug]d tables.
> 
> (Of course, we can't merely unmap a subset of a section mapping here.)

Sure. We have a similar restriction when changing permissions, so I
think that's fine.

> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 17243e43184e..7f96eabc99d7 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -140,7 +140,11 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>                         __prot = prot;
>         }
> 
> -		set_pte(pte, pfn_pte(pfn, __prot));
> +		if (pgprot_val(prot) & PTE_VALID)
> +			set_pte(pte, pfn_pte(pfn, __prot));
> +		else
> +			pte_clear(null, null, pte);

It took me a moment to figure out how this line could compile. ;)

I'm happy to take this approach in alloc_init_pte(), but as above I'd
prefer that we only handled it there, and left the pmd/pud/pgd code
as-is for now.

We can/should add a comment to make that clear.

Thanks,
Mark.

  reply	other threads:[~2017-02-03 14:22 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
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 [this message]
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=20170203142216.GF30497@leverpostej \
    --to=mark.rutland@arm.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