From: sashiko-bot@kernel.org
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: "Jeff Layton" <jlayton@kernel.org>,
"Anna Schumaker" <anna@kernel.org>,
tytso@mit.edu, "Chuck Lever" <cel@kernel.org>,
linux-ext4@vger.kernel.org
Subject: Re: [PATCH 9/9] filemap: Remove FGP_NOFS
Date: Sun, 30 Aug 2026 04:27:42 +0000 [thread overview]
Message-ID: <20260830042742.84E321F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830041901.2668-10-willy@infradead.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Undeclared identifier 'FGP_NOFS' causes compilation failure in f2fs, and trivial removal introduces a filesystem reclaim deadlock.
--
commit 1683abf08ae4fef5fa05b44d804e2e0ac6771ec5
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
filemap: Remove FGP_NOFS
This commit removes the FGP_NOFS flag and its associated __GFP_FS clearing
logic, stating that there are no more users of it.
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 3974b063a0496..bff8b7264fb02 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
[ ... ]
> @@ -710,11 +709,10 @@ typedef unsigned int __bitwise fgf_t;
> #define FGP_LOCK ((__force fgf_t)0x00000002)
> #define FGP_CREAT ((__force fgf_t)0x00000004)
> #define FGP_WRITE ((__force fgf_t)0x00000008)
> -#define FGP_NOFS ((__force fgf_t)0x00000010)
[Severity: Low]
Does this removal break the build for f2fs?
Looking at f2fs_write_begin() in fs/f2fs/data.c, it still relies on the
removed FGP_NOFS flag:
folio = f2fs_filemap_get_folio(mapping, index,
FGP_LOCK | FGP_WRITE | FGP_CREAT | FGP_NOFS,
mapping_gfp_mask(mapping));
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 6afec636881fb..e6580291f2185 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1994,8 +1994,6 @@ struct folio *__filemap_get_folio_mpol(struct address_space *mapping,
>
> if ((fgp_flags & FGP_WRITE) && mapping_can_writeback(mapping))
> gfp |= __GFP_WRITE;
> - if (fgp_flags & FGP_NOFS)
> - gfp &= ~__GFP_FS;
[Severity: Low]
If the build failure is trivially fixed by simply deleting FGP_NOFS from
f2fs_write_begin() without adding a memalloc_nofs_save() wrapper, will this
introduce an ABBA deadlock during direct reclaim?
Because __filemap_get_folio_mpol() no longer clears __GFP_FS, this could
allow __GFP_FS to bleed into the allocator while f2fs calls this holding
internal filesystem locks.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830041901.2668-1-willy@infradead.org?part=9
next prev parent reply other threads:[~2026-08-30 4:27 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 4:18 [PATCH 0/9] Remove FGP_NOFS Matthew Wilcox (Oracle)
2026-08-30 4:18 ` [PATCH 1/9] mm: Improve memalloc_nofs_save() documentation Matthew Wilcox (Oracle)
2026-08-30 4:21 ` sashiko-bot
2026-08-31 9:59 ` Jan Kara
2026-08-30 4:18 ` [PATCH 2/9] ext4: Remove uses of FGP_NOFS Matthew Wilcox (Oracle)
2026-08-30 4:27 ` sashiko-bot
2026-08-31 10:03 ` Jan Kara
2026-08-31 12:32 ` Baokun Li
2026-09-01 2:17 ` Zhang Yi
2026-09-03 14:44 ` Theodore Tso
2026-08-30 4:18 ` [PATCH 3/9] erofs: Remove redundant FGP_NOFS Matthew Wilcox (Oracle)
2026-08-30 4:24 ` sashiko-bot
2026-08-31 10:08 ` Jan Kara
2026-09-01 5:55 ` Gao Xiang
2026-08-30 4:18 ` [PATCH 4/9] nfs: " Matthew Wilcox (Oracle)
2026-08-30 4:26 ` sashiko-bot
2026-08-31 10:07 ` Jan Kara
2026-08-30 4:18 ` [PATCH 5/9] ntfs: Remove FGP_NOFS from __ntfs_inode_resident_attr_pwrite() Matthew Wilcox (Oracle)
2026-08-30 4:39 ` sashiko-bot
2026-08-31 23:34 ` Namjae Jeon
2026-08-30 4:18 ` [PATCH 6/9] ntfs: Remove redundant FGP_NOFS from ntfs_wof_collect_dest() Matthew Wilcox (Oracle)
2026-08-30 4:25 ` sashiko-bot
2026-08-31 23:31 ` Namjae Jeon
2026-08-30 4:18 ` [PATCH 7/9] squashfs: Remove use of FGP_NOFS Matthew Wilcox (Oracle)
2026-08-30 4:33 ` sashiko-bot
2026-08-31 10:11 ` Jan Kara
2026-08-30 4:18 ` [PATCH 8/9] filemap: Remove redundant FGP_NOFS Matthew Wilcox (Oracle)
2026-08-30 4:25 ` sashiko-bot
2026-08-31 10:06 ` Jan Kara
2026-08-30 4:18 ` [PATCH 9/9] filemap: Remove FGP_NOFS Matthew Wilcox (Oracle)
2026-08-30 4:27 ` sashiko-bot [this message]
2026-08-30 4:32 ` Matthew Wilcox
2026-08-31 10:07 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830042742.84E321F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.