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=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 704A5C43331 for ; Thu, 2 Apr 2020 11:30:43 +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 40D6020787 for ; Thu, 2 Apr 2020 11:30:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="q0SJ3WgP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40D6020787 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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=6Xwog9GQlMsLC+RQ9I4QDjpJ3vylF/7FGmoyMjI+3Hw=; b=q0SJ3WgPR824jo axnBdxhviWA+HDBMehNJIbPQfaRsHbGOc8939sjDeyGzVPtB/z4H6IWVzyXRSz36DsyRzsWEUkI4o +1sd9sSPK59nUauOZDmwDMAPlqDt4MpWxA8Ca0+y7h8HvS/YY8ArwAtMbCtA9aDtVgwHPCMsiLLaA PfizQ6MU9fIiQfEgiYgoMX6wSetrgqF+U+d2hnX44qAv0y5vh7h0CBb0d9a23yRq4UeKtVXyoVBSY vDaimRTe3cGQiW53ZFHilzSzt9wsz7jxesQr55froONzLBwRzZv3Ti0oBSdZ6IdxI21BMdN/GLw42 W5l3p2qbnddA+Sq8w0LQ==; 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 1jJy3W-0003S4-D2; Thu, 02 Apr 2020 11:30:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJy3S-0003Rk-MK for linux-arm-kernel@lists.infradead.org; Thu, 02 Apr 2020 11:30:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 06F8D101E; Thu, 2 Apr 2020 04:30:37 -0700 (PDT) Received: from mbp (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 316503F71E; Thu, 2 Apr 2020 04:30:36 -0700 (PDT) Date: Thu, 2 Apr 2020 12:30:33 +0100 From: Catalin Marinas To: Ard Biesheuvel Subject: Re: [RFC PATCH] arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature Message-ID: <20200402113033.GD21087@mbp> References: <20200329141258.31172-1-ardb@kernel.org> <20200330135121.GD10633@willie-the-truck> <20200330140441.GE10633@willie-the-truck> <20200330142805.GA11312@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200402_043038_771796_D6474982 X-CRM114-Status: GOOD ( 17.37 ) 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: Mark Rutland , Will Deacon , Linux ARM , kernel-hardening@lists.openwall.com 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 On Mon, Mar 30, 2020 at 04:32:31PM +0200, Ard Biesheuvel wrote: > On Mon, 30 Mar 2020 at 16:28, Will Deacon wrote: > > > On Mon, 30 Mar 2020 at 16:04, Will Deacon wrote: > > > > On Mon, Mar 30, 2020 at 03:53:04PM +0200, Ard Biesheuvel wrote: > > > > > On Mon, 30 Mar 2020 at 15:51, Will Deacon wrote: > > > > > > But I would really like to go a step further and rip out the block mapping > > > > > > support altogether so that we can fix non-coherent DMA aliases: > > > > > > > > > > > > https://lore.kernel.org/lkml/20200224194446.690816-1-hch@lst.de > > > > > > > > > > I'm not sure I follow - is this about mapping parts of the static > > > > > kernel Image for non-coherent DMA? > > > > > > > > Sorry, it's not directly related to your patch, just that if we're removing > > > > options relating to kernel mappings then I'd be quite keen on effectively > > > > forcing page-granularity on the linear map, as is currently done by default > > > > thanks to RODATA_FULL_DEFAULT_ENABLED, so that we can nobble cacheable > > > > aliases for non-coherent streaming DMA mappings by hooking into Christoph's > > > > series above. Have we ever hit this issue in practice? At least from the CPU perspective, we've assumed that a non-cacheable access would not hit in the cache. Reading the ARM ARM rules, it doesn't seem to state this explicitly but we can ask for clarification (I dug out an email from 2015, left unanswered). Assuming that the CPU is behaving as we'd expect, are there other issues with peripherals/SMMU? > > Fair enough, but I'd still like to see some numbers. If they're compelling, > > then we could explore something like CONFIG_OF_DMA_DEFAULT_COHERENT, but > > that doesn't really help the kconfig maze :( I'd prefer not to have a config option, we could easily break single Image at some point. > Could we make this a runtime thing? E.g., remap the entire linear > region down to pages under stop_machine() the first time we probe a > device that uses non-coherent DMA? That could be pretty expensive at run-time. With the ARMv8.4-TTRem feature, I wonder whether we could do this lazily when allocating non-coherent DMA buffers. (I still hope there isn't a problem at all with this mismatch ;)). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel