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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 96873C432BE for ; Tue, 31 Aug 2021 13:33:41 +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 5DB8160F92 for ; Tue, 31 Aug 2021 13:33:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5DB8160F92 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=xLkwhTVPsrpaBb+Auk913GjhPsjdTM/g06GuxGidmrk=; b=yBP+tlbfshfdra pHQIdwp1o5KIfW7kMfXbuh58LAyOiKaDSHFZM0WH5w/wxDO50nQsVCPr/Ad7lVWwPYqGHZu6+X1kd GUNuvD2qHB1n9tXInbdjJhU0EBOcDzWeQ6YBS1o7LHlxL/1pRQKPF8wSYyRd66NmrxzudaMvkaSxb 7oHy5q63BnVJuv2lDgONvN+uWs19Xs2SARR/otkNH1nA26K3hO/KQd1C2CMGjuVtxze0NJeVhVrf9 /hmTQKalnRzIVB82e8KofeIHw7x93Mfqh8UjeIQ4AoLWRg70ZsW/ruX/LflYrbS13lSdW4fY7dGBE cWMAcsw84v5JHg+3eCiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mL3rQ-002KL2-I0; Tue, 31 Aug 2021 13:31:32 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mL3rI-002KK9-Bk for linux-arm-kernel@lists.infradead.org; Tue, 31 Aug 2021 13:31:25 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 438C560249; Tue, 31 Aug 2021 13:31:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630416682; bh=yfQIQYdgnIv9MEe5gtI21/szPMXdVIsmtImv9y6mkGI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=izxX5uSZclyn0YetApctJ3htw30uSf7HiMuFzRZmej6Macq5nNuXXLnMCNI63G8q2 mom12LvjWriKAQxzzotSfG5vu58R40KT7iNDO2vOEeE8rA16oCqNSpMzWAvWDpnPwL qFBb1GLl0JoMPZ8ccfe0ZK+vtbcyg/zWLqfKlcdSHKeJ1vrm0N8Asc3Z52AFA1LdxO GJaMTIzXsOTzcILA1nIQlWja9wDf6tD7gPmlNX0r1vTRQ+3Feue4AVEG9c44UmjgDC o9zTE733D8FkDZDHegehbEIQQzeaSpCjqoRsHAbfX96t50xbJ+XOTSaTYHWfhyn2tW KHUPy/FFM549A== Date: Tue, 31 Aug 2021 14:31:17 +0100 From: Will Deacon To: Linus Torvalds Cc: Christoph Hellwig , Catalin Marinas , Linux ARM , Linux Kernel Mailing List , Android Kernel Team , david@redhat.com Subject: Re: [GIT PULL] arm64 fix for 5.14 Message-ID: <20210831133117.GD31712@willie-the-truck> References: <20210826131747.GE26318@willie-the-truck> <20210827074041.GA24309@lst.de> <20210827171041.GA28149@lst.de> 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-20210831_063124_468289_03A17994 X-CRM114-Status: GOOD ( 23.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org [+David] On Fri, Aug 27, 2021 at 10:16:27AM -0700, Linus Torvalds wrote: > On Fri, Aug 27, 2021 at 10:10 AM Christoph Hellwig wrote: > > > > They CCed me on their earlier discussion, but I did not catch up on it > > until you responded to the pull request If I understood it correct it > > was about a platform device mapping a MMIO region (like a PCI bar), > > but something about section alignment cause pfn_valid to mistrigger. > > Yeah, so I can easily see the maxpfn numbers can easily end up being > rounded up to a whole memory section etc. > > I think my suggested solution should JustWork(tm) - exactly because if > the area is then in that "this pfn is valid" area, it will > double-check the actual underlying page. I think the pitfall there is that the 'struct page' might well exist, but isn't necessarily initialised with anything meaningful. I remember seeing something like that in the past (I think for "no-map" memory) and David's reply here: https://lore.kernel.org/r/aff3942e-b9ce-5bae-8214-0e5d89cd071c@redhat.com hints that there are still gotchas with looking at the page flags for pages if the memory is offline or ZONE_DEVICE. Don't get me wrong, I'd really like to use the generic code here as I think it would help to set expectations around what pfn_valid() actually means, I'm just less keen on the try-it-and-see-what-breaks approach given how sensitive it is to the layout of the physical memory map. > That said, I think x86 avoids the problem another way - by just making > sure max_pfn is exact. That works too, as long as there are no holes > in the RAM map that might be used for PCI BAR's. > > So I think arm could fix it that way too, depending on their memory layout. The physical memory map is the wild west, unfortunately. It's one of the things where everybody does something different and it's very common to see disjoint banks of memory placed seemingly randomly around. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel