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 40919C46CD2 for ; Sun, 24 Dec 2023 21:48:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B62E38E0008; Sun, 24 Dec 2023 16:48:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC4668E0003; Sun, 24 Dec 2023 16:48:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93D5D8E0008; Sun, 24 Dec 2023 16:48:45 -0500 (EST) 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 8034A8E0003 for ; Sun, 24 Dec 2023 16:48:45 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 51E931401EE for ; Sun, 24 Dec 2023 21:48:45 +0000 (UTC) X-FDA: 81603051810.07.C74E1B9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 38ED440009 for ; Sun, 24 Dec 2023 21:48:41 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oP0ArS5X; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703454522; 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=iS4XqJ2iABVTA87UAP3QHDG9uzTMdMhBSMobX+j7nkw=; b=bT+lBi6qFl5Kd1RH93e9nWL8XY5t4/jR4Ydu91p1GNqFqnOBNjB7CH/zGK7oAnLUpVJ1yY uGsglmPgmuSMj2f/8bSfqSlQfvrwgVDJWb9S4XYT6at2KwTl+VXzDIuxO09FvTtI/MWadB iD7YlA8B6xK8y0VLo54P7Qfp0wLQkx4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oP0ArS5X; dmarc=none; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703454522; a=rsa-sha256; cv=none; b=EUoie8PThlM0Mv15sVG39Ei0peKRqg6pYftlC+7UvEW0dAoh2XmduOcAzs2OMtHgqc1BaC nhL5xqkIlKsxs18kvVbYVWR7MG+ZFrVTwNy/V6SzZ1HPzxKWOIFJ1Kyegl+2JTlfr0Ulf4 y5+iOa36+/cFQWQzyU6owJh3vTyIUig= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=iS4XqJ2iABVTA87UAP3QHDG9uzTMdMhBSMobX+j7nkw=; b=oP0ArS5XMerkIUplOafUOc2jkf xd6inAczmxuCSkcupZtjzZwLdPR450XFbqVXVdOoMu+ZgEVMSuXyBqVXwLEj+cvFCdjyaQ+TZlMeN GPOAZmWo5vwwIoSDRpkjzeZd01Ff1VKdrXgltm6g3/O7LKt01JtGOFz06MdIJNKq41AoANV1GBtj3 PhNxXHKxaT0oXm1YvIs1BY1OMqYslvGZF/l6iqnZ/PzN0NVBoFRKY3Jw9xZriwpXUM5iuZAbG0inV SHNsGQLdXhf87JrqnW9GEnwoHW0R+6ZiRH01SK2HXETJ5P1bOkUJ1WUd+OiIFkLTH3xg6no19SMEl /vYubegA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rHWKG-00Ek0R-Do; Sun, 24 Dec 2023 21:48:01 +0000 Date: Sun, 24 Dec 2023 21:48:00 +0000 From: Matthew Wilcox To: David Rientjes Cc: Pasha Tatashin , Andrew Morton , alim.akhtar@samsung.com, alyssa@rosenzweig.io, asahi@lists.linux.dev, baolu.lu@linux.intel.com, bhelgaas@google.com, cgroups@vger.kernel.org, corbet@lwn.net, david@redhat.com, dwmw2@infradead.org, hannes@cmpxchg.org, heiko@sntech.de, iommu@lists.linux.dev, jernej.skrabec@gmail.com, jonathanh@nvidia.com, joro@8bytes.org, krzysztof.kozlowski@linaro.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-rockchip@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org, lizefan.x@bytedance.com, marcan@marcan.st, mhiramat@kernel.org, m.szyprowski@samsung.com, paulmck@kernel.org, rdunlap@infradead.org, robin.murphy@arm.com, samuel@sholland.org, suravee.suthikulpanit@amd.com, sven@svenpeter.dev, thierry.reding@gmail.com, tj@kernel.org, tomas.mudrunka@gmail.com, vdumpa@nvidia.com, wens@csie.org, will@kernel.org, yu-cheng.yu@intel.com Subject: Re: [PATCH v2 01/10] iommu/vt-d: add wrapper functions for page allocations Message-ID: References: <20231130201504.2322355-1-pasha.tatashin@soleen.com> <20231130201504.2322355-2-pasha.tatashin@soleen.com> <776e17af-ae25-16a0-f443-66f3972b00c0@google.com> <1fd66377-030c-2e48-e658-4669bbf037e9@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1fd66377-030c-2e48-e658-4669bbf037e9@google.com> X-Rspamd-Queue-Id: 38ED440009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 3phzn77o3gr3zbm7miykkfrdexnkf38p X-HE-Tag: 1703454521-878490 X-HE-Meta: U2FsdGVkX19230a1WM2GCaGxPoBGk8owWNElGXSaUquw0VxppvewHwMyU95GmNguE3i4i0nLwzyy5dDBJAMS3rNoJnioo5bYzWdak/sxgn0mpVc7sm5wt8e4xfYeZWC8er5FMdiaMS9jeyPkgHm9T5WJ/b+1Uo9T9R1Nh4zSAKWXHd4GReDlo/NhkxdPIwY7oDOofMDmx53ouJxM9AVY91OLe8JGkTDfWhqERQKidtKvU1xDDRKknjCtsFnWuy1eS7/PXRSglwE7+8ujIHwxddWQG32koVEAnDMVM059ToWu07KY0zSFn9RtNySqBZAy+S3VttbfXqhn1QqWDU9rFCRBgvE+0xnH3k+cor3DRBq3H1v8CVZOloa71i5Q3zEXSeU3KcRMUtQlSrSVtsJbyMakQWf3tO8YuJAROTog98FfW+vlzPDIQTGR1KuKNyCgBNmbinot5IoP0Eez0fcxcCfhRrNJOm8fcoFsl0FAE19a+/ylAJswyqaylLTd/hnCJoRF0kU219e/QsXgQHA0+ZU056DF2VbHRyYmZnze5qqs93nXPa17Dh0y9aGwoxhOt0uqDrguMSNo31Fjllu2tL+Xi18iQCJj9tq6WKvLnuWgsHQ0/PIxtShI9ghs/AFM1SieVnzqERwIP7SDKlNPK9Bk2oALBUgBRHEe7DYlKDzcWCaCu+ImgrCR3QtSUKnDadZgVBOrOJQiAkpngOv1/mi6EHbW2V2Nq2/enguD93dBf2vnlQobNbna6Pd7KzYh++Wn9Hy7UAcGVpdquFp8eXnJveYEF/IoZvavWtWDjLNxb8mdfwovr2Bgq8ZjiqgdwSVy/QmAyqewQVGCsLier+1oYeVpaH8qVvs2fSEG8FBRVmSiKGjpChDOVlmOFUiedVtU4qr2yGI6gk1Ws0G4dONHs58aUNFSGn2fzhmBpRYD30VF5N9G3/iiPbBz62xulDI+/pw4o4Zo4VwyH7e dB21+1eC lriSdHGi0H4MYv0lTTE65J85S0ho+nPim651n3pB9JuOhTr3WOwHlJLGR3tfSVa6WuMWSoKDe090IwxgDMG2TN7ch0gA1wC2GzTcQX5fIWxFXl1k8f2Y8WhgL46o+42dOSh8dc3VwXKfQ4H26oCNCCQFq7CD0W2CMt5/p8HTQ/kq+16s8qP7KCAiRanGKWDrjq7IJbvWAczYOZLr97Ru2mCDckw== 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: List-Subscribe: List-Unsubscribe: On Sun, Dec 24, 2023 at 01:30:50PM -0800, David Rientjes wrote: > > > s/pages/page/ here and later in this file. > > > > In this file, where there a page with an "order", I reference it with > > "pages", when no order (i.e. order = 0), I reference it with "page" > > > > I.e.: __iommu_alloc_page vs. __iommu_alloc_pages > > > > Eh, the struct page points to a (potentially compound) page, not a set or > list of pages. I won't bikeshed on it, but "struct page *pages" never > makes sense unless it's **pages or *pages[] :) I'd suggest that 'pages' also makes sense when _not_ using __GFP_COMP, as we do in fact allocate an array of pages in that case. That said, we shouldn't encourage the use of non-compound allocations. It would also be good for someone to define a memdesc for iommu memory like we have already for slab. We'll need it eventually, and it'll work out better if someone who understands iommus (ie not me) does it.