From: Mike Kravetz <mike.kravetz@oracle.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Davidlohr Bueso <dave@stgolabs.net>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Hocko <mhocko@kernel.org>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: [PATCH v2 0/2] A couple hugetlbfs fixes
Date: Thu, 28 Mar 2019 16:47:02 -0700 [thread overview]
Message-ID: <20190328234704.27083-1-mike.kravetz@oracle.com> (raw)
I stumbled on these two hugetlbfs issues while looking at other things:
- The 'restore reserve' functionality at page free time should not
be adjusting subpool counts.
- A BUG can be triggered (not easily) due to temporarily mapping a
page before doing a COW.
Both are described in detail in the commit message of the patches.
I would appreciate comments from Davidlohr Bueso as one patch is
directly related to code he added in commit 8382d914ebf7.
I did not cc stable as the first problem has been around since reserves
were added to hugetlbfs and nobody has noticed. The second is very hard
to hit/reproduce.
v2 - Update definition and all callers of hugetlb_fault_mutex_hash as
the arguments mm and vma are no longer used or necessary.
Mike Kravetz (2):
huegtlbfs: on restore reserve error path retain subpool reservation
hugetlb: use same fault hash key for shared and private mappings
fs/hugetlbfs/inode.c | 7 ++-----
include/linux/hugetlb.h | 4 +---
mm/hugetlb.c | 43 +++++++++++++++++++++--------------------
mm/userfaultfd.c | 3 +--
4 files changed, 26 insertions(+), 31 deletions(-)
--
2.20.1
next reply other threads:[~2019-03-28 23:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-28 23:47 Mike Kravetz [this message]
2019-03-28 23:47 ` [PATCH v2 1/2] huegtlbfs: on restore reserve error path retain subpool reservation Mike Kravetz
2019-03-28 23:47 ` [PATCH v2 2/2] hugetlb: use same fault hash key for shared and private mappings Mike Kravetz
2019-04-11 18:32 ` Mike Kravetz
2019-04-12 16:52 ` Davidlohr Bueso
2019-04-03 5:29 ` [PATCH v2 0/2] A couple hugetlbfs fixes Naoya Horiguchi
2019-04-08 19:48 ` Davidlohr Bueso
2019-04-09 3:30 ` 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=20190328234704.27083-1-mike.kravetz@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=iamjoonsoo.kim@lge.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.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.