linux-kernel - Re: linux-next: manual merge of the arm64 tree with Linus' 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]

Date:   Wed, 9 Mar 2022 12:20:20 +0000
From:   Will Deacon <will@...nel.org>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        James Morse <james.morse@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Vladimir Murzin <vladimir.murzin@....com>
Subject: Re: linux-next: manual merge of the arm64 tree with Linus' tree

On Wed, Mar 09, 2022 at 09:42:35AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the arm64 tree got a conflict in:
> 
>   arch/arm64/kernel/cpufeature.c
> 
> between commit:
> 
>   228a26b91228 ("arm64: Use the clearbhb instruction in mitigations")
> 
> from Linus' tree and commit:
> 
>   def8c222f054 ("arm64: Add support of PAuth QARMA3 architected algorithm")
> 
> from the arm64 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/arm64/kernel/cpufeature.c
> index d33687673f6b,32aa0eb3ed68..000000000000
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@@ -231,7 -226,10 +231,11 @@@ static const struct arm64_ftr_bits ftr_
>   };
>   
>   static const struct arm64_ftr_bits ftr_id_aa64isar2[] = {
>  +	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64ISAR2_CLEARBHB_SHIFT, 4, 0),
> + 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> + 		       FTR_STRICT, FTR_EXACT, ID_AA64ISAR2_APA3_SHIFT, 4, 0),
> + 	ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
> + 		       FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_GPA3_SHIFT, 4, 0),
>   	ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64ISAR2_RPRES_SHIFT, 4, 0),
>   	ARM64_FTR_END,
>   };

This (and https://lore.kernel.org/r/20220309093832.01585172@canb.auug.org.au)
are due to the surprise spectre mitigations which landed yesterday. Now
that's all public, I'll merge those changes into our for-next/core branch
and these conflicts should all disappear.

Thanks,

Will