Re: [RFC] crypto/sm4: Fix objtool/libelf warning

[Tianjia Zhang <tianjia.zhang@linux.alibaba.com>]

Hi Peter,

On 10/8/21 4:22 AM, Peter Zijlstra wrote:
> Hi,
> 
> objtool is yielding the obscure libelf warning:
> 
>    vmlinux.o: warning: objtool: elf_update: invalid section entry size
> 
> Which I tracked down to section:
> 
>    [3023] .rodata.cst164    PROGBITS        0000000000000000 1ab501e0 000154 a4  AM  0   0 16
> 
> Which has a section size of 0x154 (340) and an entry size of 0xa4 (164).
> An obvious mis-match.
> 
>  From there, git-grep quickly yields:
> 
>    arch/x86/crypto/sm4-aesni-avx-asm_64.S:.section .rodata.cst164, "aM", @progbits, 164
>    arch/x86/crypto/sm4-aesni-avx2-asm_64.S:.section        .rodata.cst164, "aM", @progbits, 164
> 
> So those files create this .rodata section with an explicit entry size,
> but then don't respect it themselves. Removing the entry size makes the
> warning go away, but I can't tell if that's right or not, given there is
> zero clue as to why that entry size was specified to begin with.
> 
> Please explain...
> 
> ---
> diff --git a/arch/x86/crypto/sm4-aesni-avx-asm_64.S b/arch/x86/crypto/sm4-aesni-avx-asm_64.S
> index 18d2f5199194..d089cccf4db7 100644
> --- a/arch/x86/crypto/sm4-aesni-avx-asm_64.S
> +++ b/arch/x86/crypto/sm4-aesni-avx-asm_64.S
> @@ -78,7 +78,7 @@
>   	vpxor tmp0, x, x;
>   
>   
> -.section	.rodata.cst164, "aM", @progbits, 164
> +.section	.rodata.cst164, "aM", @progbits
>   .align 16
>   
>   /*
> diff --git a/arch/x86/crypto/sm4-aesni-avx2-asm_64.S b/arch/x86/crypto/sm4-aesni-avx2-asm_64.S
> index d2ffd7f76ee2..a0f7541c2246 100644
> --- a/arch/x86/crypto/sm4-aesni-avx2-asm_64.S
> +++ b/arch/x86/crypto/sm4-aesni-avx2-asm_64.S
> @@ -93,7 +93,7 @@
>   	vpxor tmp0, x, x;
>   
>   
> -.section	.rodata.cst164, "aM", @progbits, 164
> +.section	.rodata.cst164, "aM", @progbits
>   .align 16
>   
>   /*
> 

Thanks for pointing it out, We have also reproduced this error. If the M 
flag is specified, the entry_size argument is required. We also need to 
consider the clang compiler. This requires a more thorough method to fix 
it. I will post another patch later.

Best regards,
Tianjia