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 E66DEC197A0 for ; Thu, 16 Nov 2023 10:08:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69CC56B0449; Thu, 16 Nov 2023 05:08:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 627A16B044B; Thu, 16 Nov 2023 05:08:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49F606B044C; Thu, 16 Nov 2023 05:08:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3398E6B0449 for ; Thu, 16 Nov 2023 05:08:02 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0EEB1B5EC8 for ; Thu, 16 Nov 2023 10:08:02 +0000 (UTC) X-FDA: 81463391604.24.05A9611 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 06D3B140012 for ; Thu, 16 Nov 2023 10:07:59 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700129280; a=rsa-sha256; cv=none; b=Mc77vhdDbOnle/fsioho33Oi8I7ucvwGoAR5lbA9uAeqiuntL0FpnMSiN19vXG1ggFrU9u b8uXY2i9k2g59isf3d8PV+XPxD+3i0vXo5ahXOMvVSTDW7jRCWjP9k9B5Us1wr9dDclq4R CFD+ofnHqeBzmNEc8/IOcOQKumYYvSA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700129280; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iKdOJipVYxyVeBsEe303Z7UgtiPkk3DP9PjYT1oTA9M=; b=RAQBQr5ld6Go48SAy4aXYNfq/4oEOqNPmI0DUCpSCg0DSUueZ+97DhNSjFDqPEIXxyWu0b X3S4d8qRRxYxE3/3xvt63p5337+YkeFhl2Vwtthtyq5evhJ8yidZCFI5pXE+0X2CTL0tQQ K4K3fKgfbKIK/ZfniTs3BjNGAulMEnI= 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 B0F741595; Thu, 16 Nov 2023 02:08:44 -0800 (PST) Received: from [10.1.35.163] (XHFQ2J9959.cambridge.arm.com [10.1.35.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 42D543F6C4; Thu, 16 Nov 2023 02:07:55 -0800 (PST) Message-ID: Date: Thu, 16 Nov 2023 10:07:53 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork() Content-Language: en-GB To: kernel test robot , Catalin Marinas , Will Deacon , Ard Biesheuvel , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Andrew Morton , Anshuman Khandual , Matthew Wilcox , Yu Zhao , Mark Rutland , David Hildenbrand , Kefeng Wang , John Hubbard , Zi Yan Cc: oe-kbuild-all@lists.linux.dev, Linux Memory Management List , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20231115163018.1303287-2-ryan.roberts@arm.com> <202311160516.kHhfmjvl-lkp@intel.com> From: Ryan Roberts In-Reply-To: <202311160516.kHhfmjvl-lkp@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 06D3B140012 X-Stat-Signature: x89o18tf45ezrptsdm7tqnz1u57inwb3 X-HE-Tag: 1700129279-740539 X-HE-Meta: U2FsdGVkX18Rg8SFz4JxGHdAlfxPeMnFb9XvwDCE/u2GpKMkPcozfdbjPPppF4Qm4a7oagk67ZI178pYkyAA/gw7IbplSI1+xntSoM0suKEB7TeZRgVjcUeY2ss/WzBWTLj6dcDYxGYjmjkBir0UlYkpicYOx35kw8QB2N+v2lJnL8Y7W3zM0CstY4vUoMOdSj5QxgCdWHi1Ln9ZtSpdBWpxJxcn6P31fur9K4571jm9soiZXqZewo9Zq1htk2xXvQgSFjCXE0zInIKy/0MfcYGf6qctdan1w9Pynx04cqa+jR0wAdzTp9h8l4/O81C/AWZu7pQIpuLj+cjPl57kziIZoZOQnDA2OcQE6zIIIzjYsdiSzvySWME4dHAQx0uDvVdGF9fZfA602Hfz5q1/omtPI3Zomz0WvMrk3NQUcjoaAtqkbknoUjHVy0lyOb+YBBZ5mQtJnVC+9L9mKy/7xkdMDeAPXo9LShDoCPaHUeRpiSek8n+ItJ70IlsHTR0Qw2tGSRiFwsuzBS+C0x56eP1u/a0CsOgvYqL6aNSI6+Npf5yjfYWbPHyTvlihqbJT9mFrvma+247rysZ2eKH+A2s6T+K2j7zzFCgQ5dZbSBojidF2DvvFBvtHCByTH9cCrTYzbsBJN99z3KYIrkIhkpY5P+WabgF5GDYGRu54lgBYfa0N7faAQamWnIHXhBn7SY7A1Btsu5SKYX5qTZp5p4IbWNSS5nJXr1pqEGmDXHlDqAEvSNiZ+LbbxwYId7wAOPlnd33fdca0Vo+Jt395Oy8ST/wIAfigoL0CO4XZrCevyNTAj7x2fguMyn+G2TKlpd69k4ULxeNN7NvrDbAlYd7vbnryskz0xFUBuGPGCvAH7CEsDvbO0tUIpgcyXSz94NFb10RJMJ3vz2yueZmLliczAVRs+oWB441cA7MYlakZTMOP6RvHuEmEkc2N8UbhFn852wXLdR76SwVnz6W JurGxpYx UD5ReSg+BczVqMM/Dd3sYyAcXpVJLu4BygNy54V8cr4oAiVGQV413cUGLQCFAmu2qZH7ateUeCN7IihnbpGskVEAqodLAbs0njg8/GgPAlEM8cqnC6NV1sZ/O8sUCgvdWQitadzEbcPQ6mKKVk5xbIQ1tmw+mAtDOHSldRsFDP9ep4NgBSPxAwe8ZtYk7RqCtsmPuCwu36exNJH3LHlDyQ91dhPDAmH7WtuNmRfXbLTYiBnGmzeaXoPYxhzaC2fh7/Nz8Y6CVsFaZs6keTMmRoBxDm9RGYNSZ58zeIEuprTkrsYXVcmzM2BXivafQbYfnxI0hK6vA/EUJunVhPqg8tln940A/Yd1Kqb3DwQ3mAEmQasEwo/9BKBDZ2dVGZ9HdrryZ+aPD/Hk6MTPNEsAbVQSInH1S2kCDoF71aNSk/tlTtlcl/vdSLOsyFo5dYzsDKVxlV39BnqNRvYtX1I4aO+rgaj5Cg5nZcr/jZqaooPljd9GRrI1vXizKUoOvW6sIQIzy 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: Hi All, Hoping for some guidance below! On 15/11/2023 21:26, kernel test robot wrote: > Hi Ryan, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on akpm-mm/mm-everything] > [also build test ERROR on linus/master v6.7-rc1 next-20231115] > [cannot apply to arm64/for-next/core efi/next] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: https://github.com/intel-lab-lkp/linux/commits/Ryan-Roberts/mm-Batch-copy-PTE-ranges-during-fork/20231116-010123 > base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything > patch link: https://lore.kernel.org/r/20231115163018.1303287-2-ryan.roberts%40arm.com > patch subject: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork() > config: arm-randconfig-002-20231116 (https://download.01.org/0day-ci/archive/20231116/202311160516.kHhfmjvl-lkp@intel.com/config) > compiler: arm-linux-gnueabi-gcc (GCC) 13.2.0 > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20231116/202311160516.kHhfmjvl-lkp@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: https://lore.kernel.org/oe-kbuild-all/202311160516.kHhfmjvl-lkp@intel.com/ > > All errors (new ones prefixed by >>): > > mm/memory.c: In function 'folio_nr_pages_cont_mapped': >>> mm/memory.c:969:16: error: implicit declaration of function 'pte_pgprot'; did you mean 'ptep_get'? [-Werror=implicit-function-declaration] > 969 | prot = pte_pgprot(pte_mkold(pte_mkclean(ptent))); > | ^~~~~~~~~~ > | ptep_get > cc1: some warnings being treated as errors It turns out that pte_pgprot() is not universal; its only implemented by architectures that select CONFIG_HAVE_IOREMAP_PROT (currently arc, arm64, loongarch, mips, powerpc, s390, sh, x86). I'm using it in core-mm to help calculate the number of "contiguously mapped" pages within a folio (note that's not the same as arm64's notion of contpte-mapped. I just want to know that there are N physically contiguous pages mapped virtually contiguously with the same permissions). And I'm using pte_pgprot() to extract the permissions for each pte to compare. It's important that we compare the permissions because just because the pages belongs to the same folio doesn't imply they are mapped with the same permissions; think mprotect()ing a sub-range. I don't have a great idea for how to fix this - does anyone have any thoughts? Some ideas: - Implement folio_nr_pages_cont_mapped() conditionally on CONFIG_HAVE_IOREMAP_PROT being set, otherwise it just returns 1 and for those arches we always get the old, non-batching behavior. There is some precident; mm/memory.c is already using pte_pgprot() behind this ifdef. - Implement a generic helper the same way arm64 does it. This will return all the pte bits that are not part of the PFN. But I'm not sure this is definitely a valid thing to do for all architectures: static inline pgprot_t pte_pgprot(pte_t pte) { unsigned long pfn = pte_pfn(pte); return __pgprot(pte_val(pfn_pte(pfn, __pgprot(0))) ^ pte_val(pte)); } - Explicitly implement pte_pgprot() for all arches that don't currently have it (sigh). Thanks, Ryan > > > vim +969 mm/memory.c > > 950 > 951 static int folio_nr_pages_cont_mapped(struct folio *folio, > 952 struct page *page, pte_t *pte, > 953 unsigned long addr, unsigned long end, > 954 pte_t ptent, bool *any_dirty) > 955 { > 956 int floops; > 957 int i; > 958 unsigned long pfn; > 959 pgprot_t prot; > 960 struct page *folio_end; > 961 > 962 if (!folio_test_large(folio)) > 963 return 1; > 964 > 965 folio_end = &folio->page + folio_nr_pages(folio); > 966 end = min(page_cont_mapped_vaddr(folio_end, page, addr), end); > 967 floops = (end - addr) >> PAGE_SHIFT; > 968 pfn = page_to_pfn(page); > > 969 prot = pte_pgprot(pte_mkold(pte_mkclean(ptent))); > 970 > 971 *any_dirty = pte_dirty(ptent); > 972 > 973 pfn++; > 974 pte++; > 975 > 976 for (i = 1; i < floops; i++) { > 977 ptent = ptep_get(pte); > 978 ptent = pte_mkold(pte_mkclean(ptent)); > 979 > 980 if (!pte_present(ptent) || pte_pfn(ptent) != pfn || > 981 pgprot_val(pte_pgprot(ptent)) != pgprot_val(prot)) > 982 break; > 983 > 984 if (pte_dirty(ptent)) > 985 *any_dirty = true; > 986 > 987 pfn++; > 988 pte++; > 989 } > 990 > 991 return i; > 992 } > 993 >