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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 3D641CA9EAF for ; Sun, 27 Oct 2019 17:40:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0EA4721850 for ; Sun, 27 Oct 2019 17:40:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="oLXoo3oi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727579AbfJ0RkA (ORCPT ); Sun, 27 Oct 2019 13:40:00 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:46285 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726930AbfJ0RkA (ORCPT ); Sun, 27 Oct 2019 13:40:00 -0400 Received: by mail-wr1-f68.google.com with SMTP id n15so7465133wrw.13 for ; Sun, 27 Oct 2019 10:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FkHYFiDsqcrhh/x1p2m9DSaSG+KUAmaOqRNCjiDWvoQ=; b=oLXoo3oi2skejIH/dt1cK91nZ5IqjDglwEaOkev5Inlb2GkvtJXPaLQSIqZEzp56Mc 9hU/WR0a0ElL+ElqXZsbP5J1UTncwnHFtw37q7v1L19NYotEtRgiVRcpwDZ3Oc1uCmx6 xs0QHTj8bmN9Y42sliiCwlOPyOqdXgQcuWSmm/x8T90dJW8oO5YKpGspVyv6SNcUuHNl scpCW/EINUOlVC0N4EMRzP8Elgfq1ldc4pRpgqKcXHY6xQSbSfJmB1M2A1YyIMBoDJ+K TDtIY2cS6eZfnydzfOW7Wy22PbakAGZJgF1B1dQN5z2LYusj7QGT2PIv6OHF1TSVU9Ix jpuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FkHYFiDsqcrhh/x1p2m9DSaSG+KUAmaOqRNCjiDWvoQ=; b=C+AfpOFKXbhsn62pJl/nWiHaaljDAOk0p32hUw4p/ISegIxpAdqsMQutJpwKoKmGoU 6NkQEbcFAmkaEwleZuPOBko+Z1F9qXQDTKB4WljnQ+SeSej8XJBniePMc988nN2KIURx JpZq4ckvAtT3ZJXy1EQnIVoWfnicjr2COjkv50/lbb6W6m+YLRQthfcGXU+HWTvPVXNC kLxJ0rmAazg0ayRnuCLFWToQY+2lUaMEB90QrLFklfZcnjdnOf/n0pnP6RtDGVqs9mRC 2w/1foG1UDGFC5NwN1R3Zkt+F+rGxYx42JFBThra8m40NhaFCOkmCHNobA4zvHF0UTan 3lPQ== X-Gm-Message-State: APjAAAVGKFFmffVtAknwyqxUZllRxcliyKxTymUojDRQFkfSUnFV6Pax H4EhpYpnuZ7J1encvb1gwwscjmNCZUDT4n1fBTqDzg== X-Google-Smtp-Source: APXvYqzofjHJy+wG6fao9JMFBVbG6KV82wZ2RG51e0Gx9IEDcoAiIRH1iM8w1GHXtlTrVKD2K5RdMjOiI7qNniKZH7o= X-Received: by 2002:adf:f685:: with SMTP id v5mr12387947wrp.246.1572197997372; Sun, 27 Oct 2019 10:39:57 -0700 (PDT) MIME-Version: 1.0 References: <20191024124833.4158-1-ard.biesheuvel@linaro.org> <20191024124833.4158-43-ard.biesheuvel@linaro.org> <20191025152534.GF31224@sasha-vm> <20191026080121.GB554748@kroah.com> <20191026154020.GK31224@sasha-vm> <20191027133936.GA2195060@kroah.com> In-Reply-To: <20191027133936.GA2195060@kroah.com> From: Ard Biesheuvel Date: Sun, 27 Oct 2019 18:39:55 +0100 Message-ID: Subject: Re: [PATCH for-stable-4.14 42/48] arm64: Always enable spectre-v2 vulnerability detection To: Greg KH Cc: Sasha Levin , Alexandru Elisei , stable , Will Deacon , Catalin Marinas , Marc Zyngier , Mark Rutland , Suzuki K Poulose , Jeremy Linton , Andre Przywara , Stefan Wahren , Will Deacon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Sun, 27 Oct 2019 at 14:39, Greg KH wrote: > > On Sat, Oct 26, 2019 at 05:46:03PM +0200, Ard Biesheuvel wrote: > > On Sat, 26 Oct 2019 at 17:40, Sasha Levin wrote: > > > > > > On Sat, Oct 26, 2019 at 10:01:21AM +0200, Greg KH wrote: > > > >On Fri, Oct 25, 2019 at 05:39:44PM +0200, Ard Biesheuvel wrote: > > > >> On Fri, 25 Oct 2019 at 17:28, Ard Biesheuvel wrote: > > > >> > > > > >> > On Fri, 25 Oct 2019 at 17:25, Sasha Levin wr= ote: > > > >> > > > > > >> > > On Thu, Oct 24, 2019 at 04:37:12PM +0200, Ard Biesheuvel wrote= : > > > >> > > >On Thu, 24 Oct 2019 at 16:34, Alexandru Elisei wrote: ... > > > >> > > >> > > > >> > > >> This breaks when building, because __hardenbp_enab is decla= red in the next patch: > > > >> > > >> > > > >> > > >> $ make -j32 defconfig && make -j32 > > > >> > > >> > > > >> > > >> [..] > > > >> > > >> arch/arm64/kernel/cpu_errata.c: In function =E2=80=98check_= branch_predictor=E2=80=99: > > > >> > > >> arch/arm64/kernel/cpu_errata.c:492:3: error: =E2=80=98__har= denbp_enab=E2=80=99 undeclared (first > > > >> > > >> use in this function) > > > >> > > >> __hardenbp_enab =3D false; > > > >> > > >> ^~~~~~~~~~~~~~~ > > > >> > > >> arch/arm64/kernel/cpu_errata.c:492:3: note: each undeclared= identifier is reported > > > >> > > >> only once for each function it appears in > > > >> > > >> make[1]: *** [scripts/Makefile.build:326: arch/arm64/kernel= /cpu_errata.o] Error 1 > > > >> > > >> make[1]: *** Waiting for unfinished jobs.... > > > >> > > >> > > > >> > > > > > > >> > > >Indeed, but as discussed, this matches the state of both main= line and > > > >> > > >v4.19, which carry these patches in the same [wrong] order as= well. > > > >> > > > > > > >> > > >Greg should confirm, but as I understand it, it is preferred = to be > > > >> > > >bug-compatible with mainline rather than fixing problems when= spotting > > > >> > > >them while doing the backport. > > > >> > > > > > >> > > Is it just patch ordering? If so I'd rather fix it, there's no= reason to > > > >> > > carry this issue into the stable trees. > > > >> > > > > > >> > > We reserve "bug compatibility" for functional issues that are = not yet > > > >> > > fixed upstream, it doesn't seem to be the case here. > > > >> > > > > > >> > > > > >> > The patches don't apply cleanly in the opposite order. > > > >> > > > >> What we could do is squash the two patches together. That way, we > > > >> avoid the breakage without having to modify the patches in order t= o be > > > >> able to apply them. > > > > > > > >No, don't do that. Just take all of the needed commits. > > > > > > Right, just make the patches apply in reverse, this shouldn't be more > > > than moving some code from the 2nd patch back to the 1st one, right? > > > > > > We usually don't do this in stable backports, but there are three goo= d > > > reasons to do it here: > > > > > > 1. It'll be nice to maintain bisectability. > > > 2. The end result should be exactly the same, so there's no room for > > > error here. > > > 3. It's a backport for an older kernel to begin with, so there are > > > changes from upstream already. > > > > > > > I really don't see the point of doing this for v4.14 while v4.19 and > > mainline have the two patches in the opposite order. > > > > Would you like me to resend the entire 48 piece series for this? > > No need, I've queued the whole thing up now, thanks. > Thanks Greg