lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240416120635.361838-1-skseofh@gmail.com>
Date: Tue, 16 Apr 2024 21:06:34 +0900
From: skseofh@...il.com
To: robh@...nel.org,
	saravanak@...gle.com,
	rppt@...nel.org,
	akpm@...ux-foundation.org
Cc: devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: [PATCH v2] memblock: add no-map alloc functions


> > From: Daero Lee <daero_le.lee@...sung.com>
> > 
> > Like reserved-memory with the no-map property, there are memory regions
> > need to be allocated in memblock.memory marked with the
> > MEMBLOCK_NOMAP flag, but sholud not be allocated in memblock.reserved.
> 
> Can you please explain your use case?
> Why do you need this functionality?
Thank you for your comments.
I added a example to the commit message.

> > So, functions were added that find the required memory area in
> > memblock.memory, but do not allocate it to memblock.reserved.
> > 
> > The early_init_dt_alloc_reserved_memory_arch function was modified
> > using the no-map alloc function.
> > 
> > Signed-off-by: Daero Lee <daero_le.lee@...sung.com>
> > ---
> >  drivers/of/of_reserved_mem.c |  9 +++--
> >  mm/memblock.c                | 78 ++++++++++++++++++++++++++++++++++++
> >  2 files changed, 84 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 8236ecae2953..504f2f60689c 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -40,15 +40,18 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
> >  
> >  	end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
> >  	align = !align ? SMP_CACHE_BYTES : align;
> > -	base = memblock_phys_alloc_range(size, align, start, end);
> > +	if (nomap) {
> > +		base = memblock_phys_alloc_range_nomap(size, align, start, end);
> > +	} else {
> > +		base = memblock_phys_alloc_range(size, align, start, end);
> > +	}
> > +	
>
> This changes behaviour of internal function, what effect will it have on
> the users?
I added explanation about this to the commit message, too.

Thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ