devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] cma: check for memory region overlapping
@ 2023-07-20 16:07 Binglei Wang
  2023-07-21 16:21 ` Rob Herring
  0 siblings, 1 reply; 3+ messages in thread
From: Binglei Wang @ 2023-07-20 16:07 UTC (permalink / raw)
  To: robh+dt; +Cc: frowand.list, devicetree, linux-kernel, iommu, l3b2w1

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.

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);
 			} 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;
 	}
 
+	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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] cma: check for memory region overlapping
  2023-07-20 16:07 [PATCH] cma: check for memory region overlapping Binglei Wang
@ 2023-07-21 16:21 ` Rob Herring
  2023-07-21 21:34   ` binglei wang
  0 siblings, 1 reply; 3+ messages in thread
From: Rob Herring @ 2023-07-21 16:21 UTC (permalink / raw)
  To: Binglei Wang; +Cc: frowand.list, devicetree, linux-kernel, iommu

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
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] cma: check for memory region overlapping
  2023-07-21 16:21 ` Rob Herring
@ 2023-07-21 21:34   ` binglei wang
  0 siblings, 0 replies; 3+ messages in thread
From: binglei wang @ 2023-07-21 21:34 UTC (permalink / raw)
  To: Rob Herring; +Cc: frowand.list, devicetree, linux-kernel, iommu

Rob Herring <robh@kernel.org> 于2023年7月22日周六 00:21写道:
>
> 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.
> >

Dear Rob:
Thanks for your reply.

In the production environment, I encountered this issue in the 5.4 kernel.
The goal is just to warn enough to fix the DT.

> > 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?
>
>

yes, in some cases, freeing the DT CMA area is the right thing to do.
in another case, like the read-only panic,  freeing will cause problems.

Actually,  giving a warning message is already sufficient.
I should not overthink it, after all, it was caused by human factors.

When using command line,
I find cma_declare_contiguous_nid will check the overlap in the latest kernel.
But in the program flow of parsing dts, both the 5.4 kernel and the
latest version of the kernel lack this check.
That's the reason for this patch.

> >       }
> >
> > +     if (memblock_is_region_reserved(rmem->base, rmem->size)) {
> > +             pr_info("Reserved memory: overlap with exsiting one\n");
> > +             return -EBUSY;
> > +     }

Do you think a warning message is sufficient?

Best wishes
Binglei Wang.

> > +
> >       if (!of_get_flat_dt_prop(node, "reusable", NULL) ||
> >           of_get_flat_dt_prop(node, "no-map", NULL))
> >               return -EINVAL;
> > --
> > 2.34.1
> >

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-07-21 21:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-20 16:07 [PATCH] cma: check for memory region overlapping Binglei Wang
2023-07-21 16:21 ` Rob Herring
2023-07-21 21:34   ` binglei wang

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).