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:   Mon, 24 Sep 2018 11:55:58 +0100
From:   Julien Thierry <julien.thierry@....com>
To:     Suzuki K Poulose <suzuki.poulose@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Jeremy Linton <jeremy.linton@....com>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>
Subject: Re: [PATCH 02/10] irqchip/gic-v3-its: Consolidate LPI_PENDBASE_SZ
 usage



On 24/09/18 11:54, Suzuki K Poulose wrote:
> 
> 
> On 24/09/18 11:50, Julien Thierry wrote:
>> Hi,
>>
>> On 24/09/18 11:33, Suzuki K Poulose wrote:
>>> Hi Marc,
>>>
>>> On 21/09/18 20:59, Marc Zyngier wrote:
>>>> LPI_PENDING_SZ is always used in conjunction with a max(). Let's
>>>> factor this in the definition of the macro, and simplify the rest
>>>> of the code.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier@....com>
>>>> ---
>>>>   drivers/irqchip/irq-gic-v3-its.c | 12 ++++--------
>>>>   1 file changed, 4 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>>>> b/drivers/irqchip/irq-gic-v3-its.c
>>>> index c2df341ff6fa..ed6aab11e019 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -62,7 +62,7 @@ static u32 lpi_id_bits;
>>>>    */
>>>>   #define LPI_NRBITS        lpi_id_bits
>>>>   #define LPI_PROPBASE_SZ        ALIGN(BIT(LPI_NRBITS), SZ_64K)
>>>> -#define LPI_PENDBASE_SZ        ALIGN(BIT(LPI_NRBITS) / 8, SZ_64K)
>>>> +#define LPI_PENDBASE_SZ        max_t(u32, SZ_64K, 
>>>> ALIGN(BIT(LPI_NRBITS) / 8, SZ_64K))
>>>
>>> minor nit: The ALIGN() already aligns the given value up to the required
>>> alignment. So, if the LPI_NRBITS is guaranteed to be non-zero,
>>> we could simply drop the max_t().
>>>
>>
>> Hmmm, Doesn't ALIGN only aligns down? So if "BIT(LPI_NR_BITS) / 8 < 
>> SZ_64K" (i.e. LPI_NRBITS < 20) The ALIGN(..., SZ_64K) would give 0.
> 
> Isn't it the ALIGN_DOWN(), which aligns it down ? Following the kernel
> definitions :
> linux/kernel.h -> uapi/linux/kernel.h
> ALIGN(x,a) =>     __ALIGN_KERNEL(x, a)
>          \ => __ALIGN_KERNEL_MASK(x, (a -1)
>          \ => (((x + (a - 1)) & ~ (a - 1))

Oh, yes you're right, made the wrong assumption.
Your suggestion makes sense. Sorry for the noise.

Thanks,

> 
> Cheers
> Suzuki
> 
> 
>>
>> Thanks,
>>
>>> Rest looks good to me.
>>>
>>> Suzuki
>>>
>>>>   #define LPI_PROP_DEFAULT_PRIO    0xa0
>>>> @@ -1924,12 +1924,9 @@ static int its_alloc_collections(struct 
>>>> its_node *its)
>>>>   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_t(u32, LPI_PENDBASE_SZ, SZ_64K)));
>>>> +                get_order(LPI_PENDBASE_SZ));
>>>>       if (!pend_page)
>>>>           return NULL;
>>>> @@ -1941,8 +1938,7 @@ static struct page 
>>>> *its_allocate_pending_table(gfp_t gfp_flags)
>>>>   static void its_free_pending_table(struct page *pt)
>>>>   {
>>>> -    free_pages((unsigned long)page_address(pt),
>>>> -           get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K)));
>>>> +    free_pages((unsigned long)page_address(pt), 
>>>> get_order(LPI_PENDBASE_SZ));
>>>>   }
>>>>   static void its_cpu_init_lpis(void)
>>>>
>>

-- 
Julien Thierry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ