From: Stephen Boyd <swboyd@chromium.org>
To: Hsin-Yi Wang <hsinyi@chromium.org>, Mike Rapoport <rppt@linux.ibm.com>
Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Kees Cook <keescook@chromium.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Architecture Mailman List <boot-architecture@lists.linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Miles Chen <miles.chen@mediatek.com>,
James Morse <james.morse@arm.com>,
Andrew Murray <andrew.murray@arm.com>
Subject: Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan()
Date: Tue, 14 May 2019 14:05:43 -0700 [thread overview]
Message-ID: <155786794318.14659.2925897827978978040@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAJMQK-hKrU2J0_uGe3eO_JTNwM=HRkXbDx2u45izcdD7wqwGeQ@mail.gmail.com>
Quoting Hsin-Yi Wang (2019-05-13 04:14:32)
> On Mon, May 13, 2019 at 4:59 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> >
> > This makes the fdt mapped without the call to meblock_reserve(fdt) which
> > makes the fdt memory available for memblock allocations.
> >
> > Chances that is will be actually allocated are small, but you know, things
> > happen.
> >
> > IMHO, instead of calling directly __fixmap_remap_fdt() it would be better
> > to add pgprot parameter to fixmap_remap_fdt(). Then here and in kaslr.c it
> > can be called with PAGE_KERNEL and below with PAGE_KERNEL_RO.
> >
> > There is no problem to call memblock_reserve() for the same area twice,
> > it's essentially a NOP.
> >
> Thanks for the suggestion. Will update fixmap_remap_fdt() in next patch.
>
> However, I tested on some arm64 platform, if we also call
> memblock_reserve() in kaslr.c, would cause warning[1] when
> memblock_reserve() is called again in setup_machine_fdt(). The warning
> comes from https://elixir.bootlin.com/linux/latest/source/mm/memblock.c#L601
> ```
> if (type->regions[0].size == 0) {
> WARN_ON(type->cnt != 1 || type->total_size);
> ...
> ```
>
> Call memblock_reserve() multiple times after setup_machine_fdt()
> doesn't have such warning though.
>
> I didn't trace the real reason causing this. But in this case, maybe
> don't call memblock_reserve() in kaslr?
>
Why not just have fixmap_remap_fdt() that maps it as RW and reserves
memblock once, and then call __fixmap_remap_fdt() with RO after
early_init_dt_scan() or unflatten_device_tree() is called? Why the
desire to call memblock_reserve() twice or even three times?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org>
To: Hsin-Yi Wang <hsinyi@chromium.org>, Mike Rapoport <rppt@linux.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Architecture Mailman List <boot-architecture@lists.linaro.org>,
Michal Hocko <mhocko@suse.com>, Kees Cook <keescook@chromium.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
Miles Chen <miles.chen@mediatek.com>,
Rob Herring <robh+dt@kernel.org>,
James Morse <james.morse@arm.com>,
Andrew Murray <andrew.murray@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Frank Rowand <frowand.list@gmail.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan()
Date: Tue, 14 May 2019 14:05:43 -0700 [thread overview]
Message-ID: <155786794318.14659.2925897827978978040@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAJMQK-hKrU2J0_uGe3eO_JTNwM=HRkXbDx2u45izcdD7wqwGeQ@mail.gmail.com>
Quoting Hsin-Yi Wang (2019-05-13 04:14:32)
> On Mon, May 13, 2019 at 4:59 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> >
> > This makes the fdt mapped without the call to meblock_reserve(fdt) which
> > makes the fdt memory available for memblock allocations.
> >
> > Chances that is will be actually allocated are small, but you know, things
> > happen.
> >
> > IMHO, instead of calling directly __fixmap_remap_fdt() it would be better
> > to add pgprot parameter to fixmap_remap_fdt(). Then here and in kaslr.c it
> > can be called with PAGE_KERNEL and below with PAGE_KERNEL_RO.
> >
> > There is no problem to call memblock_reserve() for the same area twice,
> > it's essentially a NOP.
> >
> Thanks for the suggestion. Will update fixmap_remap_fdt() in next patch.
>
> However, I tested on some arm64 platform, if we also call
> memblock_reserve() in kaslr.c, would cause warning[1] when
> memblock_reserve() is called again in setup_machine_fdt(). The warning
> comes from https://elixir.bootlin.com/linux/latest/source/mm/memblock.c#L601
> ```
> if (type->regions[0].size == 0) {
> WARN_ON(type->cnt != 1 || type->total_size);
> ...
> ```
>
> Call memblock_reserve() multiple times after setup_machine_fdt()
> doesn't have such warning though.
>
> I didn't trace the real reason causing this. But in this case, maybe
> don't call memblock_reserve() in kaslr?
>
Why not just have fixmap_remap_fdt() that maps it as RW and reserves
memblock once, and then call __fixmap_remap_fdt() with RO after
early_init_dt_scan() or unflatten_device_tree() is called? Why the
desire to call memblock_reserve() twice or even three times?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org>
To: Hsin-Yi Wang <hsinyi@chromium.org>, Mike Rapoport <rppt@linux.ibm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Architecture Mailman List <boot-architecture@lists.linaro.org>,
Michal Hocko <mhocko@suse.com>, Kees Cook <keescook@chromium.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-kernel@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
Miles Chen <miles.chen@mediatek.com>,
Rob Herring <robh+dt@kernel.org>,
James Morse <james.morse@arm.com>,
Andrew Murray <andrew.murray@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Frank Rowand <frowand.list@gmail.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan()
Date: Tue, 14 May 2019 14:05:43 -0700 [thread overview]
Message-ID: <155786794318.14659.2925897827978978040@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <CAJMQK-hKrU2J0_uGe3eO_JTNwM=HRkXbDx2u45izcdD7wqwGeQ@mail.gmail.com>
Quoting Hsin-Yi Wang (2019-05-13 04:14:32)
> On Mon, May 13, 2019 at 4:59 PM Mike Rapoport <rppt@linux.ibm.com> wrote:
>
> >
> > This makes the fdt mapped without the call to meblock_reserve(fdt) which
> > makes the fdt memory available for memblock allocations.
> >
> > Chances that is will be actually allocated are small, but you know, things
> > happen.
> >
> > IMHO, instead of calling directly __fixmap_remap_fdt() it would be better
> > to add pgprot parameter to fixmap_remap_fdt(). Then here and in kaslr.c it
> > can be called with PAGE_KERNEL and below with PAGE_KERNEL_RO.
> >
> > There is no problem to call memblock_reserve() for the same area twice,
> > it's essentially a NOP.
> >
> Thanks for the suggestion. Will update fixmap_remap_fdt() in next patch.
>
> However, I tested on some arm64 platform, if we also call
> memblock_reserve() in kaslr.c, would cause warning[1] when
> memblock_reserve() is called again in setup_machine_fdt(). The warning
> comes from https://elixir.bootlin.com/linux/latest/source/mm/memblock.c#L601
> ```
> if (type->regions[0].size == 0) {
> WARN_ON(type->cnt != 1 || type->total_size);
> ...
> ```
>
> Call memblock_reserve() multiple times after setup_machine_fdt()
> doesn't have such warning though.
>
> I didn't trace the real reason causing this. But in this case, maybe
> don't call memblock_reserve() in kaslr?
>
Why not just have fixmap_remap_fdt() that maps it as RW and reserves
memblock once, and then call __fixmap_remap_fdt() with RO after
early_init_dt_scan() or unflatten_device_tree() is called? Why the
desire to call memblock_reserve() twice or even three times?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-14 21:05 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-13 0:38 [PATCH v2 1/2] fdt: add support for rng-seed Hsin-Yi Wang
2019-05-13 0:38 ` Hsin-Yi Wang
2019-05-13 0:38 ` Hsin-Yi Wang
2019-05-13 0:38 ` [PATCH v2 2/2] amr64: map FDT as RW for early_init_dt_scan() Hsin-Yi Wang
2019-05-13 0:38 ` Hsin-Yi Wang
2019-05-13 8:58 ` Mike Rapoport
2019-05-13 8:58 ` Mike Rapoport
2019-05-13 11:14 ` Hsin-Yi Wang
2019-05-13 11:14 ` Hsin-Yi Wang
2019-05-13 11:14 ` Hsin-Yi Wang
2019-05-14 15:42 ` Mike Rapoport
2019-05-14 15:42 ` Mike Rapoport
2019-05-14 15:42 ` Mike Rapoport
2019-05-15 10:24 ` Hsin-Yi Wang
2019-05-15 10:24 ` Hsin-Yi Wang
2019-05-15 10:24 ` Hsin-Yi Wang
2019-05-15 20:11 ` Ard Biesheuvel
2019-05-15 20:11 ` Ard Biesheuvel
2019-05-15 20:11 ` Ard Biesheuvel
2019-05-16 11:07 ` Mike Rapoport
2019-05-16 11:07 ` Mike Rapoport
2019-05-16 11:07 ` Mike Rapoport
2019-05-14 21:05 ` Stephen Boyd [this message]
2019-05-14 21:05 ` Stephen Boyd
2019-05-14 21:05 ` Stephen Boyd
2019-05-15 5:00 ` Mike Rapoport
2019-05-15 5:00 ` Mike Rapoport
2019-05-15 5:00 ` Mike Rapoport
2019-05-15 10:34 ` Hsin-Yi Wang
2019-05-15 10:34 ` Hsin-Yi Wang
2019-05-15 10:34 ` Hsin-Yi Wang
2019-05-13 8:42 ` [PATCH v2 1/2] fdt: add support for rng-seed Mike Rapoport
2019-05-13 8:42 ` Mike Rapoport
2019-05-13 8:42 ` Mike Rapoport
2019-05-13 13:14 ` Rob Herring
2019-05-13 13:14 ` Rob Herring
2019-05-13 13:14 ` Rob Herring
2019-05-15 9:07 ` Hsin-Yi Wang
2019-05-15 9:07 ` Hsin-Yi Wang
2019-05-15 9:07 ` Hsin-Yi Wang
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=155786794318.14659.2925897827978978040@swboyd.mtv.corp.google.com \
--to=swboyd@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=andrew.murray@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=boot-architecture@lists.linaro.org \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=hsinyi@chromium.org \
--cc=james.morse@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=miles.chen@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=will.deacon@arm.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 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.