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-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 18 May 2021 13:06:33 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Yanfei Xu <yanfei.xu@...driver.com>
Cc:     rppt@...nel.org, ardb@...nel.org, linus.walleij@...aro.org,
        akpm@...ux-foundation.org, carver4lio@....com,
        tiantao6@...ilicon.com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm: make the size of vmalloc in cmdline and meminfo
 uniform

On Tue, May 18, 2021 at 12:29:32PM +0100, Russell King (Oracle) wrote:
> On Tue, May 18, 2021 at 07:12:54PM +0800, Yanfei Xu wrote:
> > The value of "vmalloc=" set in cmdline is always 8M more than the value
> > of "VmallocTotal" in meminfo. When use the "vmalloc=" parameter, user
> > expect to get the size what they input, and no need to consider the 8M
> > "hole" hided in codes. This commit make real vmalloc size equal to value
> > of "vmalloc=" in cmdline.
> > 
> > Also, the commit will reduce the size of vmalloc printed in boot message
> > by 8M when the size set in cmdline is irrational.
> 
> Hi,
> 
> I think I'd like to do several cleanups with this:
> 
> 1. change vmalloc_min to be an unsigned long.
> 2. exclude VMALLOC_OFFSET from vmalloc_min, moving it into
>    adjust_lowmem_bounds where vmalloc_min is used.
> 3. rename vmalloc_min to be vmalloc_start
> 4. enforce vmalloc_start to be a multiple of 2MiB
> 5. in early_vmalloc(), calculate vmalloc_max as:
> 	VMALLOC_END - (PAGE_OFFSET + SZ_32M + VMALLOC_OFFSET)
>    and use that to set the upper bound of vmalloc_reserve (which is
>    something your patch doesn't do, which I think is a bug.
> 
> Thoughts?

I've slightly modified the above idea, and will shortly follow up with
some patches to show the idea a bit better...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ