From: kernel test robot <lkp@intel.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: oe-kbuild-all@lists.linux.dev,
Linux Memory Management List <linux-mm@kvack.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Christoph Hellwig <hch@lst.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
cgroups@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] vmalloc: Move memcg logic into memcg code
Date: Wed, 11 Dec 2024 18:11:06 +0800 [thread overview]
Message-ID: <202412111725.koF7jNeD-lkp@intel.com> (raw)
In-Reply-To: <20241210193035.2667005-1-willy@infradead.org>
Hi Matthew,
kernel test robot noticed the following build warnings:
[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on linus/master v6.13-rc2 next-20241211]
[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/Matthew-Wilcox-Oracle/vmalloc-Move-memcg-logic-into-memcg-code/20241211-033214
base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link: https://lore.kernel.org/r/20241210193035.2667005-1-willy%40infradead.org
patch subject: [PATCH] vmalloc: Move memcg logic into memcg code
config: m68k-randconfig-r112-20241211 (https://download.01.org/0day-ci/archive/20241211/202412111725.koF7jNeD-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 14.2.0
reproduce: (https://download.01.org/0day-ci/archive/20241211/202412111725.koF7jNeD-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/202412111725.koF7jNeD-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> mm/vmalloc.c:3675:55: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned int nr_pages @@ got restricted gfp_t [assigned] [usertype] gfp_mask @@
mm/vmalloc.c:3675:55: sparse: expected unsigned int nr_pages
mm/vmalloc.c:3675:55: sparse: got restricted gfp_t [assigned] [usertype] gfp_mask
>> mm/vmalloc.c:3675:69: sparse: sparse: incorrect type in argument 3 (different base types) @@ expected restricted gfp_t [usertype] gfp @@ got unsigned int nr_pages @@
mm/vmalloc.c:3675:69: sparse: expected restricted gfp_t [usertype] gfp
mm/vmalloc.c:3675:69: sparse: got unsigned int nr_pages
mm/vmalloc.c:180:74: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:231:74: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:282:74: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:384:46: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:407:46: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:427:46: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:531:46: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:549:46: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:567:46: sparse: sparse: self-comparison always evaluates to false
mm/vmalloc.c:1054:25: sparse: sparse: context imbalance in 'find_vmap_area_exceed_addr_lock' - wrong count at exit
mm/vmalloc.c:4426:28: sparse: sparse: context imbalance in 'vread_iter' - unexpected unlock
vim +3675 mm/vmalloc.c
3623
3624 static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
3625 pgprot_t prot, unsigned int page_shift,
3626 int node)
3627 {
3628 const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
3629 bool nofail = gfp_mask & __GFP_NOFAIL;
3630 unsigned long addr = (unsigned long)area->addr;
3631 unsigned long size = get_vm_area_size(area);
3632 unsigned long array_size;
3633 unsigned int nr_small_pages = size >> PAGE_SHIFT;
3634 unsigned int page_order;
3635 unsigned int flags;
3636 int ret;
3637
3638 array_size = (unsigned long)nr_small_pages * sizeof(struct page *);
3639
3640 if (!(gfp_mask & (GFP_DMA | GFP_DMA32)))
3641 gfp_mask |= __GFP_HIGHMEM;
3642
3643 /* Please note that the recursion is strictly bounded. */
3644 if (array_size > PAGE_SIZE) {
3645 area->pages = __vmalloc_node_noprof(array_size, 1, nested_gfp, node,
3646 area->caller);
3647 } else {
3648 area->pages = kmalloc_node_noprof(array_size, nested_gfp, node);
3649 }
3650
3651 if (!area->pages) {
3652 warn_alloc(gfp_mask, NULL,
3653 "vmalloc error: size %lu, failed to allocated page array size %lu",
3654 nr_small_pages * PAGE_SIZE, array_size);
3655 free_vm_area(area);
3656 return NULL;
3657 }
3658
3659 set_vm_area_page_order(area, page_shift - PAGE_SHIFT);
3660 page_order = vm_area_page_order(area);
3661
3662 /*
3663 * High-order nofail allocations are really expensive and
3664 * potentially dangerous (pre-mature OOM, disruptive reclaim
3665 * and compaction etc.
3666 *
3667 * Please note, the __vmalloc_node_range_noprof() falls-back
3668 * to order-0 pages if high-order attempt is unsuccessful.
3669 */
3670 area->nr_pages = vm_area_alloc_pages((page_order ?
3671 gfp_mask & ~__GFP_NOFAIL : gfp_mask) | __GFP_NOWARN,
3672 node, page_order, nr_small_pages, area->pages);
3673
3674 atomic_long_add(area->nr_pages, &nr_vmalloc_pages);
> 3675 ret = obj_cgroup_charge_vmalloc(&area->objcg, gfp_mask, area->nr_pages);
3676 if (ret)
3677 goto fail;
3678
3679 /*
3680 * If not enough pages were obtained to accomplish an
3681 * allocation request, free them via vfree() if any.
3682 */
3683 if (area->nr_pages != nr_small_pages) {
3684 /*
3685 * vm_area_alloc_pages() can fail due to insufficient memory but
3686 * also:-
3687 *
3688 * - a pending fatal signal
3689 * - insufficient huge page-order pages
3690 *
3691 * Since we always retry allocations at order-0 in the huge page
3692 * case a warning for either is spurious.
3693 */
3694 if (!fatal_signal_pending(current) && page_order == 0)
3695 warn_alloc(gfp_mask, NULL,
3696 "vmalloc error: size %lu, failed to allocate pages",
3697 area->nr_pages * PAGE_SIZE);
3698 goto fail;
3699 }
3700
3701 /*
3702 * page tables allocations ignore external gfp mask, enforce it
3703 * by the scope API
3704 */
3705 if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
3706 flags = memalloc_nofs_save();
3707 else if ((gfp_mask & (__GFP_FS | __GFP_IO)) == 0)
3708 flags = memalloc_noio_save();
3709
3710 do {
3711 ret = vmap_pages_range(addr, addr + size, prot, area->pages,
3712 page_shift);
3713 if (nofail && (ret < 0))
3714 schedule_timeout_uninterruptible(1);
3715 } while (nofail && (ret < 0));
3716
3717 if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
3718 memalloc_nofs_restore(flags);
3719 else if ((gfp_mask & (__GFP_FS | __GFP_IO)) == 0)
3720 memalloc_noio_restore(flags);
3721
3722 if (ret < 0) {
3723 warn_alloc(gfp_mask, NULL,
3724 "vmalloc error: size %lu, failed to map pages",
3725 area->nr_pages * PAGE_SIZE);
3726 goto fail;
3727 }
3728
3729 return area->addr;
3730
3731 fail:
3732 vfree(area->addr);
3733 return NULL;
3734 }
3735
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2024-12-11 10:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 19:30 [PATCH] vmalloc: Move memcg logic into memcg code Matthew Wilcox (Oracle)
2024-12-10 20:05 ` Matthew Wilcox
2024-12-11 10:11 ` kernel test robot [this message]
2024-12-11 11:44 ` Balbir Singh
2024-12-11 19:14 ` kernel test robot
2024-12-11 23:26 ` 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=202412111725.koF7jNeD-lkp@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hch@lst.de \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--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.