From: Andrew Morton <akpm@linux-foundation.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
lvc-project@linuxtesting.org, Fedor Pchelkin <pchelkin@ispras.ru>
Subject: Re: [PATCH] lib: free pagelist on error in iov_iter_extract_pages()
Date: Fri, 8 May 2026 14:48:23 -0700 [thread overview]
Message-ID: <20260508144823.0213964cb15e7ef8fbdcd7c5@linux-foundation.org> (raw)
In-Reply-To: <20260508111329.329943-1-dmantipov@yandex.ru>
On Fri, 8 May 2026 14:13:29 +0300 Dmitry Antipov <dmantipov@yandex.ru> wrote:
> Since 'iov_iter_extract_pages()' may allocate new pagelist if the passed
> one isn't large enough, the worst-case scenario may be:
>
> ...
> struct page *stack_pages[SMALL];
> struct page **pages = stack_pages;
> ...
> if (iov_iter_extract_pages(i..., &pages, ...) <= 0) {
> /* Even in case of error, new pagelist may be allocated */
> if (pages != stack_pages)
> kvfree(pages); [1]
> /* The rest of error handling and return */
> }
> /* Regular flow */
> ...
> if (pages != stack_pages)
> kvfree(pages);
> ...
> return 0;
>
> If you're unlucky so SMALL amount of pages wasn't enough and new
> pagelist was allocated, missing [1] causes the memory leak similar
> to one I've recently observed and fixed for 6.12 in [2]. So adjust
> 'iov_iter_extract_pages()' to make such a cleanup itself rather than
> rely on caller's handling on error paths, thus making [1] not needed.
AI review said things:
https://sashiko.dev/#/patchset/20260508111329.329943-1-dmantipov@yandex.ru
next prev parent reply other threads:[~2026-05-08 21:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 11:13 [PATCH] lib: free pagelist on error in iov_iter_extract_pages() Dmitry Antipov
2026-05-08 18:33 ` Caleb Sander Mateos
2026-05-11 6:35 ` Christoph Hellwig
2026-05-12 8:12 ` Dmitry Antipov
2026-05-12 9:07 ` Fedor Pchelkin
2026-05-12 11:23 ` Dmitry Antipov
2026-05-08 21:48 ` Andrew Morton [this message]
2026-06-04 13:46 ` Fedor Pchelkin
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=20260508144823.0213964cb15e7ef8fbdcd7c5@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=dmantipov@yandex.ru \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=pchelkin@ispras.ru \
/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.