On 8/22/19 2:07 PM, Dave Chinner wrote: > On Thu, Aug 22, 2019 at 01:14:30PM +0200, Vlastimil Babka wrote: > > No, the problem is this (using kmalloc as a general term for > allocation, whether it be kmalloc, kmem_cache_alloc, alloc_page, etc) > > some random kernel code > kmalloc(GFP_KERNEL) > reclaim > PF_MEMALLOC > shrink_slab > xfs_inode_shrink > XFS_ILOCK > xfs_buf_allocate_memory() > kmalloc(GFP_KERNEL) > > And so locks on inodes in reclaim are seen below reclaim. Then > somewhere else we have: > > some high level read-only xfs code like readdir > XFS_ILOCK > xfs_buf_allocate_memory() > kmalloc(GFP_KERNEL) > reclaim > > And this one throws false positive lockdep warnings because we > called into reclaim with XFS_ILOCK held and GFP_KERNEL alloc OK, and what exactly makes this positive a false one? Why can't it continue like the first example where reclaim leads to another XFS_ILOCK, thus deadlock? > context. So the only solution we had at the tiem to shut it up was: > > some high level read-only xfs code like readdir > XFS_ILOCK > xfs_buf_allocate_memory() > kmalloc(GFP_NOFS) > > So that lockdep sees it's not going to recurse into reclaim and > doesn't throw a warning... AFAICS that GFP_NOFS would fix not only a warning but also a real deadlock (depending on the answer to my previous question). > Cheers, > > Dave. >
