From: kernel test robot <lkp@intel.com>
To: Ryan Roberts <ryan.roberts@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Yin Fengwei <fengwei.yin@intel.com>,
David Hildenbrand <david@redhat.com>, Yu Zhao <yuzhao@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Yang Shi <shy828301@gmail.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
Ryan Roberts <ryan.roberts@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance
Date: Tue, 4 Jul 2023 00:01:58 +0800 [thread overview]
Message-ID: <202307032330.TguyNttt-lkp@intel.com> (raw)
In-Reply-To: <20230703135330.1865927-5-ryan.roberts@arm.com>
Hi Ryan,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v6.4]
[cannot apply to akpm-mm/mm-everything linus/master next-20230703]
[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-Non-pmd-mappable-large-folios-for-folio_add_new_anon_rmap/20230703-215627
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20230703135330.1865927-5-ryan.roberts%40arm.com
patch subject: [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance
config: um-allnoconfig (https://download.01.org/0day-ci/archive/20230703/202307032330.TguyNttt-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce: (https://download.01.org/0day-ci/archive/20230703/202307032330.TguyNttt-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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202307032330.TguyNttt-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from mm/memory.c:42:
In file included from include/linux/kernel_stat.h:9:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
547 | val = __raw_readb(PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
560 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
| ^
In file included from mm/memory.c:42:
In file included from include/linux/kernel_stat.h:9:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
573 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
| ^
In file included from mm/memory.c:42:
In file included from include/linux/kernel_stat.h:9:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
584 | __raw_writeb(value, PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
594 | __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
604 | __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
692 | readsb(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
700 | readsw(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:708:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
708 | readsl(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:717:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
717 | writesb(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:726:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
726 | writesw(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:735:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
735 | writesl(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
>> mm/memory.c:4271:2: error: call to undeclared function 'set_ptes'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
4271 | set_ptes(vma->vm_mm, addr, vmf->pte, entry, pgcount);
| ^
mm/memory.c:4271:2: note: did you mean 'set_pte'?
arch/um/include/asm/pgtable.h:232:20: note: 'set_pte' declared here
232 | static inline void set_pte(pte_t *pteptr, pte_t pteval)
| ^
>> mm/memory.c:4274:2: error: call to undeclared function 'update_mmu_cache_range'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
4274 | update_mmu_cache_range(vma, addr, vmf->pte, pgcount);
| ^
12 warnings and 2 errors generated.
vim +/set_ptes +4271 mm/memory.c
4135
4136 /*
4137 * We enter with non-exclusive mmap_lock (to exclude vma changes,
4138 * but allow concurrent faults), and pte mapped but not yet locked.
4139 * We return with mmap_lock still held, but pte unmapped and unlocked.
4140 */
4141 static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
4142 {
4143 bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
4144 struct vm_area_struct *vma = vmf->vma;
4145 struct folio *folio;
4146 vm_fault_t ret = 0;
4147 pte_t entry;
4148 int order;
4149 int pgcount;
4150 unsigned long addr;
4151
4152 /* File mapping without ->vm_ops ? */
4153 if (vma->vm_flags & VM_SHARED)
4154 return VM_FAULT_SIGBUS;
4155
4156 /*
4157 * Use pte_alloc() instead of pte_alloc_map(). We can't run
4158 * pte_offset_map() on pmds where a huge pmd might be created
4159 * from a different thread.
4160 *
4161 * pte_alloc_map() is safe to use under mmap_write_lock(mm) or when
4162 * parallel threads are excluded by other means.
4163 *
4164 * Here we only have mmap_read_lock(mm).
4165 */
4166 if (pte_alloc(vma->vm_mm, vmf->pmd))
4167 return VM_FAULT_OOM;
4168
4169 /* See comment in handle_pte_fault() */
4170 if (unlikely(pmd_trans_unstable(vmf->pmd)))
4171 return 0;
4172
4173 /* Use the zero-page for reads */
4174 if (!(vmf->flags & FAULT_FLAG_WRITE) &&
4175 !mm_forbids_zeropage(vma->vm_mm)) {
4176 entry = pte_mkspecial(pfn_pte(my_zero_pfn(vmf->address),
4177 vma->vm_page_prot));
4178 vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
4179 vmf->address, &vmf->ptl);
4180 if (vmf_pte_changed(vmf)) {
4181 update_mmu_tlb(vma, vmf->address, vmf->pte);
4182 goto unlock;
4183 }
4184 ret = check_stable_address_space(vma->vm_mm);
4185 if (ret)
4186 goto unlock;
4187 /* Deliver the page fault to userland, check inside PT lock */
4188 if (userfaultfd_missing(vma)) {
4189 pte_unmap_unlock(vmf->pte, vmf->ptl);
4190 return handle_userfault(vmf, VM_UFFD_MISSING);
4191 }
4192 if (uffd_wp)
4193 entry = pte_mkuffd_wp(entry);
4194 set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
4195
4196 /* No need to invalidate - it was non-present before */
4197 update_mmu_cache(vma, vmf->address, vmf->pte);
4198 goto unlock;
4199 }
4200
4201 /*
4202 * If allocating a large folio, determine the biggest suitable order for
4203 * the VMA (e.g. it must not exceed the VMA's bounds, it must not
4204 * overlap with any populated PTEs, etc). We are not under the ptl here
4205 * so we will need to re-check that we are not overlapping any populated
4206 * PTEs once we have the lock.
4207 */
4208 order = uffd_wp ? 0 : max_anon_folio_order(vma);
4209 if (order > 0) {
4210 vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
4211 order = calc_anon_folio_order_alloc(vmf, order);
4212 pte_unmap(vmf->pte);
4213 }
4214
4215 /* Allocate our own private folio. */
4216 if (unlikely(anon_vma_prepare(vma)))
4217 goto oom;
4218 folio = alloc_anon_folio(vma, vmf->address, order);
4219 if (!folio && order > 0) {
4220 order = 0;
4221 folio = alloc_anon_folio(vma, vmf->address, order);
4222 }
4223 if (!folio)
4224 goto oom;
4225
4226 pgcount = 1 << order;
4227 addr = ALIGN_DOWN(vmf->address, pgcount << PAGE_SHIFT);
4228
4229 if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
4230 goto oom_free_page;
4231 folio_throttle_swaprate(folio, GFP_KERNEL);
4232
4233 /*
4234 * The memory barrier inside __folio_mark_uptodate makes sure that
4235 * preceding stores to the folio contents become visible before
4236 * the set_ptes() write.
4237 */
4238 __folio_mark_uptodate(folio);
4239
4240 entry = mk_pte(&folio->page, vma->vm_page_prot);
4241 entry = pte_sw_mkyoung(entry);
4242 if (vma->vm_flags & VM_WRITE)
4243 entry = pte_mkwrite(pte_mkdirty(entry));
4244
4245 vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
4246 if (vmf_pte_changed(vmf)) {
4247 update_mmu_tlb(vma, vmf->address, vmf->pte);
4248 goto release;
4249 } else if (order > 0 && check_ptes_none(vmf->pte, pgcount) != pgcount) {
4250 goto release;
4251 }
4252
4253 ret = check_stable_address_space(vma->vm_mm);
4254 if (ret)
4255 goto release;
4256
4257 /* Deliver the page fault to userland, check inside PT lock */
4258 if (userfaultfd_missing(vma)) {
4259 pte_unmap_unlock(vmf->pte, vmf->ptl);
4260 folio_put(folio);
4261 return handle_userfault(vmf, VM_UFFD_MISSING);
4262 }
4263
4264 folio_ref_add(folio, pgcount - 1);
4265 add_mm_counter(vma->vm_mm, MM_ANONPAGES, pgcount);
4266 folio_add_new_anon_rmap(folio, vma, addr);
4267 folio_add_lru_vma(folio, vma);
4268
4269 if (uffd_wp)
4270 entry = pte_mkuffd_wp(entry);
> 4271 set_ptes(vma->vm_mm, addr, vmf->pte, entry, pgcount);
4272
4273 /* No need to invalidate - it was non-present before */
> 4274 update_mmu_cache_range(vma, addr, vmf->pte, pgcount);
4275 unlock:
4276 pte_unmap_unlock(vmf->pte, vmf->ptl);
4277 return ret;
4278 release:
4279 folio_put(folio);
4280 goto unlock;
4281 oom_free_page:
4282 folio_put(folio);
4283 oom:
4284 return VM_FAULT_OOM;
4285 }
4286
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com>
To: Ryan Roberts <ryan.roberts@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Yin Fengwei <fengwei.yin@intel.com>,
David Hildenbrand <david@redhat.com>, Yu Zhao <yuzhao@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Yang Shi <shy828301@gmail.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
Ryan Roberts <ryan.roberts@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance
Date: Tue, 4 Jul 2023 00:01:58 +0800 [thread overview]
Message-ID: <202307032330.TguyNttt-lkp@intel.com> (raw)
In-Reply-To: <20230703135330.1865927-5-ryan.roberts@arm.com>
Hi Ryan,
kernel test robot noticed the following build errors:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v6.4]
[cannot apply to akpm-mm/mm-everything linus/master next-20230703]
[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-Non-pmd-mappable-large-folios-for-folio_add_new_anon_rmap/20230703-215627
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
patch link: https://lore.kernel.org/r/20230703135330.1865927-5-ryan.roberts%40arm.com
patch subject: [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance
config: um-allnoconfig (https://download.01.org/0day-ci/archive/20230703/202307032330.TguyNttt-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a)
reproduce: (https://download.01.org/0day-ci/archive/20230703/202307032330.TguyNttt-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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202307032330.TguyNttt-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from mm/memory.c:42:
In file included from include/linux/kernel_stat.h:9:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
547 | val = __raw_readb(PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
560 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu'
37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
| ^
In file included from mm/memory.c:42:
In file included from include/linux/kernel_stat.h:9:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
573 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
| ~~~~~~~~~~ ^
include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu'
35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
| ^
In file included from mm/memory.c:42:
In file included from include/linux/kernel_stat.h:9:
In file included from include/linux/interrupt.h:11:
In file included from include/linux/hardirq.h:11:
In file included from arch/um/include/asm/hardirq.h:5:
In file included from include/asm-generic/hardirq.h:17:
In file included from include/linux/irq.h:20:
In file included from include/linux/io.h:13:
In file included from arch/um/include/asm/io.h:24:
include/asm-generic/io.h:584:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
584 | __raw_writeb(value, PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:594:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
594 | __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:604:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
604 | __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:692:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
692 | readsb(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:700:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
700 | readsw(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:708:20: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
708 | readsl(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:717:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
717 | writesb(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:726:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
726 | writesw(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
include/asm-generic/io.h:735:21: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
735 | writesl(PCI_IOBASE + addr, buffer, count);
| ~~~~~~~~~~ ^
>> mm/memory.c:4271:2: error: call to undeclared function 'set_ptes'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
4271 | set_ptes(vma->vm_mm, addr, vmf->pte, entry, pgcount);
| ^
mm/memory.c:4271:2: note: did you mean 'set_pte'?
arch/um/include/asm/pgtable.h:232:20: note: 'set_pte' declared here
232 | static inline void set_pte(pte_t *pteptr, pte_t pteval)
| ^
>> mm/memory.c:4274:2: error: call to undeclared function 'update_mmu_cache_range'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
4274 | update_mmu_cache_range(vma, addr, vmf->pte, pgcount);
| ^
12 warnings and 2 errors generated.
vim +/set_ptes +4271 mm/memory.c
4135
4136 /*
4137 * We enter with non-exclusive mmap_lock (to exclude vma changes,
4138 * but allow concurrent faults), and pte mapped but not yet locked.
4139 * We return with mmap_lock still held, but pte unmapped and unlocked.
4140 */
4141 static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
4142 {
4143 bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
4144 struct vm_area_struct *vma = vmf->vma;
4145 struct folio *folio;
4146 vm_fault_t ret = 0;
4147 pte_t entry;
4148 int order;
4149 int pgcount;
4150 unsigned long addr;
4151
4152 /* File mapping without ->vm_ops ? */
4153 if (vma->vm_flags & VM_SHARED)
4154 return VM_FAULT_SIGBUS;
4155
4156 /*
4157 * Use pte_alloc() instead of pte_alloc_map(). We can't run
4158 * pte_offset_map() on pmds where a huge pmd might be created
4159 * from a different thread.
4160 *
4161 * pte_alloc_map() is safe to use under mmap_write_lock(mm) or when
4162 * parallel threads are excluded by other means.
4163 *
4164 * Here we only have mmap_read_lock(mm).
4165 */
4166 if (pte_alloc(vma->vm_mm, vmf->pmd))
4167 return VM_FAULT_OOM;
4168
4169 /* See comment in handle_pte_fault() */
4170 if (unlikely(pmd_trans_unstable(vmf->pmd)))
4171 return 0;
4172
4173 /* Use the zero-page for reads */
4174 if (!(vmf->flags & FAULT_FLAG_WRITE) &&
4175 !mm_forbids_zeropage(vma->vm_mm)) {
4176 entry = pte_mkspecial(pfn_pte(my_zero_pfn(vmf->address),
4177 vma->vm_page_prot));
4178 vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
4179 vmf->address, &vmf->ptl);
4180 if (vmf_pte_changed(vmf)) {
4181 update_mmu_tlb(vma, vmf->address, vmf->pte);
4182 goto unlock;
4183 }
4184 ret = check_stable_address_space(vma->vm_mm);
4185 if (ret)
4186 goto unlock;
4187 /* Deliver the page fault to userland, check inside PT lock */
4188 if (userfaultfd_missing(vma)) {
4189 pte_unmap_unlock(vmf->pte, vmf->ptl);
4190 return handle_userfault(vmf, VM_UFFD_MISSING);
4191 }
4192 if (uffd_wp)
4193 entry = pte_mkuffd_wp(entry);
4194 set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
4195
4196 /* No need to invalidate - it was non-present before */
4197 update_mmu_cache(vma, vmf->address, vmf->pte);
4198 goto unlock;
4199 }
4200
4201 /*
4202 * If allocating a large folio, determine the biggest suitable order for
4203 * the VMA (e.g. it must not exceed the VMA's bounds, it must not
4204 * overlap with any populated PTEs, etc). We are not under the ptl here
4205 * so we will need to re-check that we are not overlapping any populated
4206 * PTEs once we have the lock.
4207 */
4208 order = uffd_wp ? 0 : max_anon_folio_order(vma);
4209 if (order > 0) {
4210 vmf->pte = pte_offset_map(vmf->pmd, vmf->address);
4211 order = calc_anon_folio_order_alloc(vmf, order);
4212 pte_unmap(vmf->pte);
4213 }
4214
4215 /* Allocate our own private folio. */
4216 if (unlikely(anon_vma_prepare(vma)))
4217 goto oom;
4218 folio = alloc_anon_folio(vma, vmf->address, order);
4219 if (!folio && order > 0) {
4220 order = 0;
4221 folio = alloc_anon_folio(vma, vmf->address, order);
4222 }
4223 if (!folio)
4224 goto oom;
4225
4226 pgcount = 1 << order;
4227 addr = ALIGN_DOWN(vmf->address, pgcount << PAGE_SHIFT);
4228
4229 if (mem_cgroup_charge(folio, vma->vm_mm, GFP_KERNEL))
4230 goto oom_free_page;
4231 folio_throttle_swaprate(folio, GFP_KERNEL);
4232
4233 /*
4234 * The memory barrier inside __folio_mark_uptodate makes sure that
4235 * preceding stores to the folio contents become visible before
4236 * the set_ptes() write.
4237 */
4238 __folio_mark_uptodate(folio);
4239
4240 entry = mk_pte(&folio->page, vma->vm_page_prot);
4241 entry = pte_sw_mkyoung(entry);
4242 if (vma->vm_flags & VM_WRITE)
4243 entry = pte_mkwrite(pte_mkdirty(entry));
4244
4245 vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd, addr, &vmf->ptl);
4246 if (vmf_pte_changed(vmf)) {
4247 update_mmu_tlb(vma, vmf->address, vmf->pte);
4248 goto release;
4249 } else if (order > 0 && check_ptes_none(vmf->pte, pgcount) != pgcount) {
4250 goto release;
4251 }
4252
4253 ret = check_stable_address_space(vma->vm_mm);
4254 if (ret)
4255 goto release;
4256
4257 /* Deliver the page fault to userland, check inside PT lock */
4258 if (userfaultfd_missing(vma)) {
4259 pte_unmap_unlock(vmf->pte, vmf->ptl);
4260 folio_put(folio);
4261 return handle_userfault(vmf, VM_UFFD_MISSING);
4262 }
4263
4264 folio_ref_add(folio, pgcount - 1);
4265 add_mm_counter(vma->vm_mm, MM_ANONPAGES, pgcount);
4266 folio_add_new_anon_rmap(folio, vma, addr);
4267 folio_add_lru_vma(folio, vma);
4268
4269 if (uffd_wp)
4270 entry = pte_mkuffd_wp(entry);
> 4271 set_ptes(vma->vm_mm, addr, vmf->pte, entry, pgcount);
4272
4273 /* No need to invalidate - it was non-present before */
> 4274 update_mmu_cache_range(vma, addr, vmf->pte, pgcount);
4275 unlock:
4276 pte_unmap_unlock(vmf->pte, vmf->ptl);
4277 return ret;
4278 release:
4279 folio_put(folio);
4280 goto unlock;
4281 oom_free_page:
4282 folio_put(folio);
4283 oom:
4284 return VM_FAULT_OOM;
4285 }
4286
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-03 16:04 UTC|newest]
Thread overview: 167+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 13:53 [PATCH v2 0/5] variable-order, large folios for anonymous memory Ryan Roberts
2023-07-03 13:53 ` Ryan Roberts
2023-07-03 13:53 ` [PATCH v2 1/5] mm: Non-pmd-mappable, large folios for folio_add_new_anon_rmap() Ryan Roberts
2023-07-03 13:53 ` Ryan Roberts
2023-07-03 19:05 ` Yu Zhao
2023-07-03 19:05 ` Yu Zhao
2023-07-04 2:13 ` Yin, Fengwei
2023-07-04 2:13 ` Yin, Fengwei
2023-07-04 11:19 ` Ryan Roberts
2023-07-04 11:19 ` Ryan Roberts
2023-07-04 2:14 ` Yin, Fengwei
2023-07-04 2:14 ` Yin, Fengwei
2023-07-03 13:53 ` [PATCH v2 2/5] mm: Allow deferred splitting of arbitrary large anon folios Ryan Roberts
2023-07-03 13:53 ` Ryan Roberts
2023-07-07 8:21 ` Huang, Ying
2023-07-07 8:21 ` Huang, Ying
2023-07-07 9:39 ` Ryan Roberts
2023-07-07 9:42 ` Ryan Roberts
2023-07-07 9:42 ` Ryan Roberts
2023-07-10 5:37 ` Huang, Ying
2023-07-10 5:37 ` Huang, Ying
2023-07-10 8:29 ` Ryan Roberts
2023-07-10 8:29 ` Ryan Roberts
2023-07-10 9:01 ` Huang, Ying
2023-07-10 9:01 ` Huang, Ying
2023-07-10 9:39 ` Ryan Roberts
2023-07-10 9:39 ` Ryan Roberts
2023-07-11 1:56 ` Huang, Ying
2023-07-11 1:56 ` Huang, Ying
2023-07-03 13:53 ` [PATCH v2 3/5] mm: Default implementation of arch_wants_pte_order() Ryan Roberts
2023-07-03 13:53 ` Ryan Roberts
2023-07-03 19:50 ` Yu Zhao
2023-07-03 19:50 ` Yu Zhao
2023-07-04 13:20 ` Ryan Roberts
2023-07-04 13:20 ` Ryan Roberts
2023-07-05 2:07 ` Yu Zhao
2023-07-05 2:07 ` Yu Zhao
2023-07-05 9:11 ` Ryan Roberts
2023-07-05 9:11 ` Ryan Roberts
2023-07-05 17:24 ` Yu Zhao
2023-07-05 17:24 ` Yu Zhao
2023-07-05 18:01 ` Ryan Roberts
2023-07-05 18:01 ` Ryan Roberts
2023-07-06 19:33 ` Matthew Wilcox
2023-07-06 19:33 ` Matthew Wilcox
2023-07-07 10:00 ` Ryan Roberts
2023-07-07 10:00 ` Ryan Roberts
2023-07-04 2:22 ` Yin, Fengwei
2023-07-04 2:22 ` Yin, Fengwei
2023-07-04 3:02 ` Yu Zhao
2023-07-04 3:02 ` Yu Zhao
2023-07-04 3:59 ` Yu Zhao
2023-07-04 3:59 ` Yu Zhao
2023-07-04 5:22 ` Yin, Fengwei
2023-07-04 5:22 ` Yin, Fengwei
2023-07-04 5:42 ` Yu Zhao
2023-07-04 5:42 ` Yu Zhao
2023-07-04 12:36 ` Ryan Roberts
2023-07-04 12:36 ` Ryan Roberts
2023-07-04 13:23 ` Ryan Roberts
2023-07-04 13:23 ` Ryan Roberts
2023-07-05 1:40 ` Yu Zhao
2023-07-05 1:40 ` Yu Zhao
2023-07-05 1:23 ` Yu Zhao
2023-07-05 1:23 ` Yu Zhao
2023-07-05 2:18 ` Yin Fengwei
2023-07-05 2:18 ` Yin Fengwei
2023-07-03 13:53 ` [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance Ryan Roberts
2023-07-03 13:53 ` Ryan Roberts
2023-07-03 15:51 ` kernel test robot
2023-07-03 15:51 ` kernel test robot
2023-07-03 16:01 ` kernel test robot [this message]
2023-07-03 16:01 ` kernel test robot
2023-07-04 1:35 ` Yu Zhao
2023-07-04 1:35 ` Yu Zhao
2023-07-04 14:08 ` Ryan Roberts
2023-07-04 14:08 ` Ryan Roberts
2023-07-04 23:47 ` Yu Zhao
2023-07-04 23:47 ` Yu Zhao
2023-07-04 3:45 ` Yin, Fengwei
2023-07-04 3:45 ` Yin, Fengwei
2023-07-04 14:20 ` Ryan Roberts
2023-07-04 14:20 ` Ryan Roberts
2023-07-04 23:35 ` Yin Fengwei
2023-07-04 23:57 ` Matthew Wilcox
2023-07-04 23:57 ` Matthew Wilcox
2023-07-05 9:54 ` Ryan Roberts
2023-07-05 9:54 ` Ryan Roberts
2023-07-05 12:08 ` Matthew Wilcox
2023-07-05 12:08 ` Matthew Wilcox
2023-07-07 8:01 ` Huang, Ying
2023-07-07 8:01 ` Huang, Ying
2023-07-07 9:52 ` Ryan Roberts
2023-07-07 9:52 ` Ryan Roberts
2023-07-07 11:29 ` David Hildenbrand
2023-07-07 11:29 ` David Hildenbrand
2023-07-07 13:57 ` Matthew Wilcox
2023-07-07 13:57 ` Matthew Wilcox
2023-07-07 14:07 ` David Hildenbrand
2023-07-07 14:07 ` David Hildenbrand
2023-07-07 15:13 ` Ryan Roberts
2023-07-07 15:13 ` Ryan Roberts
2023-07-07 16:06 ` David Hildenbrand
2023-07-07 16:06 ` David Hildenbrand
2023-07-07 16:22 ` Ryan Roberts
2023-07-07 16:22 ` Ryan Roberts
2023-07-07 19:06 ` David Hildenbrand
2023-07-07 19:06 ` David Hildenbrand
2023-07-10 8:41 ` Ryan Roberts
2023-07-10 8:41 ` Ryan Roberts
2023-07-10 3:03 ` Huang, Ying
2023-07-10 3:03 ` Huang, Ying
2023-07-10 8:55 ` Ryan Roberts
2023-07-10 8:55 ` Ryan Roberts
2023-07-10 9:18 ` Huang, Ying
2023-07-10 9:18 ` Huang, Ying
2023-07-10 9:25 ` Ryan Roberts
2023-07-10 9:25 ` Ryan Roberts
2023-07-11 0:48 ` Huang, Ying
2023-07-11 0:48 ` Huang, Ying
2023-07-10 2:49 ` Huang, Ying
2023-07-10 2:49 ` Huang, Ying
2023-07-03 13:53 ` [PATCH v2 5/5] arm64: mm: Override arch_wants_pte_order() Ryan Roberts
2023-07-03 13:53 ` Ryan Roberts
2023-07-03 20:02 ` Yu Zhao
2023-07-03 20:02 ` Yu Zhao
2023-07-04 2:18 ` [PATCH v2 0/5] variable-order, large folios for anonymous memory Yu Zhao
2023-07-04 2:18 ` Yu Zhao
2023-07-04 6:22 ` Yin, Fengwei
2023-07-04 6:22 ` Yin, Fengwei
2023-07-04 7:11 ` Yu Zhao
2023-07-04 7:11 ` Yu Zhao
2023-07-04 15:36 ` Ryan Roberts
2023-07-04 15:36 ` Ryan Roberts
2023-07-04 23:52 ` Yin Fengwei
2023-07-05 0:21 ` Yu Zhao
2023-07-05 0:21 ` Yu Zhao
2023-07-05 10:16 ` Ryan Roberts
2023-07-05 10:16 ` Ryan Roberts
2023-07-05 19:00 ` Yu Zhao
2023-07-05 19:00 ` Yu Zhao
2023-07-05 19:38 ` David Hildenbrand
2023-07-05 19:38 ` David Hildenbrand
2023-07-06 8:02 ` Ryan Roberts
2023-07-06 8:02 ` Ryan Roberts
2023-07-07 11:40 ` David Hildenbrand
2023-07-07 11:40 ` David Hildenbrand
2023-07-07 13:12 ` Matthew Wilcox
2023-07-07 13:12 ` Matthew Wilcox
2023-07-07 13:24 ` David Hildenbrand
2023-07-07 13:24 ` David Hildenbrand
2023-07-10 10:07 ` Ryan Roberts
2023-07-10 10:07 ` Ryan Roberts
2023-07-10 16:57 ` Matthew Wilcox
2023-07-10 16:57 ` Matthew Wilcox
2023-07-10 16:53 ` Zi Yan
2023-07-10 16:53 ` Zi Yan
2023-07-19 15:49 ` Ryan Roberts
2023-07-19 15:49 ` Ryan Roberts
2023-07-19 16:05 ` Zi Yan
2023-07-19 16:05 ` Zi Yan
2023-07-19 18:37 ` Ryan Roberts
2023-07-19 18:37 ` Ryan Roberts
2023-07-11 21:11 ` Luis Chamberlain
2023-07-11 21:11 ` Luis Chamberlain
2023-07-11 21:59 ` Matthew Wilcox
2023-07-11 21:59 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202307032330.TguyNttt-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=fengwei.yin@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.