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: <20180827030742.GA11545@192.168.1.2>
Date:   Mon, 27 Aug 2018 11:07:42 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Chao Fan <fanc.fnst@...fujitsu.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        keescook@...omium.org, n-horiguchi@...jp.nec.com,
        indou.takao@...fujitsu.com, caoj.fnst@...fujitsu.com,
        douly.fnst@...fujitsu.com
Subject: Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter
 immovable memory

On 08/27/18 at 10:56am, Chao Fan wrote:

> >> +#ifdef CONFIG_MEMORY_HOTREMOVE
> >> +/*
> >> + * According to ACPI table, filter the immvoable memory regions
> >> + * and store them in immovable_mem[].
> >> + */
> >> +static void handle_immovable_mem(void)
> >
> >Can we change this function like below, passed in the immovable_mem and
> >the array lengty, the value of num_immovable_mem will be passed back?
> >
> >static void handle_immovable_mem(char* region, int max, int *num)
> >{
> >}
> >
> >Like this, you don't need patch 1/4 to make a header file, just put this
> >function handle_immovable_mem() into acpitb.c since it's handling acpi
> >tables. And its name can be get_immovable_mem().
> 
> That makes sense.
> But if we change like this, we can put the whole function to acpitb.c.
> It will be like:
> static void handle_immovable_mem(int *num)
> {
> }
> Because the value of immovable_mem is filled in handle_immovable_mem,
> it's better to put immovable_mem in acpitb.c also, then extern in
> kaslr.c.

Yes, it's fine to me. Thanks.

> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ