From: Pranjal Shrivastava <praan@google.com>
To: sashiko-reviews@lists.linux.dev
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 15:04:47 +0000 [thread overview]
Message-ID: <an8uj2qmwuHeSCL1@google.com> (raw)
In-Reply-To: <20260814144658.129DB1F000E9@smtp.kernel.org>
On Fri, Aug 14, 2026 at 02:46:57PM +0000, sashiko-bot@kernel.org wrote:
> 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?
>
These are fixed by patch 2 with the introduction of wb_nr_pinned.
Thanks,
Praan
next prev parent reply other threads:[~2026-08-14 15:04 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
2026-08-14 15:04 ` Pranjal Shrivastava [this message]
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=an8uj2qmwuHeSCL1@google.com \
--to=praan@google.com \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-pci@vger.kernel.org \
--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