From: kernel test robot <lkp@intel.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
ryan.roberts@arm.com, Matthew Wilcox <willy@infradead.org>,
David Hildenbrand <david@redhat.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH] mm: memory: move mem_cgroup_charge() into alloc_anon_folio()
Date: Wed, 17 Jan 2024 05:26:58 +0800 [thread overview]
Message-ID: <202401170535.2TfJ7u74-lkp@intel.com> (raw)
In-Reply-To: <20240116071302.2282230-1-wangkefeng.wang@huawei.com>
Hi Kefeng,
kernel test robot noticed the following build errors:
[auto build test ERROR on akpm-mm/mm-everything]
url: https://github.com/intel-lab-lkp/linux/commits/Kefeng-Wang/mm-memory-move-mem_cgroup_charge-into-alloc_anon_folio/20240116-151640
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20240116071302.2282230-1-wangkefeng.wang%40huawei.com
patch subject: [PATCH] mm: memory: move mem_cgroup_charge() into alloc_anon_folio()
config: x86_64-allnoconfig (https://download.01.org/0day-ci/archive/20240117/202401170535.2TfJ7u74-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240117/202401170535.2TfJ7u74-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/202401170535.2TfJ7u74-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
mm/memory.c: In function 'alloc_anon_folio':
>> mm/memory.c:4223:31: error: 'vma' undeclared (first use in this function); did you mean 'vmf'?
4223 | return folio_prealloc(vma->vm_mm, vma, vmf->address, true);
| ^~~
| vmf
mm/memory.c:4223:31: note: each undeclared identifier is reported only once for each function it appears in
>> mm/memory.c:4224:1: warning: control reaches end of non-void function [-Wreturn-type]
4224 | }
| ^
vim +4223 mm/memory.c
4153
4154 static struct folio *alloc_anon_folio(struct vm_fault *vmf)
4155 {
4156 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
4157 struct vm_area_struct *vma = vmf->vma;
4158 unsigned long orders;
4159 struct folio *folio;
4160 unsigned long addr;
4161 pte_t *pte;
4162 gfp_t gfp;
4163 int order;
4164
4165 /*
4166 * If uffd is active for the vma we need per-page fault fidelity to
4167 * maintain the uffd semantics.
4168 */
4169 if (unlikely(userfaultfd_armed(vma)))
4170 goto fallback;
4171
4172 /*
4173 * Get a list of all the (large) orders below PMD_ORDER that are enabled
4174 * for this vma. Then filter out the orders that can't be allocated over
4175 * the faulting address and still be fully contained in the vma.
4176 */
4177 orders = thp_vma_allowable_orders(vma, vma->vm_flags, false, true, true,
4178 BIT(PMD_ORDER) - 1);
4179 orders = thp_vma_suitable_orders(vma, vmf->address, orders);
4180
4181 if (!orders)
4182 goto fallback;
4183
4184 pte = pte_offset_map(vmf->pmd, vmf->address & PMD_MASK);
4185 if (!pte)
4186 return ERR_PTR(-EAGAIN);
4187
4188 /*
4189 * Find the highest order where the aligned range is completely
4190 * pte_none(). Note that all remaining orders will be completely
4191 * pte_none().
4192 */
4193 order = highest_order(orders);
4194 while (orders) {
4195 addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
4196 if (pte_range_none(pte + pte_index(addr), 1 << order))
4197 break;
4198 order = next_order(&orders, order);
4199 }
4200
4201 pte_unmap(pte);
4202
4203 /* Try allocating the highest of the remaining orders. */
4204 gfp = vma_thp_gfp_mask(vma);
4205 while (orders) {
4206 addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
4207 folio = vma_alloc_folio(gfp, order, vma, addr, true);
4208 if (folio) {
4209 if (mem_cgroup_charge(folio, vma->vm_mm, gfp)) {
4210 folio_put(folio);
4211 goto next;
4212 }
4213 folio_throttle_swaprate(folio, gfp);
4214 clear_huge_page(&folio->page, vmf->address, 1 << order);
4215 return folio;
4216 }
4217 next:
4218 order = next_order(&orders, order);
4219 }
4220
4221 fallback:
4222 #endif
> 4223 return folio_prealloc(vma->vm_mm, vma, vmf->address, true);
> 4224 }
4225
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2024-01-16 21:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 7:13 [PATCH] mm: memory: move mem_cgroup_charge() into alloc_anon_folio() Kefeng Wang
2024-01-16 14:35 ` Ryan Roberts
2024-01-16 14:51 ` Matthew Wilcox
2024-01-16 15:07 ` Ryan Roberts
2024-01-17 1:34 ` Kefeng Wang
2024-01-16 21:26 ` kernel test robot [this message]
2024-01-17 1:02 ` Kefeng Wang
2024-01-16 23:41 ` kernel test robot
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=202401170535.2TfJ7u74-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=ryan.roberts@arm.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
/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.