Re: [akpm-mm:mm-unstable 169/175] ld.lld: error: undefined symbol: shmem_uncharge

[Balbir Singh <balbirs@nvidia.com>]

On 11/20/25 09:35, Balbir Singh wrote:
> On 11/20/25 08:26, kernel test robot wrote:
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable
>> head:   102494e6776f316b6cf2924976681d790f278cf1
>> commit: 9a655bd0773b41af6d8515502de102544f3ec4c1 [169/175] mm-huge_memoryc-introduce-folio_split_unmapped-v2
>> config: i386-buildonly-randconfig-002-20251119 (https://download.01.org/0day-ci/archive/20251120/202511200534.o4hsMNEt-lkp@intel.com/config)
>> compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251120/202511200534.o4hsMNEt-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/202511200534.o4hsMNEt-lkp@intel.com/
>>
>> All errors (new ones prefixed by >>):
>>
>>>> ld.lld: error: undefined symbol: shmem_uncharge
>>    >>> referenced by huge_memory.c:4053 (mm/huge_memory.c:4053)
>>    >>>               mm/huge_memory.o:(__folio_split) in archive vmlinux.a
>>
> 
> On first glance it seems a bit strange since I did not change the use of shmem_uncharge, the
> computation of nr_shmem_dropped did change. I see the config has CONFIG_SHMEM not set, I wonder
> why this triggers with my changes only.
> 
> I've tried reproducing with clang-21 and the provided configuration without any success.
> My command line was CC=clang-21 and LD=ld.lld-21, but I am going to try with the script mentioned
> 

I've done more testing and followed the instructions provided to reproduce the problem
with the provided config (CONFIG_SHMEM=n)

1. I cannot reproduce the issue with COMPILER=clang-21
2. I can reproduce the issue with COMPILER=clang-20

Turns out the compiler does not like my change because it can no longer predict if nr_shmem_dropped
is 0 and thus optimize out the call to shmem_uncharge(), which it did prior to the change

Looks like I need to use

       if (shmem_mapping(mapping) && nr_shmem_dropped)
                shmem_uncharge(mapping->host, nr_shmem_dropped);


Fun times :)
Balbir