linux-kernel - Re: [PATCH v2 1/4] nitro_enclaves: merge contiguous physical memory regions

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, 21 Sep 2021 17:20:23 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Longpeng(Mike)" <longpeng2@...wei.com>
Cc:     andraprs@...zon.com, lexnv@...zon.com, alcioa@...zon.com,
        linux-kernel@...r.kernel.org, arei.gonglei@...wei.com,
        kamal@...onical.com, pbonzini@...hat.com, sgarzare@...hat.com,
        stefanha@...hat.com, vkuznets@...hat.com,
        ne-devel-upstream@...zon.com
Subject: Re: [PATCH v2 1/4] nitro_enclaves: merge contiguous physical memory
 regions

On Tue, Sep 21, 2021 at 11:10:36PM +0800, Longpeng(Mike) wrote:
> There can be cases when there are more memory regions that need to be
> set for an enclave than the maximum supported number of memory regions
> per enclave. One example can be when the memory regions are backed by 2
> MiB hugepages (the minimum supported hugepage size).
> 
> Let's merge the adjacent regions if they are physical contiguous. This
> way the final number of memory regions is less than before merging and
> could potentially avoid reaching maximum.
> 
> Signed-off-by: Longpeng(Mike) <longpeng2@...wei.com>

I need a real (i.e. legal) name for a signed-off-by line please.

> ---
>  drivers/virt/nitro_enclaves/ne_misc_dev.c | 87 ++++++++++++++++++++-----------
>  1 file changed, 58 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/virt/nitro_enclaves/ne_misc_dev.c b/drivers/virt/nitro_enclaves/ne_misc_dev.c
> index e21e1e8..a4776fc 100644
> --- a/drivers/virt/nitro_enclaves/ne_misc_dev.c
> +++ b/drivers/virt/nitro_enclaves/ne_misc_dev.c
> @@ -126,6 +126,26 @@ struct ne_cpu_pool {
>  static struct ne_cpu_pool ne_cpu_pool;
>  
>  /**
> + * struct phys_mem_region - Physical memory region
> + * @paddr:	The start physical address of the region.
> + * @size:	The sizeof of the region.
> + */
> +struct phys_mem_region {
> +	u64 paddr;
> +	u64 size;
> +};
> +
> +/**
> + * struct phys_contig_mem_region - Physical contiguous memory regions
> + * @num:	The number of regions that currently has.
> + * @region:	The array of physical memory regions.
> + */
> +struct phys_contig_mem_region {
> +	unsigned long num;
> +	struct phys_mem_region region[0];
> +};

Why create your own structures and not use the in-kernel ones for stuff
like this?  What is wrong with the existing memory region or resource
handling logic?

thanks,

greg k-h