Hi Boris, kernel test robot noticed the following build warnings: [auto build test WARNING on kdave/for-next] [also build test WARNING on v6.16] [cannot apply to akpm-mm/mm-everything linus/master next-20250806] [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/Boris-Burkov/mm-filemap-add-filemap_add_folio_nocharge/20250806-130147 base: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next patch link: https://lore.kernel.org/r/eae30d630ba07de8966d09a3e1700f53715980c2.1754438418.git.boris%40bur.io patch subject: [PATCH 3/3] mm: add vmstat for cgroup uncharged pages config: i386-buildonly-randconfig-003-20250807 (https://download.01.org/0day-ci/archive/20250807/202508070434.6EpRsRF3-lkp@xxxxxxxxx/config) compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250807/202508070434.6EpRsRF3-lkp@xxxxxxxxx/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@xxxxxxxxx> | Closes: https://lore.kernel.org/oe-kbuild-all/202508070434.6EpRsRF3-lkp@xxxxxxxxx/ All warnings (new ones prefixed by >>): mm/filemap.c: In function 'filemap_unaccount_folio': mm/filemap.c:209:9: error: implicit declaration of function 'filemap_mod_uncharged_vmstat'; did you mean 'filemap_mod_uncharged_cgroup_vmstat'? [-Werror=implicit-function-declaration] 209 | filemap_mod_uncharged_vmstat(folio, -1); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | filemap_mod_uncharged_cgroup_vmstat mm/filemap.c: At top level: >> mm/filemap.c:158:13: warning: 'filemap_mod_uncharged_cgroup_vmstat' defined but not used [-Wunused-function] 158 | static void filemap_mod_uncharged_cgroup_vmstat(struct folio *folio, int sign) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors vim +/filemap_mod_uncharged_cgroup_vmstat +158 mm/filemap.c 148 149 #ifdef CONFIG_MEMCG 150 static void filemap_mod_uncharged_vmstat(struct folio *folio, int sign) 151 { 152 long nr = folio_nr_pages(folio) * sign; 153 154 if (!folio_memcg(folio)) 155 __lruvec_stat_mod_folio(folio, NR_UNCHARGED_FILE_PAGES, nr); 156 } 157 #else > 158 static void filemap_mod_uncharged_cgroup_vmstat(struct folio *folio, int sign) 159 { 160 return; 161 } 162 #endif 163 164 165 static void filemap_unaccount_folio(struct address_space *mapping, 166 struct folio *folio) 167 { 168 long nr; 169 170 VM_BUG_ON_FOLIO(folio_mapped(folio), folio); 171 if (!IS_ENABLED(CONFIG_DEBUG_VM) && unlikely(folio_mapped(folio))) { 172 pr_alert("BUG: Bad page cache in process %s pfn:%05lx\n", 173 current->comm, folio_pfn(folio)); 174 dump_page(&folio->page, "still mapped when deleted"); 175 dump_stack(); 176 add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); 177 178 if (mapping_exiting(mapping) && !folio_test_large(folio)) { 179 int mapcount = folio_mapcount(folio); 180 181 if (folio_ref_count(folio) >= mapcount + 2) { 182 /* 183 * All vmas have already been torn down, so it's 184 * a good bet that actually the page is unmapped 185 * and we'd rather not leak it: if we're wrong, 186 * another bad page check should catch it later. 187 */ 188 atomic_set(&folio->_mapcount, -1); 189 folio_ref_sub(folio, mapcount); 190 } 191 } 192 } 193 194 /* hugetlb folios do not participate in page cache accounting. */ 195 if (folio_test_hugetlb(folio)) 196 return; 197 198 nr = folio_nr_pages(folio); 199 200 __lruvec_stat_mod_folio(folio, NR_FILE_PAGES, -nr); 201 if (folio_test_swapbacked(folio)) { 202 __lruvec_stat_mod_folio(folio, NR_SHMEM, -nr); 203 if (folio_test_pmd_mappable(folio)) 204 __lruvec_stat_mod_folio(folio, NR_SHMEM_THPS, -nr); 205 } else if (folio_test_pmd_mappable(folio)) { 206 __lruvec_stat_mod_folio(folio, NR_FILE_THPS, -nr); 207 filemap_nr_thps_dec(mapping); 208 } > 209 filemap_mod_uncharged_vmstat(folio, -1); 210 211 /* 212 * At this point folio must be either written or cleaned by 213 * truncate. Dirty folio here signals a bug and loss of 214 * unwritten data - on ordinary filesystems. 215 * 216 * But it's harmless on in-memory filesystems like tmpfs; and can 217 * occur when a driver which did get_user_pages() sets page dirty 218 * before putting it, while the inode is being finally evicted. 219 * 220 * Below fixes dirty accounting after removing the folio entirely 221 * but leaves the dirty flag set: it has no effect for truncated 222 * folio and anyway will be cleared before returning folio to 223 * buddy allocator. 224 */ 225 if (WARN_ON_ONCE(folio_test_dirty(folio) && 226 mapping_can_writeback(mapping))) 227 folio_account_cleaned(folio, inode_to_wb(mapping->host)); 228 } 229 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
