On Thu, Mar 24, 2022 at 7:11 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > Muchun, > mind taking a look at this asap? This seems like a pretty core thing, > and the fact that it oopses on that Sorry for this. I am looking at this now. > > > RIP: 0010:list_add_tail include/linux/list.h:102 [inline] > > RIP: 0010:list_lru_add+0x277/0x510 mm/list_lru.c:129 > > d_lru_add fs/dcache.c:431 [inline] > > retain_dentry fs/dcache.c:685 [inline] > > dput+0x7a7/0xdb0 fs/dcache.c:908 > > just worries me a lot. > > The dentry lru list rules are odd but not outrageously so. The main > oddity is that the DCACHE_LRU_LIST bit in the dentry flags indicate > whether the dentry is on a LRU list or not. > > And it's not one single list - it can be *either* the usual > sb->lists_dentry_lru list, or the special "shrink list". > > But this oops is for the regular d_lru_add() path that adds the dentry > to the sb->s_dentry_lru list as the dentry count goes down to zero > (and it's not one of the dentries that get insta-free'd). After this commit, the rules of dentry allocations changed. The dentry should be allocated by kmem_cache_alloc_lru() to set up the dentry reclaim context correctly (e.g. allocating its list_lru_one). This issue seems that list_lru_one wasn't allocated, then NULL pointer reference. I'm trying to reproduce this and looking for the root cause. Thanks.
