Linux PCI subsystem development
 help / color / mirror / Atom feed
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

  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