From: sashiko-bot@kernel.org
To: "Pranjal Shrivastava" <praan@google.com>
Cc: "Anna Schumaker" <anna@kernel.org>,
"Chuck Lever" <cel@kernel.org>,
linux-pci@vger.kernel.org, "Jeff Layton" <jlayton@kernel.org>
Subject: Re: [PATCH v6 1/5] nfs: make nfs_page pin-aware
Date: Fri, 14 Aug 2026 14:46:57 +0000 [thread overview]
Message-ID: <20260814144658.129DB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260814143255.861084-2-praan@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Subrequests incorrectly drop GUP pins multiple times because `req == req->wb_head` evaluates to true for all requests during teardown, causing pin count underflow and Use-After-Free.
- [Medium] Hardcoded unpin count of 1 in `unpin_user_folio()` leaks GUP pins for large folios spanning multiple pages.
--
--- Patch [1]: [PATCH v6 1/5] nfs: make nfs_page pin-aware ---
commit 21b0f62730c29dca3085e0b77d441b62786919e8
Author: Pranjal Shrivastava <praan@google.com>
nfs: make nfs_page pin-aware
Modernizing the NFS Direct I/O path to use iov_iter_extract_pages()
introduces page pinning (GUP) instead of standard page referencing.
To handle this correctly, nfs_page must track whether it holds a
pin or a standard reference.
> diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
> index 7dd478ffc2fab..a562cfe2a126d 100644
> --- a/fs/nfs/pagelist.c
> +++ b/fs/nfs/pagelist.c
[ ... ]
> @@ -552,11 +566,21 @@ static void nfs_clear_request(struct nfs_page *req)
> struct nfs_open_context *ctx;
>
> if (folio != NULL) {
> - folio_put(folio);
> + if (test_and_clear_bit(PG_PINNED, &req->wb_flags)) {
> + if (req == req->wb_head)
> + unpin_user_folio(folio, 1);
[Severity: Medium]
Will this leak GUP pins for large folios spanning multiple pages?
If a caller uses nfs_page_create_from_folio() with pinned=true for a folio
spanning multiple pages, hardcoding 1 releases only one pin and leaks the rest.
Also, does this check for the head request evaluate to true for all
subrequests?
During teardown, nfs_page_group_destroy() breaks the page group linkage by
setting tmp->wb_head = tmp before freeing the request:
nfs_page_group_destroy()
tmp->wb_head = tmp;
nfs_free_request(tmp);
Because of this, when nfs_clear_request() is called, req == req->wb_head will
evaluate to true for all subrequests, causing each subrequest to unconditionally
invoke unpin_user_folio() and potentially resulting in a pin count underflow
and Use-After-Free.
> + } else {
> + folio_put(folio);
> + }
> req->wb_folio = NULL;
> clear_bit(PG_FOLIO, &req->wb_flags);
> } else if (page != NULL) {
> - put_page(page);
> + if (test_and_clear_bit(PG_PINNED, &req->wb_flags)) {
> + if (req == req->wb_head)
> + unpin_user_page(page);
[Severity: Medium]
Similar to the issue above, because nfs_page_group_destroy() severs the
linkage and sets tmp->wb_head = tmp, will this unconditionally call
unpin_user_page() for all subrequests and cause a pin count underflow?
> + } else {
> + put_page(page);
> + }
> req->wb_page = NULL;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260814143255.861084-1-praan@google.com?part=1
next prev parent reply other threads:[~2026-08-14 14:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 14:32 [PATCH v6 0/5] nfs: modernize direct I/O path Pranjal Shrivastava
2026-08-14 14:32 ` [PATCH v6 1/5] nfs: make nfs_page pin-aware Pranjal Shrivastava
2026-08-14 14:46 ` sashiko-bot [this message]
2026-08-14 15:04 ` Pranjal Shrivastava
2026-08-14 14:32 ` [PATCH v6 2/5] nfs: track number of pinned pages in nfs_page Pranjal Shrivastava
2026-08-14 14:47 ` sashiko-bot
2026-08-14 15:14 ` Pranjal Shrivastava
2026-08-14 14:32 ` [PATCH v6 3/5] nfs: introduce nfs_release_request_list helper Pranjal Shrivastava
2026-08-14 14:38 ` sashiko-bot
2026-08-14 14:32 ` [PATCH v6 4/5] nfs: migrate direct I/O to iov_iter_extract_pages Pranjal Shrivastava
2026-08-14 14:48 ` sashiko-bot
2026-08-14 14:32 ` [PATCH v6 5/5] nfs: introduce nfs_direct_extract_pages helper Pranjal Shrivastava
2026-08-14 14:40 ` sashiko-bot
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=20260814144658.129DB1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=praan@google.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox