Re: [PATCH 7/9] squashfs: Remove use of FGP_NOFS

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unprotected GFP_KERNEL allocations while holding folio locks can cause compaction deadlocks.
--

commit f9b201cd220cb4651ba3f51b039ab61732317528
Author: Matthew Wilcox (Oracle) <willy@infradead.org>

squashfs: Remove use of FGP_NOFS

This commit replaces the use of FGP_NOFS with memalloc_nofs_save() in
squashfs_copy_cache() to prevent page reclaim from calling into the
filesystem and attempting to compact the locked folio.

> diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c
> index d83594ce91d23..34c550a266bcf 100644
> --- a/fs/squashfs/file.c
> +++ b/fs/squashfs/file.c
[ ... ]
> @@ -398,6 +398,7 @@ void squashfs_copy_cache(struct folio *folio,
>  	struct squashfs_sb_info *msblk = inode->i_sb->s_fs_info;
>  	int i, mask = (1 << (msblk->block_log - PAGE_SHIFT)) - 1;
>  	int start_index = folio->index & ~mask, end_index = start_index | mask;
> +	unsigned int nofs = memalloc_nofs_save();
>  
>  	/*
>  	 * Loop copying datablock into pages.  As the datablock likely covers

[Severity: High]
This is a pre-existing issue, but while this patch fixes the allocation
context in squashfs_copy_cache(), does the same compaction deadlock risk
apply to other GFP_KERNEL allocations in the read_folio path?

For example, in fs/squashfs/file.c:read_indexes():

    __le32 *blist = kmalloc(PAGE_SIZE, GFP_KERNEL);

And in fs/squashfs/file_direct.c:squashfs_readpage_block():

    page = kmalloc_array(pages, sizeof(void *), GFP_KERNEL);

Both of these allocations occur deep within the read_folio call chain while
the target folio is held locked by the VFS. If memory pressure triggers
direct reclaim and synchronous compaction, it could attempt to lock the
exact same folio that the thread is already holding, leading to a deadlock.

While VFS readahead callers establish a NOFS context via
memalloc_nofs_save(), read_folio callers like filemap_read_folio() do not.
Should these locations also be updated to prevent compaction deadlocks?

> @@ -430,6 +431,8 @@ void squashfs_copy_cache(struct folio *folio,
>  		if (i != folio->index)
>  			folio_put(push_folio);
>  	}
> +
> +	memalloc_nofs_restore(nofs);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260830041901.2668-1-willy@infradead.org?part=7