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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2203072252300.47558@angie.orcam.me.uk>
Date:   Mon, 7 Mar 2022 23:09:28 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Mike Rapoport <rppt@...nel.org>
cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>, linux-mips@...r.kernel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/4] MIPS: Refactor early_parse_mem() to fix mem=
 parameter

On Tue, 8 Mar 2022, Mike Rapoport wrote:

> > So can I just limit amount of memory without interfering with normal
> > memory detection ?
> 
> Maybe it's better to add a new encoding to mem= that will have the semantics
> of limiting amount of memory?
> 
> E.g.
> 
> mem=384M@
> 
> would mean "only use 384M of memory that firmware reported" while
> 
> mem=384M would mean "set memory to 0 - 384M" as it does now.

 I think you're going in the right direction, we'd just need to sort out 
the most reasonable syntax for the new semantics; `mem=384M@' just seems 
too analogous to me to `mem=384M@0'.  Maybe `mem=384M-'?

 NB that would have to work with the existing overrides, for e.g.:

`mem=192M@0 mem=192M@...M mem=384M-'

to produce the following memory ranges available for use:

  Normal   [mem 0x0000000000000000-0x000000000bffffff]
  Normal   [mem 0x0000000010000000-0x0000000017ffffff]

(so that you can paste the final cap at some command prompt and still have 
earlier parameters respected that may have been passed by the firmware or 
bootloader, or built in).

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ