From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0E63C433E0 for ; Fri, 31 Jul 2020 06:49:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 864DD20838 for ; Fri, 31 Jul 2020 06:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596178169; bh=xPd3z35wKS3rDjjx7Vmt9THjpc672VJ9ztW3nUpT64Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=JwuoGRmfmjXWQ6/UsHCEboMhldZUv8PZ6LPEMXOcqBYpDggXWV8tcSjf4hTzqvqu1 RSRvYtiVttxTxb/9rUcHsN4G9pbIKyvAiBYdTlQUzDL6mnyyC4QE8n8Vv4NTpaWE07 r/BXCZpS5C7FHc33O+dqph5LT/3ttNtla9xY4jNQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731462AbgGaGt2 (ORCPT ); Fri, 31 Jul 2020 02:49:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:58140 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731365AbgGaGt2 (ORCPT ); Fri, 31 Jul 2020 02:49:28 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1AAE620829; Fri, 31 Jul 2020 06:49:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596178167; bh=xPd3z35wKS3rDjjx7Vmt9THjpc672VJ9ztW3nUpT64Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0Q3ICI1V39uoTR2bahOLTiWRuZyStsuQCSxAxlu3tuLNDDdxXkZye4aTApfmI09oP mHeFkactbMxsGxOovfmNKBOEAIKsfLtXqMC8MYm5S6d+4VpFoyQ4kKVEHJXVQtgTz7 tfmLFxdi77Lk/PFCuX5bsTfFP/eQ6cIbQf7fE7HU= Date: Fri, 31 Jul 2020 08:49:15 +0200 From: Greg KH To: Catalin Marinas Cc: Sami Tolvanen , Will Deacon , Ard Biesheuvel , Nick Desaulniers , Kees Cook , linux-arm-kernel , LKML , clang-built-linux , stable@vger.kernel.org Subject: Re: [PATCH] arm64/alternatives: move length validation inside the subsection Message-ID: <20200731064915.GI1508201@kroah.com> References: <20200729215152.662225-1-samitolvanen@google.com> <20200730122201.GM25149@gaia> <20200730152330.GA3128@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200730152330.GA3128@gaia> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 04:23:31PM +0100, Catalin Marinas wrote: > On Thu, Jul 30, 2020 at 08:13:05AM -0700, Sami Tolvanen wrote: > > On Thu, Jul 30, 2020 at 5:22 AM Catalin Marinas wrote: > > > > > > On Wed, Jul 29, 2020 at 02:51:52PM -0700, Sami Tolvanen wrote: > > > > Commit f7b93d42945c ("arm64/alternatives: use subsections for replacement > > > > sequences") breaks LLVM's integrated assembler, because due to its > > > > one-pass design, it cannot compute instruction sequence lengths before the > > > > layout for the subsection has been finalized. This change fixes the build > > > > by moving the .org directives inside the subsection, so they are processed > > > > after the subsection layout is known. > > > > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1078 > > > > Cc: # 4.14+ > > > > > > Commit f7b93d42945c went in 5.8-rc4. Why is this cc stable from 4.14? If > > > Will picks it up for 5.8, it doesn't even need a cc stable. > > > > Greg or Sasha can probably answer why, but this patch is in 4.14.189, > > 4.19.134, 5.4.53, and 5.7.10, which ended up breaking some downstream > > Android kernel builds. > > I see but I don't think we need the explicit cc stable for 4.14. That's > why the Fixes tag is important. If a patch was back-ported, the > subsequent fixes should be picked by the stable maintainers as well. If you know it ahead of time, the explict "# kernel.version" hint is always nice to have as it ensures I will try to backport it that far, and if I have problems, I will ask for help. thanks, greg k-h