Re: [PATCH 2/3] xfs: add kmem_alloc_io()

Vlastimil Babka
2019-08-22T12:19:07Z

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.
>