linux-kernel - Re: [RFC PATCH 11/33] irqchip/gic-v3-its: Split out pending table allocation

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:   Thu, 16 Mar 2017 09:57:34 +0100
From:   Auger Eric <eric.auger@...hat.com>
To:     Marc Zyngier <marc.zyngier@....com>, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [RFC PATCH 11/33] irqchip/gic-v3-its: Split out pending table
 allocation

Hi Marc,

On 17/01/2017 11:20, Marc Zyngier wrote:
> Just as for the property table, let's move the pending table
> allocation to a separate function.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier@....com>
Reviewed-by: Eric Auger <eric.auger@...hat.com>

Thanks

Eric

> ---
>  drivers/irqchip/irq-gic-v3-its.c | 29 ++++++++++++++++++++---------
>  1 file changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 14305db1..dce8f8c 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1188,6 +1188,24 @@ static int its_alloc_collections(struct its_node *its)
>  	return 0;
>  }
>  
> +static struct page *its_allocate_pending_table(gfp_t gfp_flags)
> +{
> +	struct page *pend_page;
> +	/*
> +	 * The pending pages have to be at least 64kB aligned,
> +	 * hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below.
> +	 */
> +	pend_page = alloc_pages(gfp_flags | __GFP_ZERO,
> +				get_order(max(LPI_PENDBASE_SZ, SZ_64K)));
> +	if (!pend_page)
> +		return NULL;
> +
> +	/* Make sure the GIC will observe the zero-ed page */
> +	gic_flush_dcache_to_poc(page_address(pend_page), LPI_PENDBASE_SZ);
> +
> +	return pend_page;
> +}
> +
>  static void its_cpu_init_lpis(void)
>  {
>  	void __iomem *rbase = gic_data_rdist_rd_base();
> @@ -1198,21 +1216,14 @@ static void its_cpu_init_lpis(void)
>  	pend_page = gic_data_rdist()->pend_page;
>  	if (!pend_page) {
>  		phys_addr_t paddr;
> -		/*
> -		 * The pending pages have to be at least 64kB aligned,
> -		 * hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below.
> -		 */
> -		pend_page = alloc_pages(GFP_NOWAIT | __GFP_ZERO,
> -					get_order(max(LPI_PENDBASE_SZ, SZ_64K)));
> +
> +		pend_page = its_allocate_pending_table(GFP_NOWAIT);
>  		if (!pend_page) {
>  			pr_err("Failed to allocate PENDBASE for CPU%d\n",
>  			       smp_processor_id());
>  			return;
>  		}
>  
> -		/* Make sure the GIC will observe the zero-ed page */
> -		gic_flush_dcache_to_poc(page_address(pend_page), LPI_PENDBASE_SZ);
> -
>  		paddr = page_to_phys(pend_page);
>  		pr_info("CPU%d: using LPI pending table @%pa\n",
>  			smp_processor_id(), &paddr);
>