* Re: [PATCH v5 1/2] btrfs: always uses root memcgroup for filemap_add_folio()
[not found] <d408a1b35307101e82a6845e26af4a122c8e5a25.1721363035.git.wqu@suse.com>
@ 2024-07-19 15:42 ` kernel test robot
0 siblings, 0 replies; only message in thread
From: kernel test robot @ 2024-07-19 15:42 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: llvm, oe-kbuild-all, Michal Hocko, Vlastimil Babka
Hi Qu,
kernel test robot noticed the following build errors:
[auto build test ERROR on kdave/for-next]
[also build test ERROR on linus/master v6.10 next-20240719]
[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/Qu-Wenruo/btrfs-always-uses-root-memcgroup-for-filemap_add_folio/20240719-125131
base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
patch link: https://lore.kernel.org/r/d408a1b35307101e82a6845e26af4a122c8e5a25.1721363035.git.wqu%40suse.com
patch subject: [PATCH v5 1/2] btrfs: always uses root memcgroup for filemap_add_folio()
config: x86_64-buildonly-randconfig-002-20240719 (https://download.01.org/0day-ci/archive/20240719/202407192346.BjAEmrYl-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240719/202407192346.BjAEmrYl-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/202407192346.BjAEmrYl-lkp@intel.com/
All errors (new ones prefixed by >>):
>> fs/btrfs/extent_io.c:2992:31: error: use of undeclared identifier 'root_mem_cgroup'; did you mean 'parent_mem_cgroup'?
2992 | old_memcg = set_active_memcg(root_mem_cgroup);
| ^~~~~~~~~~~~~~~
| parent_mem_cgroup
include/linux/memcontrol.h:1288:34: note: 'parent_mem_cgroup' declared here
1288 | static inline struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *memcg)
| ^
1 error generated.
vim +2992 fs/btrfs/extent_io.c
2971
2972 struct btrfs_fs_info *fs_info = eb->fs_info;
2973 struct address_space *mapping = fs_info->btree_inode->i_mapping;
2974 struct mem_cgroup *old_memcg;
2975 const unsigned long index = eb->start >> PAGE_SHIFT;
2976 struct folio *existing_folio = NULL;
2977 int ret;
2978
2979 ASSERT(found_eb_ret);
2980
2981 /* Caller should ensure the folio exists. */
2982 ASSERT(eb->folios[i]);
2983
2984 retry:
2985 /*
2986 * Btree inode is a btrfs internal inode, and not exposed to any
2987 * user.
2988 * Furthermore we do not want any cgroup limits on this inode.
2989 * So we always use root_mem_cgroup as our active memcg when attaching
2990 * the folios.
2991 */
> 2992 old_memcg = set_active_memcg(root_mem_cgroup);
2993 ret = filemap_add_folio(mapping, eb->folios[i], index + i,
2994 GFP_NOFS | __GFP_NOFAIL);
2995 set_active_memcg(old_memcg);
2996 if (!ret)
2997 goto finish;
2998
2999 existing_folio = filemap_lock_folio(mapping, index + i);
3000 /* The page cache only exists for a very short time, just retry. */
3001 if (IS_ERR(existing_folio)) {
3002 existing_folio = NULL;
3003 goto retry;
3004 }
3005
3006 /* For now, we should only have single-page folios for btree inode. */
3007 ASSERT(folio_nr_pages(existing_folio) == 1);
3008
3009 if (folio_size(existing_folio) != eb->folio_size) {
3010 folio_unlock(existing_folio);
3011 folio_put(existing_folio);
3012 return -EAGAIN;
3013 }
3014
3015 finish:
3016 spin_lock(&mapping->i_private_lock);
3017 if (existing_folio && fs_info->nodesize < PAGE_SIZE) {
3018 /* We're going to reuse the existing page, can drop our folio now. */
3019 __free_page(folio_page(eb->folios[i], 0));
3020 eb->folios[i] = existing_folio;
3021 } else if (existing_folio) {
3022 struct extent_buffer *existing_eb;
3023
3024 existing_eb = grab_extent_buffer(fs_info,
3025 folio_page(existing_folio, 0));
3026 if (existing_eb) {
3027 /* The extent buffer still exists, we can use it directly. */
3028 *found_eb_ret = existing_eb;
3029 spin_unlock(&mapping->i_private_lock);
3030 folio_unlock(existing_folio);
3031 folio_put(existing_folio);
3032 return 1;
3033 }
3034 /* The extent buffer no longer exists, we can reuse the folio. */
3035 __free_page(folio_page(eb->folios[i], 0));
3036 eb->folios[i] = existing_folio;
3037 }
3038 eb->folio_size = folio_size(eb->folios[i]);
3039 eb->folio_shift = folio_shift(eb->folios[i]);
3040 /* Should not fail, as we have preallocated the memory. */
3041 ret = attach_extent_buffer_folio(eb, eb->folios[i], prealloc);
3042 ASSERT(!ret);
3043 /*
3044 * To inform we have an extra eb under allocation, so that
3045 * detach_extent_buffer_page() won't release the folio private when the
3046 * eb hasn't been inserted into radix tree yet.
3047 *
3048 * The ref will be decreased when the eb releases the page, in
3049 * detach_extent_buffer_page(). Thus needs no special handling in the
3050 * error path.
3051 */
3052 btrfs_folio_inc_eb_refs(fs_info, eb->folios[i]);
3053 spin_unlock(&mapping->i_private_lock);
3054 return 0;
3055 }
3056
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2024-07-19 15:42 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <d408a1b35307101e82a6845e26af4a122c8e5a25.1721363035.git.wqu@suse.com>
2024-07-19 15:42 ` [PATCH v5 1/2] btrfs: always uses root memcgroup for filemap_add_folio() kernel test robot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox