Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5002380imu; Tue, 15 Jan 2019 09:27:19 -0800 (PST) X-Google-Smtp-Source: ALg8bN7eOOhgR8uPNnlgujegc81mCXQnXAN5U4f1HQvM6m13kdMx/+vEADh5Ypo6ABhowdr7fExn X-Received: by 2002:a63:fe48:: with SMTP id x8mr4796143pgj.261.1547573239631; Tue, 15 Jan 2019 09:27:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547573239; cv=none; d=google.com; s=arc-20160816; b=kkCCL6pfEJ3LZ8JlCCZm4kaXuBqqC6A7Z/D5eoyaeFFQzDXMFOF4In5utLx5Oq7RGb fyNqDWn90jTkAXDbMt8fy2v+SuVdq5rpuU54OGQYK/SRMM8wVB/LvaO37tzi2yDPZoev KKDBEJuqxPOhXIgnzpW7Ta/EASRZQ0mKkfsU23LnTCaPGpvFLBQ09Ipe3wpMQE/UhQFb DTNsw9rpKpsHdlQc992RfSDsQDm2SJNlWqm4Ohj5Rl9MHIlehk/hT0RoHOhlH30qPpb/ a9Ri5CqeFZfYTWxQzF/g6ZYeo91xYZWs3+MxpE9YDYFeOat0g1tFDjHV0HmenkhOA/+x xHBw== 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:dkim-filter; bh=ORvUJeYfdFDrcDEJahOg9VUCtLZ2xiu2Oy8mXwaaIds=; b=YtN5i+IVbS7HJEISOUSaFJFloQ7f9GvIrdGPSKgC3zdzqDW2so0qJ9mL8qlG6p+cXF S8RkMDI0EM3bP5aHArrC9mGhh5rYtc74RpjKmCzxPtlasbPxVb2ehdaB10HKaXDIYICj vYXXE4Ns9sCLFIw5LAvws2wKnKRrP+OAoXzF08p6BRV49u0JKLUzoAhcYQjDAvhBQbd0 o4BqlCIJxIyr3kQwn07Ji/e7p7k9vLjtmLkWDZ6pm0ZR+Grb7ph/Bp5eMNuXlmw598jB Jydi4HzCZqfxI6qVJ4zlNt9IpRIRLqPlirr/Ool8KZOS/I1ehH/Nsr5im1YG3X3fpNQX 5fjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=CkoXq0Al; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o28si3816446pgm.238.2019.01.15.09.27.00; Tue, 15 Jan 2019 09:27:19 -0800 (PST) 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=@nifty.com header.s=dec2015msa header.b=CkoXq0Al; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730589AbfAOPBx (ORCPT + 99 others); Tue, 15 Jan 2019 10:01:53 -0500 Received: from conssluserg-03.nifty.com ([210.131.2.82]:23066 "EHLO conssluserg-03.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729474AbfAOPBw (ORCPT ); Tue, 15 Jan 2019 10:01:52 -0500 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (authenticated) by conssluserg-03.nifty.com with ESMTP id x0FF1iT9020398; Wed, 16 Jan 2019 00:01:45 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com x0FF1iT9020398 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1547564505; bh=ORvUJeYfdFDrcDEJahOg9VUCtLZ2xiu2Oy8mXwaaIds=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CkoXq0AlQFcK1L0PN0tH0nyfP75iEVVxlzJvrfq2DzwFQd+amiOZ5uoqkKsYVubRq T0D9c66F6WzDaymeq7pRw64GMJY0GiU0nmPBsZgB1w3av8FeihesqQ0LIBfyrLOWKb 0eq8z90Nud32hBdZuxEN9LrPyptjh0o1d10XE8LJ0mCXOM+ywzAB21xw1UcbzZcJLe hdQciUUPrmAScpxNrBSZxk/cEtZ9NPbpWQpFr3KJlyKlERzZkxKpcW6O2Q7YoQSVKN Dkt8sciIQ+8iCYqOEmUc+GkKGubIQsSpCzumPuAGYdCFgHKlXr7oII91VELxEjp+St 9ZkaimboShrVA== X-Nifty-SrcIP: [209.85.221.176] Received: by mail-vk1-f176.google.com with SMTP id d201so669939vka.0; Tue, 15 Jan 2019 07:01:45 -0800 (PST) X-Gm-Message-State: AJcUukdogegZU6Sh5p3V6TqA6p/V1vyNTouyCT20RMTZKTb1pkIe1jvd qyoj2eZMmlU/RV92MYBCxHPde1sWphXk4rIEdeU= X-Received: by 2002:a1f:91cb:: with SMTP id t194mr1614598vkd.74.1547564504148; Tue, 15 Jan 2019 07:01:44 -0800 (PST) MIME-Version: 1.0 References: <1547536740-1572-1-git-send-email-yamada.masahiro@socionext.com> <54f84ad6-279f-aa64-8c2c-59becd64a6ad@ozlabs.ru> In-Reply-To: <54f84ad6-279f-aa64-8c2c-59becd64a6ad@ozlabs.ru> From: Masahiro Yamada Date: Wed, 16 Jan 2019 00:01:08 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: mark prepare0 as PHONY to fix external module build To: Alexey Kardashevskiy Cc: Linux Kbuild mailing list , Ard Biesheuvel , Samuel Holland , linuxppc-dev , Michael Ellerman , "linux-stable # v4 . 20" , Michal Marek , Linux Kernel Mailing List 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 Tue, Jan 15, 2019 at 7:45 PM Alexey Kardashevskiy wrote: > > > > On 15/01/2019 18:19, Masahiro Yamada wrote: > > Commit c3ff2a5193fa ("powerpc/32: add stack protector support") > > caused kernel panic on PowerPC if an external module is used with > > CONFIG_STACKPROTECTOR because the 'prepare' target was not executed > > for the external module build. > > > > Commit e07db28eea38 ("kbuild: fix single target build for external > > module") turned it into a build error because the 'prepare' target is > > now executed but the 'prepare0' target is missing for the external > > module build. > > > > External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is > > also broken in the same way. > > > > Move 'PHONY += prepare0' to the common place. Make is fine with missing > > rule for phony targets. > > > > I minimize the change so it can be easily backported to 4.20.x > > > > To fix v4.20 for external modules of PowerPC, please backport > > e07db28eea38 ("kbuild: fix single target build for external module"), > > and then this commit. > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891 > > Fixes: e07db28eea38 ("kbuild: fix single target build for external module") > > Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support") > > Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") > > Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries") > > Cc: linux-stable # v4.20 > > Reported-by: Samuel Holland > > Reported-by: Alexey Kardashevskiy > > Signed-off-by: Masahiro Yamada > > > Tested-by: Alexey Kardashevskiy > > Thanks for fixing this! Out of curiosity - how does this work? > arch/powerpc/Makefile's stack_protector_prepare still depends on > prepare0 which is still defined only if KBUILD_EXTMOD=="" but somehow it > does not bother ./Makefile? Thanks, Missing phony targets are ignored. I do not know if it is officially documented, but GNU Make works like that. Is the following test code helpful? [Test Makefile] prepare: prepare0 @echo hello world .PHONY: prepare prepare0 [Result] $ make hello world -- Best Regards Masahiro Yamada