From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Donet Tom <donettom@linux.ibm.com>
Cc: Shuah Khan <shuah@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Tony Battersby <tonyb@cybernetics.com>,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, Mike Rapoport <rppt@kernel.org>,
Muchun Song <songmuchun@bytedance.com>
Subject: Re: [PATCH] selftest: mm: Test if hugepage does not get leaked during __bio_release_pages()
Date: Fri, 24 May 2024 12:23:15 +0530 [thread overview]
Message-ID: <87msofsntw.fsf@gmail.com> (raw)
In-Reply-To: <d551d1cd-a02f-42aa-9de2-10ff7757224c@redhat.com>
dropping stable email again.
David Hildenbrand <david@redhat.com> writes:
> On 23.05.24 21:13, Andrew Morton wrote:
>> On Thu, 23 May 2024 01:39:05 -0500 Donet Tom <donettom@linux.ibm.com> wrote:
>>
>>> Commit 1b151e2435fc ("block: Remove special-casing of compound
>>> pages") caused a change in behaviour when releasing the pages
>>> if the buffer does not start at the beginning of the page. This
>>> was because the calculation of the number of pages to release
>>> was incorrect.
>>> This was fixed by commit 38b43539d64b ("block: Fix page refcounts
>>> for unaligned buffers in __bio_release_pages()").
>>>
>>> We pin the user buffer during direct I/O writes. If this buffer is a
>>> hugepage, bio_release_page() will unpin it and decrement all references
>>> and pin counts at ->bi_end_io. However, if any references to the hugepage
>>> remain post-I/O, the hugepage will not be freed upon unmap, leading
>>> to a memory leak.
>>>
>>> This patch verifies that a hugepage, used as a user buffer for DIO
>>> operations, is correctly freed upon unmapping, regardless of whether
>>> the offsets are aligned or unaligned w.r.t page boundary.
>>>
>>
>
> Two SOF, is there a Co-developed-by: missing?
>
Sorry about that. Andrew, could you please add the tag (let me know if you
would like me to send v2). Will take care of it next time.
Co-developed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
-ritesh
next prev parent reply other threads:[~2024-05-24 6:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 6:39 [PATCH] selftest: mm: Test if hugepage does not get leaked during __bio_release_pages() Donet Tom
2024-05-23 6:40 ` kernel test robot
2024-05-23 19:13 ` Andrew Morton
2024-05-23 20:40 ` David Hildenbrand
2024-05-24 2:57 ` Andrew Morton
2024-05-24 6:21 ` David Hildenbrand
2024-05-24 6:43 ` Ritesh Harjani
2024-05-24 7:01 ` David Hildenbrand
2024-05-24 9:31 ` Donet Tom
2024-05-24 15:20 ` David Hildenbrand
2024-05-24 6:53 ` Ritesh Harjani [this message]
2024-05-24 20:12 ` Andrew Morton
2024-05-24 18:13 ` Muhammad Usama Anjum
2024-05-25 15:40 ` Donet Tom
-- strict thread matches above, loose matches on Subject: below --
2024-06-04 13:28 [PATCH v2] " Donet Tom
2024-06-06 13:14 ` [PATCH] " Pankaj Raghav
2024-06-06 13:58 ` Donet Tom
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=87msofsntw.fsf@gmail.com \
--to=ritesh.list@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=donettom@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=tonyb@cybernetics.com \
--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.