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]
Message-ID: <0EA9CBD4-D083-4546-BFAC-9C3A97420E5B@zytor.com>
Date:   Thu, 23 Jun 2022 11:22:52 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Dave Hansen <dave.hansen@...el.com>, lizhe.67@...edance.com,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org
CC:     lizefan.x@...edance.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] memmap: introduce cmdline parameter "memmap=nn[KMG]$" without start addr

On June 23, 2022 7:06:36 AM PDT, Dave Hansen <dave.hansen@...el.com> wrote:
>On 6/22/22 23:24, lizhe.67@...edance.com wrote:
>> In our scenario, we need reserve or alloc large continous memory like
>> 256M in machine which have different memory specification at just
>> boot phase for a user land process.
>
>Just marking the memory reserved doesn't do any good by itself.  There
>must be some *other* kernel code to find this reserved area and make it
>available to userspace.
>
>It seems kinda silly to add this to the kernel without also adding the
>other half of the solution.  Plus, we don't really even know what this
>is for.  Are there other, better solutions?  I certainly can't offer any
>because this changelog did not provide a full picture of the problem
>this solves.

Don't we already have a large contiguous physical memory allocator for this reason (misdesigned hardware?)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ