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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9ABC5C7EE26 for ; Fri, 12 May 2023 14:42:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 906706B0071; Fri, 12 May 2023 10:42:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8907C6B0074; Fri, 12 May 2023 10:42:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7300E6B0075; Fri, 12 May 2023 10:42:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5A3CB6B0071 for ; Fri, 12 May 2023 10:42:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 20B60AEC47 for ; Fri, 12 May 2023 14:42:29 +0000 (UTC) X-FDA: 80781868818.02.26E4651 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 31C9440012 for ; Fri, 12 May 2023 14:42:26 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TFARr7Yj; spf=pass (imf27.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683902547; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UfWbYDnk88fPV7cf1hTEgaU+kJim0xDW+YMy86F8N2Y=; b=TmC+JkNvjVS+Ao3TDTTOL9Ok+8aVAyXibKxeJiv/JghckYydbExAEuvbdIpL6ebzd5BmoD NZLekjoJMgoSEyGtiRD4W29FgwcK6QodAgsmmUE+EA2eaVNYWzDpFIX9mHweACXiSDQ+u4 cmJDq7tt6Ak+oqHf9OBcezKSwe/Qj5c= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TFARr7Yj; spf=pass (imf27.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683902547; a=rsa-sha256; cv=none; b=sfjencuYshyS/r71iRNwyRtO2PjARBQWt/9oZayX7HDfVBxNsZr9NreW59UCR/7BdFBE2g qKZPfbEyCzzcZxaDWFmvzQ0MC9Sl6iUSSsfrAgT1bTHAs+RUj5d6ON20AzD7YTX9F5IIcB a5oyXrU2gzhCMzUAD1xb9aTgISKb60g= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E18D960C84 for ; Fri, 12 May 2023 14:42:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DE18C433EF for ; Fri, 12 May 2023 14:42:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683902545; bh=Cq0Kbtx91XM0CWPBj4j6IY7NnGd/kSGer8Mrsg2uWeI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TFARr7Yju0/zYC3P03kjGthGO4LKrUPM6ZV2dy1VAbme1m7iah/Q2v/j+YdArMjC2 IISKa5rqJe5QHiOpL+b1eQm3mm3PiZ9YkVaDKIDgwcEPNhOk5nodB0VrUQjSGwG44N 9c1JnpacFGfWPXVIAT5UOsLC42ZCz3IiNgQbk1vtX1cuWb1QnxeWvf6UVCnRY+TQk2 iX2Uo6MMgxgIUTbD4N1EKorWMs+I89a7xvcMNzbHLDjWqT4ZBw9aIvAM3kTxRvSbcf M2ZGMl5kWNNFADPOgaGGQ8v0eFuvVYWfb0ZgnF7esXrQmmMj1/bysLxSRacvaK7oO1 NKVWaYw1e5ztw== Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-4f139de8cefso52620385e87.0 for ; Fri, 12 May 2023 07:42:25 -0700 (PDT) X-Gm-Message-State: AC+VfDx0/5nb/cIB3hVJoachlMqk54TW/BMSfW+ixvCh5H59dayYlZwa PNEX2ATn+Fq6EjR/kRzOZaU1qBez9mExIHpW5gE= X-Google-Smtp-Source: ACHHUZ5EB+DWgV11PDIE1zsI8SLx4pz1jY2iF09/gzRcWg7Lu9DuSS4cTes2wcetJPmkVKvoac2pTbi5cjXcWlbxiso= X-Received: by 2002:a05:6512:33d4:b0:4f0:3e1:9ada with SMTP id d20-20020a05651233d400b004f003e19adamr4151585lfg.31.1683902543268; Fri, 12 May 2023 07:42:23 -0700 (PDT) MIME-Version: 1.0 References: <20230406040515.383238-1-jhubbard@nvidia.com> <8dd0e252-8d8b-a62d-8836-f9f26bc12bc7@nvidia.com> <90505ef2-9250-d791-e05d-dbcb7672e4c4@nvidia.com> In-Reply-To: <90505ef2-9250-d791-e05d-dbcb7672e4c4@nvidia.com> From: Ard Biesheuvel Date: Fri, 12 May 2023 16:42:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] arm64/mm: don't WARN when alloc/free-ing device private pages To: John Hubbard Cc: Andrew Morton , Catalin Marinas , Will Deacon , Anshuman Khandual , Mark Rutland , Kefeng Wang , Feiyang Chen , Alistair Popple , Ralph Campbell , linux-arm-kernel@lists.infradead.org, LKML , linux-mm@kvack.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 7qyrictbo7o1ztff76qbqyo3d8664dud X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 31C9440012 X-Rspam-User: X-HE-Tag: 1683902546-337544 X-HE-Meta: U2FsdGVkX194xQ9GIfs+3BTc3D2OlMK/v1p7X8ORGuKDc5pPvMBrmkWIGjbWIdN6j4aZjXU5cRzz7si6Y/6Lg5tbn/+HYk2eMYS1NcXNPuUHULR1iFh1lZyM0GrvgXtouCeyVcnY2nabfYmVtmD0k3tQnj1OMwv+k6m3lfLnwNsLLE+TvH6hRqMBflxlSAJ09AkkVPNMAyA+Vm6ENRfJ8HknbJIt+rpuBO6ZCSjLSbnCAbtQxjpmVgLKaU7Beoul69YkXR7DFbpFRC9+EaJna71zjVYXqLEcgHV4VqJD77hFtUSEfSr0iXPdvoznWfJZ+zgzBCwn6B1kVhVfeIk/JvpWn5y6w/Gzx0Pnprq9AkiInAcKcXT3QVekMXy95C/Mi5/JjQgOPSZR1l5gbha3zkt/rkjO995ampoROf29x3zbSTy8YEtK2djm5zJ9oc+Ezf3ZFyqSzxxYfU8koAFYdaIB/8DaDU/IUMjRLujNmRAYLVsa968b/ly1h8IAeU15D/DysNFRF+s+Fg7F9DflaveF6i84dhV5b7Hztr8ZcfZfqxkZqsqbrkDSs+Kdy/D83+ao19HZreDzvdwUCBQ8p8yTRX7AyxiKEu+YwGPKYKE1OEmq+5nYIECCAMc8RLBUydlCbLP3EaciO2Ol2W2FeaMpN+d80TKnwb3xbER+uHmsD0HTTW0RggtMn7k5Q0IK/hOZXHbOSj8S3Vl5JlFV8oclTTt+ewGKo/0ciX0wMZj4KpG95KI3w3a2InWKP4IDF7ZPissbkASE+LXInrTCMrZLkebkoDVuDHS1tT0W3Oz4Db/DMjV0cEes3ZkKag2k0WGVf3frkCrW6JmGRdVrwA5p5Dd5bL4umRDakyC329rdLKQOIRRiKIyVC64v4m+pgB4D838aalqI+x3NjI136j3cu/vQKsG7cvdO/6lj65x+dKVQTbhNB6g4OZl0gR+chLUI/PxlvaeeL+o//eb QunCK0Fv CSjhcdxyHPHznc/gfoZwO0Fr5ExUFJHRjcVYWvWXqmmta59gcfJo0k3LaysgTp/lD2L0YQ71M9TTPL/E7MBGPIOLO+r7hyF1cAPZw0TFgcxOM7MV1bUvYbz8nHUqRZuhLfrpP62IEZoAePT+B8kiC50PfovR8aGKap6n0IhZw+EZYyWDSpOx3wz5UsRx5y9Ty8dsMKuCPIgqBP5+yJZC0FTdjnMq/eZhsOpSIoYR8onMheDFE2V4CAIqI+Jre3cWaktDRTFnwM1aVCfST5dPpFjEkn8Okr7XR8R5j6h0/I2h3pK2YQa65hxMQgzleSwDP6U8hIk8It5XPW1XzJPvNjw1axQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 11 Apr 2023 at 04:48, John Hubbard wrote: > > On 4/10/23 00:39, John Hubbard wrote: > >> pfn_to_page(x) for values 0xc00_0000 < x < 0x1000_0000 will produce a > >> kernel VA that points outside the region set aside for the vmemmap. > >> This region is currently unused, but that will likely change soon. > >> > > > > I tentatively think I'm in this case right now. Because there is no wrap > > around happening in my particular config, which is CONFIG_ARM64_VA_BITS > > == 48, and PAGE_SIZE == 4KB and sizeof(struct page) == 64 (details > > below). > > > > Correction, actually it *is* wrapping around, and ending up as a bogus > user space address, as you said it would when being above the range: > > page_to_pfn(0xffffffffaee00000): 0x0000000ffec38000 > Interesting. > > > It occurs to me that ZONE_DEVICE and (within that category) device > > private page support need only support rather large setups. On x86, it > > requires 64-bit. And on arm64, from what I'm learning after a day or so > > of looking around and comparing, I think we must require at least 48 bit > > VA support. Otherwise there's just no room for things. > > I'm still not sure of how to make room, but working on it. > The assumption that only the linear map needs to be covered by struct pages is rather fundamental to the arm64 mm code, as far as I am aware. Given that these device memory regions have no direct correspondence with the linear map at all, couldn't we simply vmalloc() a range of memory for struct pages for such a region and wire that up in the existing code? That seems far more maintainable to me than reorganizing the entire kernel VA space, and only for some choices for the dimensions.