Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp161089ybe; Thu, 5 Sep 2019 19:37:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzjQed6UIk2bllaLSJuX7yM+/0Zo6H8xWIgV3mV98RTAXb2sbl+8VKqO3SSA5WJ3VFL1Jxl X-Received: by 2002:a17:90a:cb88:: with SMTP id a8mr7172099pju.111.1567737477812; Thu, 05 Sep 2019 19:37:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567737477; cv=none; d=google.com; s=arc-20160816; b=uLT4yG36vG7tv1B+UYgFD2OTrb/02UXtsioES9muSVxAzwsEJyIorNDyNdqUSWlebN TKNQlTLjTFgJrKBToi82gJ3C7t59Pli5tza3FgrAr8Wj9P4v8PCKLQ1xvXYZ5Po6734k FaFnxi43rGnDK7ThE62QmVBVOoiZj+UQsu1SewbVlM5sCUfJoVJpTp3Z5rSs8zQ2v4oD byrJdlVsGvhosmMZWHvc06Jt0/kLqhOPFn1SXqi0+Vw7Onnbm9tgmVRoOOTJliiMOukn x6Y/Fh2rtpGkH3TOurIFbT2vbnK6/k13DeqBw9UZdHMdagG3eJYcGDgTvLXroj78Hicn 0+dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=u0s/PLxFo+syH7M9Wh4VFiPBwZwXzQ4qynXsfqd0qpc=; b=d6q9uE87yxLFJlwau0v9hp4/GeCkRbMZ01bDIuslJuaAxtwwIAxpRh98s7zHj1UXje DQmZ2jCMhn1cySVmp+je/SSoJLTVBzvAJTWvxhplNSvk6QNolFch1o5HGbwOZSasQlXl 0d53b8jiCSqDTbcHILtb+WsrmHx7Z8VXeH52ZY18GSJph9NWDrHzGMYT57aSAEXD0HlR gCQTeQ8k6urrkhuvelLiEP72bKFmQ39gpUKvrAhRxoaDYuu1XqMQt2uUdJdaz7XDw/Mm qZPNupqDgTTriahl0lht0Igcbtbd6XN2wup0PciF0A3GoP5RP25UDRSqNBPMhBq/9cvw 5pdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vmxz18y5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g24si3357590pgh.416.2019.09.05.19.37.30; Thu, 05 Sep 2019 19:37:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=vmxz18y5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403867AbfIESUK (ORCPT + 99 others); Thu, 5 Sep 2019 14:20:10 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:42162 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389317AbfIESUK (ORCPT ); Thu, 5 Sep 2019 14:20:10 -0400 Received: by mail-pf1-f193.google.com with SMTP id w22so2281062pfi.9 for ; Thu, 05 Sep 2019 11:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u0s/PLxFo+syH7M9Wh4VFiPBwZwXzQ4qynXsfqd0qpc=; b=vmxz18y5j40Fyf1TwsRasL2dZnUKzA3rO7twC/uwCcyhfoYuY0LNznOubNlag7C+9q Lty9gPyH0n2Gctqtx/AOaqPJNMIuS4ySIRccpu//efecqEBBFhNixIAxRZiitPU4oeLw x24yZkCeDpV5AVxXhUrUjrOWlWFSut7LUSlfxIKcyp4GXYZ4VEbM4nT0lBnTpaCCf1tK JoYBYjY3IaUwpcBCYfrSZDkpsDFWLxq10f/Ybz/D2wStJ+xw91ApLosRC00cj4XN2gzk PTG76cOduLryMZfxigByHLYtXDB4d/bB/wdWlPHZwkXH7r8pRdaL+y7tvJvQSc3dfeHg soUA== 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; bh=u0s/PLxFo+syH7M9Wh4VFiPBwZwXzQ4qynXsfqd0qpc=; b=bCfoCW724GJ0T0eBFBWAKQ5YaBcpXyExueGFKAdGvzIiGejfKO/Q2BrqRXxZ/+PJ2v Ek1GdoOqhpisMyPpKu2nY9I2o6s7z+tuP31vLLZjFTkwqOX3Z50Axo0c/U4X1gG/6Tql z+srdiyCVEj++xXcaqWGTRyTM3gvV3Dj6WO5VVSeAO/GxQCkIYmKSFmCwubp3lPi9f5C t6TPRqp7dSsjBYBg9VmFDIDVM7PLvQVKi2WzTjnp9kuBboZPRbaHlEWfzcDGl3P1ooRI KOdT0iwTKP/MbuBzwj4AxkDI5oaNWbptuf+aBaKdnc+AFgQl5JV4X9PPGZcNVW3ojxyW ve7A== X-Gm-Message-State: APjAAAXxw48Qb92yIp+RU2BoLQ9WuZsaGUCGmS47qnxUrbRmmaURT7Ad 4ikAqybMdONSg7EzS+hPv2m8vxLxaPd+j18bikC54w== X-Received: by 2002:a63:6193:: with SMTP id v141mr4496292pgb.263.1567707608710; Thu, 05 Sep 2019 11:20:08 -0700 (PDT) MIME-Version: 1.0 References: <20190904214505.GA15093@swahl-linux> In-Reply-To: From: Nick Desaulniers Date: Thu, 5 Sep 2019 11:19:57 -0700 Message-ID: Subject: Re: [PATCH 1/1] x86/purgatory: Change compiler flags to avoid relocation errors. To: Andreas Smas Cc: Steve Wahl , Thomas Gleixner , LKML , clang-built-linux , Vaibhav Rustagi , russ.anderson@hpe.com, dimitri.sivanich@hpe.com, mike.travis@hpe.com, Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 4, 2019 at 10:34 PM Andreas Smas wrote: > > On Wed, Sep 4, 2019 at 3:19 PM Nick Desaulniers wrote: > > Thanks for confirming the fix. While it sounds like -mcmodel=large is > > the only necessary change, I don't object to -ffreestanding of > > -fno-zero-initialized-in-bss being readded, especially since I think > > what you've done with PURGATORY_CFLAGS_REMOVE is more concise. > > Without -ffreestanding this results in undefined symbols (as before this patch) Thanks for the report and sorry for the breakage. Can you test Steve's patch and send your tested by tag? Steve will likely respin the final patch today with Boris' feedback, so now is the time to get on the train. > > $ readelf -a arch/x86/purgatory/purgatory.ro|grep UND > 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND ^ what's that? A horse symbol with no name? > 51: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_fail ^ so I would have expected the stackprotector changes in my and Steve commits to prevent compiler emission of that runtime-implemented symbol. ie. that `-ffreestanding` affects that and not removing the stackprotector flags begs another question. Without `-ffreestanding` and `-fstack-protector` (or `-fstack-protector-strong`), why would the compiler emit references to __stack_chk_fail? Which .o file that composes the .ro file did we fail to remove the `-fstack-protector*` flag from? `-ffreestanding` seems to be covering that up. > > I just bumped into this issue as I discovered that kexec() no longer works after > the x86/purgatory: Use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS -commit > was merged. -- Thanks, ~Nick Desaulniers