linux-kernel - Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

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: <20180123214659.GG21977@gate.crashing.org>
Date:   Tue, 23 Jan 2018 15:47:00 -0600
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Christophe LEROY <christophe.leroy@....fr>
Cc:     "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Scott Wood <oss@...error.net>, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

On Mon, Jan 22, 2018 at 08:52:53AM +0100, Christophe LEROY wrote:
> >Just make sure to declare all functions, or define it to some empty
> >thing, or #ifdeffery if you have to.  There are many options, it is
> >not hard, and if it means you have to pull code further apart that is
> >not so bad: you get cleaner, clearer code.
> 
> Ok, if I understand well, your comment applies to the following indeed, 
> so you confirm the #ifdef is necessary.

As I said, not necessary, but it might be the easiest or even the
cleanest here.  Something for you and the maintainers to fight about,
I'll stay out of it :-)

> However, my question was related to another part of the current 
> patchset, where the functions are always refined:
> 
> 
> On PPC32 we set:
> 
> +#define SLICE_LOW_SHIFT		28
> +#define SLICE_HIGH_SHIFT	0
> 
> On PPC64 we set:
> 
>  #define SLICE_LOW_SHIFT		28
>  #define SLICE_HIGH_SHIFT	40
> 
> We define:
> 
> +#define slice_bitmap_zero(dst, nbits) \
> +	do { if (nbits) bitmap_zero(dst, nbits); } while (0)
> 
> 
> We have a function with:
> {
> 	slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
>  	slice_bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
> }

SLICE_NUM_xx is not the same as SLICE_xx_SHIFT; I don't see how any of
those shift values give nbits == 0.

> So the question is to find the better approach. Is the above approach 
> correct, including performance wise ?

If slice_bitmap_zero is inlined (or partially inlined) it is fine.  Is it?


Segher