Re: [PATCH v2] mm/swapops,rmap: remove should-never-be-compiled codes.

["David Hildenbrand (Red Hat)" <david@kernel.org>]

> 
> Hello David,
> 
> folio_inc_return_large_mapcount and folio_dec_return_large_mapcount
> are only used when CONFIG_NO_PAGE_MAPCOUNT is defined.

It's conceptually wrong to leak CONFIG_NO_PAGE_MAPCOUNT in something that is
CONFIG_MM_ID material at this point.

> 
>>
>>
>> So if the following makes compilers happy, fine with me:
> 
> Apart from the solution as below, I can't think of any other ways. Do
> you have any good ideas?

Leave the code alone.

What we *could* do is

diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index daa92a58585d9..ae495c225717a 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -354,11 +354,8 @@ static inline void folio_add_large_mapcount(struct folio *folio,
         atomic_add(diff, &folio->_large_mapcount);
  }
  
-static inline int folio_add_return_large_mapcount(struct folio *folio,
-               int diff, struct vm_area_struct *vma)
-{
-       BUILD_BUG();
-}
+int folio_add_return_large_mapcount(struct folio *folio,
+               int diff, struct vm_area_struct *vma);
  
  static inline void folio_sub_large_mapcount(struct folio *folio,
                 int diff, struct vm_area_struct *vma)
@@ -366,11 +363,8 @@ static inline void folio_sub_large_mapcount(struct folio *folio,
         atomic_sub(diff, &folio->_large_mapcount);
  }
  
-static inline int folio_sub_return_large_mapcount(struct folio *folio,
-               int diff, struct vm_area_struct *vma)
-{
-       BUILD_BUG();
-}
+int folio_sub_return_large_mapcount(struct folio *folio,
+               int diff, struct vm_area_struct *vma);
  #endif /* CONFIG_MM_ID */
  
  #define folio_inc_large_mapcount(folio, vma) \


But then, I have patches here in the works that actually fill these functions
with life.

So leave the code alone; I'm sure that is something with more added value
to be done in the kernel :)

-- 
Cheers

David