Re: [PATCH v4 24/31] mm: memcontrol: prepare for reparenting LRU pages for lruvec lock

[Shakeel Butt <shakeel.butt@linux.dev>]

On Fri, Feb 06, 2026 at 02:13:32PM +0800, Qi Zheng wrote:
> 
> 
> On 2/5/26 11:02 PM, kernel test robot wrote:
> > Hi Qi,
> > 
> > kernel test robot noticed the following build errors:
> > 
> > [auto build test ERROR on next-20260204]
> > [cannot apply to akpm-mm/mm-everything brauner-vfs/vfs.all trace/for-next tj-cgroup/for-next linus/master dennis-percpu/for-next v6.19-rc8 v6.19-rc7 v6.19-rc6 v6.19-rc8]
> > [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/mm-memcontrol-remove-dead-code-of-checking-parent-memory-cgroup/20260205-170812
> > base:   next-20260204
> > patch link:    https://lore.kernel.org/r/e27edb311dda624751cb41860237f290de8c16ae.1770279888.git.zhengqi.arch%40bytedance.com
> > patch subject: [PATCH v4 24/31] mm: memcontrol: prepare for reparenting LRU pages for lruvec lock
> > config: nios2-allnoconfig (https://download.01.org/0day-ci/archive/20260205/202602052203.U8hxsh2N-lkp@intel.com/config)
> > compiler: nios2-linux-gcc (GCC) 11.5.0
> > reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260205/202602052203.U8hxsh2N-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/202602052203.U8hxsh2N-lkp@intel.com/
> > 
> > All errors (new ones prefixed by >>):
> > 
> >     nios2-linux-ld: mm/swap.o: in function `__page_cache_release.part.0':
> >     swap.c:(.text+0x4c): undefined reference to `lruvec_unlock_irqrestore'
> > > > swap.c:(.text+0x4c): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irqrestore'
> >     nios2-linux-ld: mm/swap.o: in function `__folio_put':
> >     swap.c:(.text+0x2ac): undefined reference to `lruvec_unlock_irqrestore'
> >     swap.c:(.text+0x2ac): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irqrestore'
> >     nios2-linux-ld: mm/swap.o: in function `folios_put_refs':
> >     swap.c:(.text+0x384): undefined reference to `lruvec_unlock_irqrestore'
> >     swap.c:(.text+0x384): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irqrestore'
> >     nios2-linux-ld: mm/swap.o: in function `folio_batch_move_lru':
> >     swap.c:(.text+0x4ac): undefined reference to `lruvec_unlock_irqrestore'
> >     swap.c:(.text+0x4ac): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irqrestore'
> > > > nios2-linux-ld: swap.c:(.text+0x50c): undefined reference to `lruvec_unlock_irqrestore'
> >     swap.c:(.text+0x50c): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irqrestore'
> >     nios2-linux-ld: mm/swap.o: in function `folio_activate':
> >     swap.c:(.text+0x21d8): undefined reference to `lruvec_unlock_irq'
> > > > swap.c:(.text+0x21d8): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irq'
> >     nios2-linux-ld: mm/vmscan.o: in function `move_folios_to_lru':
> >     vmscan.c:(.text+0xa4c): undefined reference to `lruvec_unlock_irq'
> > > > vmscan.c:(.text+0xa4c): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irq'
> > > > nios2-linux-ld: vmscan.c:(.text+0xaa4): undefined reference to `lruvec_unlock_irq'
> >     vmscan.c:(.text+0xaa4): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irq'
> >     nios2-linux-ld: vmscan.c:(.text+0xcac): undefined reference to `lruvec_unlock_irq'
> >     vmscan.c:(.text+0xcac): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irq'
> >     nios2-linux-ld: vmscan.c:(.text+0xd8c): undefined reference to `lruvec_unlock_irq'
> >     vmscan.c:(.text+0xd8c): relocation truncated to fit: R_NIOS2_CALL26 against `lruvec_unlock_irq'
> >     nios2-linux-ld: mm/vmscan.o: in function `shrink_active_list':
> >     vmscan.c:(.text+0x11e0): undefined reference to `lruvec_lock_irq'
> >     vmscan.c:(.text+0x11e0): additional relocation overflows omitted from the output
> >     nios2-linux-ld: vmscan.c:(.text+0x12a0): undefined reference to `lruvec_unlock_irq'
> > > > nios2-linux-ld: vmscan.c:(.text+0x144c): undefined reference to `lruvec_lock_irq'
> >     nios2-linux-ld: mm/vmscan.o: in function `check_move_unevictable_folios':
> >     vmscan.c:(.text+0x15d4): undefined reference to `lruvec_unlock_irq'
> >     nios2-linux-ld: vmscan.c:(.text+0x1958): undefined reference to `lruvec_unlock_irq'
> >     nios2-linux-ld: mm/vmscan.o: in function `shrink_inactive_list':
> >     vmscan.c:(.text+0x2f8c): undefined reference to `lruvec_lock_irq'
> >     nios2-linux-ld: vmscan.c:(.text+0x307c): undefined reference to `lruvec_unlock_irq'
> >     nios2-linux-ld: vmscan.c:(.text+0x31dc): undefined reference to `lruvec_lock_irq'
> >     nios2-linux-ld: mm/vmscan.o: in function `folio_isolate_lru':
> >     vmscan.c:(.text+0x48a4): undefined reference to `lruvec_unlock_irq'
> >     nios2-linux-ld: mm/mlock.o: in function `__munlock_folio':
> >     mlock.c:(.text+0x968): undefined reference to `lruvec_unlock_irq'
> >     nios2-linux-ld: mm/mlock.o: in function `__mlock_folio':
> >     mlock.c:(.text+0xe5c): undefined reference to `lruvec_unlock_irq'
> >     nios2-linux-ld: mm/mlock.o: in function `mlock_folio_batch.constprop.0':
> >     mlock.c:(.text+0x158c): undefined reference to `lruvec_unlock_irq'
> > > > nios2-linux-ld: mlock.c:(.text+0x1808): undefined reference to `lruvec_unlock_irq'
> 
> Ouch, I move lruvec_lock_irq() and its firends to memcontrol.c to fix
> the compilation errors related to __acquires/__releases, but I forgot
> that memcontrol.c will only be compiled under CONFIG_MEMCG.
> 
> Hi Shakeel, for simplicity, perhaps keeping lruvec_lock_irq() and its
> firends in memcontrol.h and drop __acquires/__releases would be a
> better option?

Yes, let's proceed with that for now. We can always improve this later.