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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 41144C352BE for ; Tue, 14 Apr 2020 20:53:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 162672064A for ; Tue, 14 Apr 2020 20:53:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Cfvq1I7W"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="CSqlXQVE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 162672064A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=slvFkGkutW8z9rNYTT5/PiRCRMmrYWlcxnl3E20IiuA=; b=Cfvq1I7W8bNLuW TOgFX/fJjdGqty01asQXpvqZJdVK8jO1fMCDxAdYTj71+ws/LIdGCYIabZwSso/6sOb3effcBpJ18 nfppRGPUF3C+CtNXPBZcwMU6baFVlVXC0jaRx5HZqwJxEnMg3c//GwMys7UePdflo+Jcz0w6VKTFt ghEzsOPPd73otC4PK5uY8gSTApiCh9uMSnjiFNyQ5KqTZL49JnGrQeb3+xkCxlb7Ks+OieBZhjuBO Ss+2+cpFMzD1AqTTihcXc+cvzzhuJNzNpmFDimP/dtIGMY+UzaCV7pVF6cHeHIo7BsOGVyxeuWBrN aDlawM9P6dcAfy1nYzVw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOSZ2-0008Tp-HP; Tue, 14 Apr 2020 20:53:48 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOSYz-0008TU-SW for linux-arm-kernel@lists.infradead.org; Tue, 14 Apr 2020 20:53:47 +0000 Received: by mail-pl1-x644.google.com with SMTP id k18so399436pll.6 for ; Tue, 14 Apr 2020 13:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=K0jdNDYsyVBKVJ8vrSclC2i6UhecRADdZccibZZW3Fk=; b=CSqlXQVETewXhgi7NEbLvyqtymrdv4KHSnaV7YJrij7Z94Wt9M/LRF+hI64VHazJtJ 1OEaNJd60jfAh5LIyE1CGhu25SP010BksVkq1wrNNHfLFFEZ61/P7rUnVcuhRDEqhcNY df4JRfjYorbuTTNhpo8Q3kiPlE4PL/0KJw86w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=K0jdNDYsyVBKVJ8vrSclC2i6UhecRADdZccibZZW3Fk=; b=UTAM2H37I/rqQfYl4UPa0mhvdPw01imGbf59IQm+WdEtVwFln6SLSh/2pWBG4kYyrX XrA4JM/vzMgFwoHvzQJtZAbmTn5CCUBb6SpFdvSCQZWgS1LzQUlpquvmuQ0rhwIAVldf mzZyBSicSSUrzzj8s8kphb+ttQ/onW0YOeoEvd7lFxcRpb1vL41ubYPG1W46LlEGaYz6 A6cW95/aTKAngNQ0kXsp4Ne7GNHMJMjK8lB9vDNNmXphKHb8r+KtCqv5nydZ6Kn7Ul2o tf1xn/CHDHH77qJyMu/0D0dEojb1D+7FuU3qLaimBPZEmjGXSy0WMt70yxpOxq4EdKJ5 RGgw== X-Gm-Message-State: AGi0PubqDccZGOiXzT+fPAgO9dehXt/UB3MJBP+GALwTzYatJ0h/telS YWhoAd7vg6pyuG086ZVdmXpbNw== X-Google-Smtp-Source: APiQypLdGMmw7NvSuzoHy8mBNVlipdBTPHcElNsahD9loveLyoxd/GXH2+3BqDp98wZz9NH2Z0oODA== X-Received: by 2002:a17:90a:e2c1:: with SMTP id fr1mr2244175pjb.124.1586897623282; Tue, 14 Apr 2020 13:53:43 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id a1sm11810795pfl.188.2020.04.14.13.53.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2020 13:53:42 -0700 (PDT) Date: Tue, 14 Apr 2020 13:53:41 -0700 From: Kees Cook To: Nick Desaulniers , Ard Biesheuvel Subject: Re: [PATCH] ARM: do not assemble iwmmxt.S with LLVM toolchain Message-ID: <202004141258.6D9CB92507@keescook> References: <20200409232728.231527-1-caij2003@gmail.com> <20200410123301.GX25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200414_135345_947101_686A60E1 X-CRM114-Status: GOOD ( 22.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linus Walleij , Peter Smith , Stefan Agner , David Howells , Mauro Carvalho Chehab , Manoj Gupta , Benjamin Gaignard , "Joel Fernandes \(Google\)" , Kristof Beyls , Jian Cai , Bartosz Golaszewski , Ilie Halip , Masahiro Yamada , Russell King - ARM Linux admin , Krzysztof Kozlowski , clang-built-linux , Sami Tolvanen , Luis Lozano , Masami Hiramatsu , Arnd Bergmann , "Steven Rostedt \(VMware\)" , Jian Cai , Stephen Hines , Doug Anderson , Dan Williams , Linux ARM , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Patrick Bellasi , "Eric W. Biederman" , Tejun Heo , Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org I don't know if this will help, but I feel like folks might be talking past each other a little here. I see two primary issues that are colliding, and I just want to call them out specifically... On Tue, Apr 14, 2020 at 1:59 AM Ard Biesheuvel wrote: > On Mon, 13 Apr 2020 at 22:45, Nick Desaulniers wrote: > > 1. continuous integration and randconfigs. We need CI to help us spot > > where things are still broken, and help us from regressing the ground > > we've fought for. We can't expect kernel developers to test with > > LLVM. Currently, we have LLVM builds in numerous kernel continuous First, is this one. To paraphrase, "we don't want to lose hard-won ground." > To be honest with you, I don't actually think iwmmxt is that > important. But I have already demonstrated how we can use a couple of > macros to emit the same instructions without resorting to bare > opcodes, so there is really no need to disable pieces left and right > because the Clang assembler does not support them outright - it just > needs someone to care enough about this, rather than rush through the > list with a tick the box attitude, and rip out the pieces that look a > bit too complicated. The second is this one. To paraphrase, "we can just fix things instead of disabling them." This feels a lot to me like the pain I (and plenty of others) have felt when doing treewide changes (adding full compiler support is kind of a treewide change). The above two points were really strongly felt when we were trying to remove VLAs. In our case, we didn't even have the option to disable stuff, so the pain was even worse: VLAs were being added to the kernel faster than we could remove them. What's a good middle ground here? For VLAs, I ended up getting akpm's help by having him add -Wvla to his local builds and send nag emails to people when they added VLAs. That's not really a thing here, but it seems like there should be a way to avoid losing ground (in this case, it's the erosion of attention: repeated known-issue warnings means the CI gets ignored for the warnings on newly added issues). It does seem to me like adding the negative depends is a reasonable first step: it marks what hard things need fixing later without losing coverage for things that can be more easily fixed now with available resources. For the specific iwmmxt.S case, perhaps the solution is the suggested changes? I imagine it should be possible to do a binary diff to see zero changes before/after. For others, is a negative depends acceptable? Given how responsive Nick, Nathan, and others are, I don't think there is any real risk of a "slippery slope" of things just getting swept under the rug forever. Everyone here wants to see the kernel be awesome. :) -Kees -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel