Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1877080pxb; Mon, 20 Sep 2021 07:20:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKNxz4zTNobnoxy7ORSRRwSXlRGiPoc7XdFdLGP7pBLCMbdBrNq+h+x2eM89soLNHWpPH7 X-Received: by 2002:a05:6602:2e13:: with SMTP id o19mr19269071iow.9.1632147639495; Mon, 20 Sep 2021 07:20:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632147639; cv=none; d=google.com; s=arc-20160816; b=ajvIlsHG+PScEbZ5pbuPcRvfbNoS4SrNgINp2dELEjsCFv2xDNfwo/hsLHFdff5iBG ooBIKc5sJtQr+sxvQqTkksPRZdWVXqRcSQRp02tjFdsbVAThk+8k6m1vnCmFQZPxx4hp CSyws35jcsk3PwHDeqwq8HV/sLY3iWGYOKFGxJOzBqQdzYw15DgccpkWbpke+YJGt1Dw qNfau4jZOgODPCLsCXWxYNVQo7KrregqiwlypBAV+8NUjWE6ig139MK14m5AzDeilEKU i8SQf2aFZu2Ty+f3yAnkL0llZHvzzCEjjpR2MXaeBON+Bnv+VVVU0qk/AwYfIOdtKW+x Y3WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=N5zSDV+lSBM0JpQz6wSbLOHKNKrCyn34oUtGgIhscSM=; b=rpnS6qZeTdPAL969CUmr7Jva2XoolP6LiX/OhGkhWsUYLMZoPmSDRG2WARQTMaN+8C KPf650SZPAAjKhQo5nYwFqRewymlfJvIiAlDMHe2I/H+PfcEqfV9EDlsnpO+k/7iu5Mx wjHWL9PPqQSuDeQjc9RIg8M1Of8npaJU7mOanRBVDgkc0zfcdSB47A1SzdxM3XJ+rnNK ADJLHO+a7ltk9+o2wSGs9ZOuINSyQL57P2cgrtO94/MklhyYXWLLjGxRU9LfoEvcqdFo zodKpJGI4UHweq9cj04pD39t7P70WlOABYvrIRtu1tXmC7c0pCP4hJkxTUucyJCiZimc kg2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g11si6833668ion.10.2021.09.20.07.20.26; Mon, 20 Sep 2021 07:20:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236118AbhITK7h (ORCPT + 99 others); Mon, 20 Sep 2021 06:59:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:37294 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229999AbhITK7a (ORCPT ); Mon, 20 Sep 2021 06:59:30 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7885B60F3A; Mon, 20 Sep 2021 10:58:01 +0000 (UTC) Date: Mon, 20 Sep 2021 11:57:58 +0100 From: Catalin Marinas To: Mike Rapoport Cc: Christoph Hellwig , David Hildenbrand , Robin Murphy , Alex Bee , Will Deacon , Andrew Morton , Anshuman Khandual , Linux Kernel Mailing List , linux-mm@kvack.org, Linux ARM Subject: Re: [BUG 5.14] arm64/mm: dma memory mapping fails (in some cases) Message-ID: References: <20210824173741.GC623@arm.com> <0908ce39-7e30-91fa-68ef-11620f9596ae@arm.com> <60a11eba-2910-3b5f-ef96-97d4556c1596@redhat.com> <20210825102044.GA3420@arm.com> <20210918051843.GA16104@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 18, 2021 at 02:39:49PM +0300, Mike Rapoport wrote: > On Sat, Sep 18, 2021 at 11:37:22AM +0300, Mike Rapoport wrote: > > On Sat, Sep 18, 2021 at 07:18:43AM +0200, Christoph Hellwig wrote: > > > On Sat, Sep 18, 2021 at 12:22:47AM +0300, Mike Rapoport wrote: > > > > I did some digging and it seems that the most "generic" way to check if a > > > > page is in RAM is page_is_ram(). It's not 100% bullet proof as it'll give > > > > false negatives for architectures that do not register "System RAM", but > > > > those are not using dma_map_resource() anyway and, apparently, never would. > > > > > > The downside of page_is_ram is that it looks really expensiv for > > > something done at dma mapping time. > > > > Indeed :( > > But pfn_valid is plain wrong... > > I'll keep digging. > > I did some more archaeology and it that check for pfn_valid() was requested > by arm folks because their MMU may have troubles with alias mappings with > different attributes and so they made the check to use a false assumption > that pfn_valid() == "RAM". > > As this WARN_ON(pfn_valid()) is only present in dma_map_resource() it's > probably safe to drop it entirely. I agree, we should drop it. IIUC dma_map_resource() does not create any kernel mapping to cause problems with attribute aliasing. You'd need a prior devm_ioremap_resource() if you want access to that range from the CPU side. For arm64 at least, the latter ends up with a pfn_is_map_memory() check. -- Catalin