linux-kernel - Re: linux-next: manual merge of the tip tree with the crypto tree

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] [day] [month] [year] [list]
Message-ID: <20200804081402.70e81d3b@canb.auug.org.au>
Date:   Tue, 4 Aug 2020 08:14:02 +1000
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Linux Crypto List <linux-crypto@...r.kernel.org>
Cc:     Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Sasha Levin <sashal@...nel.org>,
        Uros Bizjak <ubizjak@...il.com>
Subject: Re: linux-next: manual merge of the tip tree with the crypto tree

Hi all,

On Tue, 21 Jul 2020 14:28:45 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/x86/include/asm/inst.h
> 
> between commit:
> 
>   d7866e503bdc ("crypto: x86 - Remove include/asm/inst.h")
> (also "crypto: x86 - Put back integer parts of include/asm/inst.h"
> which I have added to the crypto tree merge today)
> 
> from the crypto tree and commit:
> 
>   eaad981291ee ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")
> 
> from the tip tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/x86/include/asm/inst.h
> index 438ccd4f3cc4,d063841a17e3..000000000000
> --- a/arch/x86/include/asm/inst.h
> +++ b/arch/x86/include/asm/inst.h
> @@@ -143,6 -203,124 +143,21 @@@
>   	.macro MODRM mod opd1 opd2
>   	.byte \mod | (\opd1 & 7) | ((\opd2 & 7) << 3)
>   	.endm
> + 
>  -	.macro PSHUFB_XMM xmm1 xmm2
>  -	XMM_NUM pshufb_opd1 \xmm1
>  -	XMM_NUM pshufb_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX pshufb_opd1 pshufb_opd2
>  -	.byte 0x0f, 0x38, 0x00
>  -	MODRM 0xc0 pshufb_opd1 pshufb_opd2
>  -	.endm
>  -
>  -	.macro PCLMULQDQ imm8 xmm1 xmm2
>  -	XMM_NUM clmul_opd1 \xmm1
>  -	XMM_NUM clmul_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX clmul_opd1 clmul_opd2
>  -	.byte 0x0f, 0x3a, 0x44
>  -	MODRM 0xc0 clmul_opd1 clmul_opd2
>  -	.byte \imm8
>  -	.endm
>  -
>  -	.macro PEXTRD imm8 xmm gpr
>  -	R32_NUM extrd_opd1 \gpr
>  -	XMM_NUM extrd_opd2 \xmm
>  -	PFX_OPD_SIZE
>  -	PFX_REX extrd_opd1 extrd_opd2
>  -	.byte 0x0f, 0x3a, 0x16
>  -	MODRM 0xc0 extrd_opd1 extrd_opd2
>  -	.byte \imm8
>  -	.endm
>  -
>  -	.macro AESKEYGENASSIST rcon xmm1 xmm2
>  -	XMM_NUM aeskeygen_opd1 \xmm1
>  -	XMM_NUM aeskeygen_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX aeskeygen_opd1 aeskeygen_opd2
>  -	.byte 0x0f, 0x3a, 0xdf
>  -	MODRM 0xc0 aeskeygen_opd1 aeskeygen_opd2
>  -	.byte \rcon
>  -	.endm
>  -
>  -	.macro AESIMC xmm1 xmm2
>  -	XMM_NUM aesimc_opd1 \xmm1
>  -	XMM_NUM aesimc_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX aesimc_opd1 aesimc_opd2
>  -	.byte 0x0f, 0x38, 0xdb
>  -	MODRM 0xc0 aesimc_opd1 aesimc_opd2
>  -	.endm
>  -
>  -	.macro AESENC xmm1 xmm2
>  -	XMM_NUM aesenc_opd1 \xmm1
>  -	XMM_NUM aesenc_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX aesenc_opd1 aesenc_opd2
>  -	.byte 0x0f, 0x38, 0xdc
>  -	MODRM 0xc0 aesenc_opd1 aesenc_opd2
>  -	.endm
>  -
>  -	.macro AESENCLAST xmm1 xmm2
>  -	XMM_NUM aesenclast_opd1 \xmm1
>  -	XMM_NUM aesenclast_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX aesenclast_opd1 aesenclast_opd2
>  -	.byte 0x0f, 0x38, 0xdd
>  -	MODRM 0xc0 aesenclast_opd1 aesenclast_opd2
>  -	.endm
>  -
>  -	.macro AESDEC xmm1 xmm2
>  -	XMM_NUM aesdec_opd1 \xmm1
>  -	XMM_NUM aesdec_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX aesdec_opd1 aesdec_opd2
>  -	.byte 0x0f, 0x38, 0xde
>  -	MODRM 0xc0 aesdec_opd1 aesdec_opd2
>  -	.endm
>  -
>  -	.macro AESDECLAST xmm1 xmm2
>  -	XMM_NUM aesdeclast_opd1 \xmm1
>  -	XMM_NUM aesdeclast_opd2 \xmm2
>  -	PFX_OPD_SIZE
>  -	PFX_REX aesdeclast_opd1 aesdeclast_opd2
>  -	.byte 0x0f, 0x38, 0xdf
>  -	MODRM 0xc0 aesdeclast_opd1 aesdeclast_opd2
>  -	.endm
>  -
>  -	.macro MOVQ_R64_XMM opd1 opd2
>  -	REG_TYPE movq_r64_xmm_opd1_type \opd1
>  -	.if movq_r64_xmm_opd1_type == REG_TYPE_XMM
>  -	XMM_NUM movq_r64_xmm_opd1 \opd1
>  -	R64_NUM movq_r64_xmm_opd2 \opd2
>  -	.else
>  -	R64_NUM movq_r64_xmm_opd1 \opd1
>  -	XMM_NUM movq_r64_xmm_opd2 \opd2
>  -	.endif
>  -	PFX_OPD_SIZE
>  -	PFX_REX movq_r64_xmm_opd1 movq_r64_xmm_opd2 1
>  -	.if movq_r64_xmm_opd1_type == REG_TYPE_XMM
>  -	.byte 0x0f, 0x7e
>  -	.else
>  -	.byte 0x0f, 0x6e
>  -	.endif
>  -	MODRM 0xc0 movq_r64_xmm_opd1 movq_r64_xmm_opd2
>  -	.endm
>  -
> + .macro RDPID opd
> + 	REG_TYPE rdpid_opd_type \opd
> + 	.if rdpid_opd_type == REG_TYPE_R64
> + 	R64_NUM rdpid_opd \opd
> + 	.else
> + 	R32_NUM rdpid_opd \opd
> + 	.endif
> + 	.byte 0xf3
> + 	.if rdpid_opd > 7
> + 	PFX_REX rdpid_opd 0
> + 	.endif
> + 	.byte 0x0f, 0xc7
> + 	MODRM 0xc0 rdpid_opd 0x7
> + .endm
>   #endif
>   
>   #endif

This is now a conflict between the tip tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

Content of type "application/pgp-signature" skipped