From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Hugh Dickins <hughd@google.com>,
Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH 0/3] hugetlbfs fallocate hole punch race with page faults
Date: Mon, 19 Oct 2015 18:54:12 -0700 [thread overview]
Message-ID: <56259EC4.9010207@oracle.com> (raw)
In-Reply-To: <20151019161840.63e6afaa73aceec23e351905@linux-foundation.org>
On 10/19/2015 04:18 PM, Andrew Morton wrote:
> On Fri, 16 Oct 2015 15:08:27 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
>> The hugetlbfs fallocate hole punch code can race with page faults. The
>> result is that after a hole punch operation, pages may remain within the
>> hole. No other side effects of this race were observed.
>>
>> In preparation for adding userfaultfd support to hugetlbfs, it is desirable
>> to plug or significantly shrink this hole. This patch set uses the same
>> mechanism employed in shmem (see commit f00cdc6df7).
>>
>
> "still buggy but not as bad as before" isn't what we strive for ;) What
> would it take to fix this for real? An exhaustive description of the
> bug would be a good starting point, thanks.
>
Thanks for asking, it made me look closer at ways to resolve this.
The current code in remove_inode_hugepages() does nothing with a page if
it is still mapped. The only way it can be mapped is if we race and take
a page fault after unmapping, but before the page is removed. This patch
set makes that window much smaller, but it still exists.
Instead of "giving up" on a mapped page, remove_inode_hugepages() can go
back and unmap it. I'll code this up tomorrow. Fortunately, it is
pretty easy to hit these races and verify proper behavior.
I'll create a new patch set with this combined code for a complete fix.
--
Mike Kravetz
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Dave Hansen <dave.hansen@linux.intel.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Hugh Dickins <hughd@google.com>,
Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH 0/3] hugetlbfs fallocate hole punch race with page faults
Date: Mon, 19 Oct 2015 18:54:12 -0700 [thread overview]
Message-ID: <56259EC4.9010207@oracle.com> (raw)
In-Reply-To: <20151019161840.63e6afaa73aceec23e351905@linux-foundation.org>
On 10/19/2015 04:18 PM, Andrew Morton wrote:
> On Fri, 16 Oct 2015 15:08:27 -0700 Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
>> The hugetlbfs fallocate hole punch code can race with page faults. The
>> result is that after a hole punch operation, pages may remain within the
>> hole. No other side effects of this race were observed.
>>
>> In preparation for adding userfaultfd support to hugetlbfs, it is desirable
>> to plug or significantly shrink this hole. This patch set uses the same
>> mechanism employed in shmem (see commit f00cdc6df7).
>>
>
> "still buggy but not as bad as before" isn't what we strive for ;) What
> would it take to fix this for real? An exhaustive description of the
> bug would be a good starting point, thanks.
>
Thanks for asking, it made me look closer at ways to resolve this.
The current code in remove_inode_hugepages() does nothing with a page if
it is still mapped. The only way it can be mapped is if we race and take
a page fault after unmapping, but before the page is removed. This patch
set makes that window much smaller, but it still exists.
Instead of "giving up" on a mapped page, remove_inode_hugepages() can go
back and unmap it. I'll code this up tomorrow. Fortunately, it is
pretty easy to hit these races and verify proper behavior.
I'll create a new patch set with this combined code for a complete fix.
--
Mike Kravetz
next prev parent reply other threads:[~2015-10-20 2:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-16 22:08 [PATCH 0/3] hugetlbfs fallocate hole punch race with page faults Mike Kravetz
2015-10-16 22:08 ` Mike Kravetz
2015-10-16 22:08 ` [PATCH 1/3] mm/hugetlb: Define hugetlb_falloc structure for hole punch race Mike Kravetz
2015-10-16 22:08 ` Mike Kravetz
2015-10-16 22:08 ` [PATCH 2/3] mm/hugetlb: Setup hugetlb_falloc during fallocate hole punch Mike Kravetz
2015-10-16 22:08 ` Mike Kravetz
2015-10-19 23:16 ` Andrew Morton
2015-10-19 23:16 ` Andrew Morton
2015-10-20 1:41 ` Mike Kravetz
2015-10-20 1:41 ` Mike Kravetz
2015-10-20 2:22 ` Hugh Dickins
2015-10-20 2:22 ` Hugh Dickins
2015-10-20 3:12 ` Mike Kravetz
2015-10-20 3:12 ` Mike Kravetz
2015-10-16 22:08 ` [PATCH 3/3] mm/hugetlb: page faults check for fallocate hole punch in progress and wait Mike Kravetz
2015-10-16 22:08 ` Mike Kravetz
2015-10-19 23:18 ` [PATCH 0/3] hugetlbfs fallocate hole punch race with page faults Andrew Morton
2015-10-19 23:18 ` Andrew Morton
2015-10-20 1:54 ` Mike Kravetz [this message]
2015-10-20 1:54 ` Mike Kravetz
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=56259EC4.9010207@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
/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.