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: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240523063905.3173-1-donettom@linux.ibm.com>
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
[not found] ` <3c6e5e78-aa49-4002-941f-af8fd2b81d10@linux.ibm.com>
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
[not found] <20240604132801.23377-1-donettom@linux.ibm.com>
2024-06-06 13:14 ` Pankaj Raghav
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox