From: Rob Herring <robh@kernel.org>
To: Binglei Wang <l3b2w1@gmail.com>
Cc: frowand.list@gmail.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Subject: Re: [PATCH] cma: check for memory region overlapping
Date: Fri, 21 Jul 2023 10:21:14 -0600 [thread overview]
Message-ID: <20230721162114.GA1321524-robh@kernel.org> (raw)
In-Reply-To: <20230720160729.39324-1-l3b2w1@gmail.com>
On Fri, Jul 21, 2023 at 12:07:29AM +0800, Binglei Wang wrote:
> From: Binglei Wang <l3b2w1@gmail.com>
>
> Cma memory region editted carelessly in dts may overlap
> with kernel code/data memory region which is reserved by memblock
> during the early phase of system memory initialization.
Is your goal for the kernel to function with this careless editing or
warn enough to fix the DT?
What if other regions overlap with the kernel? Wouldn't we have the same
problem?
>
> Without checking overlap and cma area setup done,
> this region will be released to buddy system later.
>
> When memory usage under pressure, memory allocated from
> this region will collide with kernel code which is read-only.
> And the following writing to this region will trigger the panic
> of writing to read-only memory.
>
> So when rmem_cma_setup returns EBUSY, do not phys-free this region
> to memblock or else we end up with free the kernel code memory
> to buddy system.
>
> Signed-off-by: Binglei Wang <l3b2w1@gmail.com>
> ---
> drivers/of/of_reserved_mem.c | 3 ---
> kernel/dma/contiguous.c | 5 +++++
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 7ec94cfcb..d62cc76ef 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -338,9 +338,6 @@ void __init fdt_init_reserved_mem(void)
> rmem->name);
> if (nomap)
> memblock_clear_nomap(rmem->base, rmem->size);
> - else
> - memblock_phys_free(rmem->base,
> - rmem->size);
I don't understand this change. Seems like perhaps someone would want
the free here?
> } else {
> phys_addr_t end = rmem->base + rmem->size - 1;
> bool reusable =
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 6ea80ae42..a349f3e97 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -410,6 +410,11 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
> return -EBUSY;
Here we return EBUSY if we are using cmdline params. In that case, isn't
freeing the DT CMA area the right thing to do?
> }
>
> + if (memblock_is_region_reserved(rmem->base, rmem->size)) {
> + pr_info("Reserved memory: overlap with exsiting one\n");
> + return -EBUSY;
> + }
> +
> if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
> of_get_flat_dt_prop(node, "no-map", NULL))
> return -EINVAL;
> --
> 2.34.1
>
next prev parent reply other threads:[~2023-07-21 16:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 16:07 [PATCH] cma: check for memory region overlapping Binglei Wang
2023-07-21 16:21 ` Rob Herring [this message]
2023-07-21 21:34 ` binglei 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=20230721162114.GA1321524-robh@kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=l3b2w1@gmail.com \
--cc=linux-kernel@vger.kernel.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).