Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5384687ybp; Tue, 8 Oct 2019 01:54:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqyULC+fLxkMomg1u1jRu6hC+KKmoGatr00IQvUAr0gUaxu6YyTqe24BWY/Y8D8HnLgUwT8f X-Received: by 2002:a50:8d5e:: with SMTP id t30mr33079877edt.112.1570524895009; Tue, 08 Oct 2019 01:54:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570524895; cv=none; d=google.com; s=arc-20160816; b=Kkse6qifbJVcv2bUvHdX5tpIDr7j+oxiF4tSEFBpPykIuqLWHgHn3LTmgNM3RWHoCO lzUVtPahjFLlKBoJ7c9m8Aim9W69qx3fafwRW5uhfsEArCZZw+vplJAaoxnDH8u7nEBl ZrvS4XAWHECnrKmJnHXur05O1pg+cnnjCjxc5XtZJFV6i3UbKFkIavS/DMoyasy4ZyPn PagFK6uUOWCLM6vffYDycB0r68YEB5wSswTKWgVSkijv5D4toqUW9ZJY2Qqsnr0IswYl HD9VEmJ7PI6x/SJ1SJPMwKsugn2JxHzjsxW/ndNB8K5fTCrshT8LEHhAfB3yxIzQcQmP P/rA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=7bodkUGtgIMVzWXPwrY2l2aRW9toyJFatwtqT6DaSTA=; b=qHZberXK3xRu0n/u3kYTWXN4JbyeHHilt/SNv0iX0yvG8TFGDxibi45gXI+Vy9dyfb HJNIB62rWgcqoKq/fclZGF6eqCgEq8zFChfgeK3HWIZR20xbMyCwyojtq+fXabe9xJSo lg7aqdglFYwqtBFIFdx/Bp3R/qaOyLAGCBTcTbbYsuTrhe5QB99G9yM8HS8yrf6P3g4a vTEFnGMpVdTAHDgLvkj0mWvWHvhTCJmbhvBOoxDYfcieqJjmxhTVMsuwvKbTTVZhPZST P76zrql3+mfwC2RYmnyM5FmmzUHxB0LqDmtn31jBemiBzAc453vPqHg7WDyo2jVPqFm7 8KXg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g18si9874640edq.209.2019.10.08.01.54.31; Tue, 08 Oct 2019 01:54:54 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730036AbfJHIyY (ORCPT + 99 others); Tue, 8 Oct 2019 04:54:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33196 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728866AbfJHIyY (ORCPT ); Tue, 8 Oct 2019 04:54:24 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 356D310CC1FD; Tue, 8 Oct 2019 08:54:24 +0000 (UTC) Received: from shalem.localdomain.com (ovpn-117-197.ams2.redhat.com [10.36.117.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9193619C68; Tue, 8 Oct 2019 08:54:22 +0000 (UTC) From: Hans de Goede To: Heiko Carstens , Vasily Gorbik , Christian Borntraeger Cc: Hans de Goede , Arvind Sankar , Nathan Chancellor , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC v2 0/1] s390/purgatory: Make sure we fail the build if purgatory has missing symbols Date: Tue, 8 Oct 2019 10:54:20 +0200 Message-Id: <20191008085421.11011-1-hdegoede@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.65]); Tue, 08 Oct 2019 08:54:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi s390 maintainers, Here is a second RFC version of my patch for $subject, mirroring the changes in v2 of the x86 patch. As last time this patch is completely UNTESTED. Changes in v2: - Using 2 if_changed lines under a single rule does not work, then 1 of the 2 will always execute each build. Instead add a new (unused) purgatory.chk intermediate which gets linked from purgatory.ro without -r to do the missing symbols check - This also fixes the check generating an a.out file (oops) Relevant part of the cover letter from v1: In 5.4-rc1 the 2 different sha256 implementations for the purgatory resp. for crypto/sha256_generic.c have been consolidated into 1 single shared implementation under lib/crypto/sha256.c . At least on x86 this was causing silent corruption of the purgatory due to a missing memzero_explicit symbol in the purgatory string.c/.o file. With the x86 equivalent of this patch applied a x86 build of 5.4-rc1 now correctly fails: CHK arch/x86/purgatory/purgatory.ro ld: arch/x86/purgatory/purgatory.ro: in function `sha256_transform': sha256.c:(.text+0x1c0c): undefined reference to `memzero_explicit' make[2]: *** [arch/x86/purgatory/Makefile:72: arch/x86/purgatory/kexec-purgatory.c] Error 1 make[1]: *** [scripts/Makefile.build:509: arch/x86/purgatory] Error 2 make: *** [Makefile:1650: arch/x86] Error 2 It would be great if the s390 maintainers can test this equivalent patch on s390. As for fixing the missing memzero_explicit symbol, we are currently discussing making memzero_explicit a static inline wrapper of memset in string.h, so that we do not need to implement it in multiple places. This discussion is Cc-ed to the generic linux-kernel@vger.kernel.org list, it is happening in the "[PATCH v2 5.4 regression fix] x86/boot: Provide memzero_explicit" thread. Regards, Hans