From: Eric Biggers <ebiggers@kernel.org>
To: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
linux-crypto@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Clang-Built-Linux ML <clang-built-linux@googlegroups.com>,
Fangrui Song <maskray@google.com>,
Peter Smith <peter.smith@linaro.org>
Subject: Re: crypto: x86/crct10dif-pcl - cleanup and optimizations
Date: Wed, 3 Jul 2019 09:14:56 -0700 [thread overview]
Message-ID: <20190703161456.GC21629@sol.localdomain> (raw)
In-Reply-To: <CA+icZUV8693G8jgHw2t9qUay4_Ad-7BgNOkL6z+4z8xNXyL=cA@mail.gmail.com>
Hi Sedat,
On Wed, Jul 03, 2019 at 05:16:40PM +0200, Sedat Dilek wrote:
>
> Hi Eric, Hi Nick,
>
> I am building Linux v5.1.16 with a new llvm-toolchain including the fix for LLD:
>
> "[ELF] Allow placing SHF_MERGE sections with different alignments into
> the same MergeSyntheticSection"
>
> [ Alignment=16 before my patch ]
>
> $ cd arch/x86/crypto/
> $ for o in $(ls *.o) ; do echo [ $o ] ; readelf -WS $o | grep
> rodata\.cst32 ; done
>
> [ crct10dif-pcl-asm_64.o ]
> [ 9] .rodata.cst32.byteshift_table PROGBITS 0000000000000000
> 0004e0 000020 20 AM 0 0 16
>
> [ crct10dif-pclmul.o ]
> [ 9] .rodata.cst32.byteshift_table PROGBITS 0000000000000000
> 000b40 000020 20 AM 0 0 16
>
> [ Alignment=32 after my patch ]
>
> [ crct10dif-pcl-asm_64.o ]
> [ 9] .rodata.cst32.byteshift_table PROGBITS 0000000000000000
> 0004e0 000020 20 AM 0 0 32
>
> [ crct10dif-pclmul.o ]
> [ 9] .rodata.cst32.byteshift_table PROGBITS 0000000000000000
> 000b40 000020 20 AM 0 0 32
>
> I am still building the Linux-kernel but first checks in [3] looks good.
>
> I can send out a separate patch if you like for the issue I have reported.
Sorry, I am still confused. Are you saying that something still needs to be
fixed in the kernel code, and if so, why? To reiterate, the byteshift_table
doesn't actually *need* any particular alignment. Would it avoid the confusion
if I changed it to no alignment? Or is there some section merging related
reason it actually needs to be 32?
>
> I can not say much to ...
>
> > .rodata.cst16.aegis128_const
> > .rodata.cst16.aegis128l_const
> > .rodata.cst16.aegis256_const
> > .rodata.cst16.morus640_const
> > .rodata.cst256.K256
>
> ... as I am not a Linker or Linux/x86/crypto specialist.
Well those all seem to be the same issue; the needed alignment isn't the same as
the entity size. So if the crct10dif one needs to be fixed, these need to be
too. Am I missing something?
- Eric
next prev parent reply other threads:[~2019-07-03 16:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 13:35 crypto: x86/crct10dif-pcl - cleanup and optimizations Sedat Dilek
2019-06-17 18:06 ` Nick Desaulniers
2019-06-17 18:07 ` Nick Desaulniers
2019-06-17 18:22 ` Eric Biggers
2019-07-03 15:16 ` Sedat Dilek
2019-07-03 16:14 ` Eric Biggers [this message]
2019-07-03 18:52 ` Nick Desaulniers
2019-07-04 7:38 ` Sedat Dilek
2019-07-08 18:19 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190703161456.GC21629@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=clang-built-linux@googlegroups.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=maskray@google.com \
--cc=ndesaulniers@google.com \
--cc=peter.smith@linaro.org \
--cc=sedat.dilek@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.