Hi Qi,

kernel test robot noticed the following build errors:

[auto build test ERROR on deller-parisc/for-next]
[also build test ERROR on uml/next tip/x86/core akpm-mm/mm-everything 
linus/master v6.18-rc5 next-20251114]
[cannot apply to uml/fixes vgupta-arc/for-next vgupta-arc/for-curr]
[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/Qi-Zheng/alpha-mm-enable-MMU_GATHER_RCU_TABLE_FREE/20251114-191543
base:   https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git 
for-next
patch link:    
https://lore.kernel.org/r/0a4d1e6f0bf299cafd1fc624f965bd1ca542cea8.1763117269.git.zhengqi.arch%40bytedance.com
patch subject: [PATCH 7/7] mm: make PT_RECLAIM depend on 
MMU_GATHER_RCU_TABLE_FREE && 64BIT
config: arm64-randconfig-004-20251115 
(https://download.01.org/0day-ci/archive/20251115/[email protected]/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20251115/[email protected]/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 <[email protected]>
| Closes: 
https://lore.kernel.org/oe-kbuild-all/[email protected]/

All errors (new ones prefixed by >>):

   In file included from mm/pt_reclaim.c:3:
   mm/pt_reclaim.c: In function 'free_pte':
>> include/asm-generic/tlb.h:731:3: error: implicit declaration of function 
>> '__pte_free_tlb'; did you mean 'pte_free_tlb'? 
>> [-Werror=implicit-function-declaration]
      __pte_free_tlb(tlb, ptep, address);  \
      ^~~~~~~~~~~~~~
   mm/pt_reclaim.c:31:2: note: in expansion of macro 'pte_free_tlb'
     pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
     ^~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +731 include/asm-generic/tlb.h

a00cc7d9dd93d6 Matthew Wilcox         2017-02-24  701  
a00cc7d9dd93d6 Matthew Wilcox         2017-02-24  702  #define 
tlb_remove_pud_tlb_entry(tlb, pudp, address)                     \
a00cc7d9dd93d6 Matthew Wilcox         2017-02-24  703   do {                    
                                        \
2631ed00b04988 Peter Zijlstra (Intel  2020-06-25  704)          
tlb_flush_pud_range(tlb, address, HPAGE_PUD_SIZE);      \
a00cc7d9dd93d6 Matthew Wilcox         2017-02-24  705           
__tlb_remove_pud_tlb_entry(tlb, pudp, address);         \
a00cc7d9dd93d6 Matthew Wilcox         2017-02-24  706   } while (0)
a00cc7d9dd93d6 Matthew Wilcox         2017-02-24  707  
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  708  /*
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  709   * For things like page 
tables caches (ie caching addresses "inside" the
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  710   * page tables, like x86 
does), for legacy reasons, flushing an
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  711   * individual page had 
better flush the page table caches behind it. This
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  712   * is definitely how x86 
works, for example. And if you have an
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  713   * architected 
non-legacy page table cache (which I'm not aware of
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  714   * anybody actually 
doing), you're going to have some architecturally
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  715   * explicit flushing for 
that, likely *separate* from a regular TLB entry
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  716   * flush, and thus you'd 
need more than just some range expansion..
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  717   *
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  718   * So if we ever find an 
architecture
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  719   * that would want 
something that odd, I think it is up to that
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  720   * architecture to do 
its own odd thing, not cause pain for others
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  721   * 
http://lkml.kernel.org/r/ca+55afzbggoxtnxqeng5d_mrodnambe5y+urs+phr67nupm...@mail.gmail.com
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  722   *
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  723   * For now w.r.t page 
table cache, mark the range_size as PAGE_SIZE
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  724   */
b5bc66b7131087 Aneesh Kumar K.V       2016-12-12  725  
a90744bac57c3c Nicholas Piggin        2018-07-13  726  #ifndef pte_free_tlb
9e1b32caa525cb Benjamin Herrenschmidt 2009-07-22  727  #define 
pte_free_tlb(tlb, ptep, address)                 \
^1da177e4c3f41 Linus Torvalds         2005-04-16  728   do {                    
                                \
2631ed00b04988 Peter Zijlstra (Intel  2020-06-25  729)          
tlb_flush_pmd_range(tlb, address, PAGE_SIZE);   \
22a61c3c4f1379 Peter Zijlstra         2018-08-23  730           
tlb->freed_tables = 1;                          \
9e1b32caa525cb Benjamin Herrenschmidt 2009-07-22 @731           
__pte_free_tlb(tlb, ptep, address);             \
^1da177e4c3f41 Linus Torvalds         2005-04-16  732   } while (0)
a90744bac57c3c Nicholas Piggin        2018-07-13  733  #endif
^1da177e4c3f41 Linus Torvalds         2005-04-16  734  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Reply via email to